Sandstorm's security track record, and what it means for self-hosting | Hacker News Reader

Sandstorm's security track record, and what it means for self-hosting

sandstorm.io

98 pointsdanboarder19 comments

I'm continually impressed with sandstorm. I played around with their thing on oasis and it all worked as advertised. It's not extremely polished yet, but the functionality is there. I've been looking into their serialization protocol, Cap'n Proto, for a side project and again it seems quite well designed.

I sincerely hope the future is one in which lots of families, people, etc, self host their own "cloud apps" rather than delegating it all to facebook, gmail, etc, and sandstorm looks like it could be a winner here. (Or maybe owncloud, or that thing that HN blogged about a week or two ago, or...)

I looked around for mobile support, but couldn't find a list of client apps for iOS/Android. Seems a reason to skip on sandstorm for now.

Sandstorm works decently as a web app on mobile devices. Also, certain apps have mobile app support. For instance, Davros actually can use the ownCloud client. Tiny Tiny RSS has an app embedded in Sandstorm (slightly forked) for Android as well. And then Radicale is an CalDAV/CardDAV sync server, which will work with a lot of contacts and calendar apps.

Given the variety of applications one can host on Sandstorm, it's hard to have an all encompassing 'Sandstorm app'. And for what the core of Sandstorm does, the web interface does it well on mobile.

We definitely want to build a "Sandstorm App" on mobile at some point, although it's worth noting that it would mostly be a hub for other apps to hook into your Sandstorm server, which to some extent they can do already, as demonstrated e.g. by the TinyTinyRSS Android app which can sync with your TTRSS instance on Sandstorm.

At present most of our apps are focused on productivity tasks (e.g. real-time collaborative document editing) with I think is the kind of thing people still mostly do on desktops. You can totally open Sandstorm and Etherpad on a phone browser, though, and I commonly do this when demoing it to people.

In any case, we obviously have a lot of work still to do, but I hope that doesn't stop anyone from trying out what we have so far. :)

What do you want the mobile app to do?

I really, really want to support sandstorm! I think their model is awesome, especially because i fully support a decentralized web where the masses and the regular Janes/Joes have a valid alternative to the silos on the web. However, I tried using rocket.chat recently, and while installation of app was dead simple, actually using it seemed non-obvious. I'll admit I'm no super devops/engineer, but i do successfully manage my only little server via other providers (e.g. digital ocean, etc.)...so it was a little annoying that i had to spend more time than i expected to see how to actually use rocket.chat via sandstorm. Here's where a little documentation could have gone a very long way. My interest in sandstorm was for setting up apps only for my family...and eventually having my "non-technical wife" (her words not mine) use and manage things. I'll be honest, i will speak highly of sandstorm for techies, and I will support you guys - even if only because you so greatly support open source and a decentralized web - but seriously, you guys could be getting so much more attention and BUSINESS if you only had much more "civilian" documentation (I'll say more on the "how to use an app" side, since installation of apps is so dead simple)...until then i can not in good conscious recommend your service - at least not for all apps - to the "non-techie" people that i know. Again, i state this not to disparage your service, but because I really, really want you guys to succeed! When you do (update/create more user documentation), let's talk; my handle on your platform is mxuribe. Thanks and good luck!

Thanks for the feedback. I'd love to know what were the specific usability problems you ran into. Documentation is great but if we can eliminate the confusing parts entirely that's even better. Rocket.Chat in particular does have some rough edges that we're aware of and working with them to fix.

In essence once a grain for rocket.chat is set up, what non-ephemeral url should be used for users to connect from their rocket chat client (either desktop or mobile)?

I tried the grain's url, the "share with others" url, etc...But none work via rocket chat's clients. I did find the following discussion: https://github.com/RocketChat/Rocket.Chat/issues/1352 ...Again, I'm just not understanding what url i can share for my family to use - via for example mobile device - to connect/chat on this grain (whether i kill my browser sessions or not).

Sorry i didn't mean to make this almost a support inquiry. Maybe a simple note displayed upon creation of the grain like the following would help: "Hey, you just created a rocket chat grain, if your users are going to connect using one of rocket chat's clients, they need to enter this following url: xyz12300d64bnfnskdfnfgi3o45titj34.oasis.sandostorm.io/whatever/rocketchat/whatever/2342342r". And you can imagine if you look at your "abandon logs"; how many other users try your service, can't figure out how to connect to it for a particular app (again we're talking typical, non-techie users), and then never come back? Again, my comments are coming from a fan of yours. ;-)

Ah, the problem is that Rocket.Chat's client apps actually don't work with the Sandstorm app right now; it's only accessible in the browser. That's definitely something we're trying to get the Rocket.Chat team to fix, as you can see in that bug thread.

Got it, thanks. Yeah, not specific to only rocket.chat, I think you will win more clients if you clarify - maybe in the intro text for each app? - that the app is designed currently for "in browser" use, etc. In any case, thanks a bunch for this clarification! You guys keep rocking on!!

It wasn't initially clear to me when reading... Is this referring to the Sandstorm environment automatically applying updates as they are released to the apps you have enabled? Or are these vulnerabilities that the Sandstorm environment itself mitigated without the need to apply a patch?

Clicking through it seems like they are saying "security non-events" meaning if you self-hosted an app yourself you would have been vulnerable, but because you managed the app through Sandstorm, you were never vulnerable. This is definitely very interesting!

These are things Sandstorm mitigated even before the vulnerability was reported, much less patched! The magic solution is fine-grained containerization, meaning every document goes in its own container and Sandstorm (the platform) manages access control to containers.

This page describes individual CVEs and how they were mitigated: https://docs.sandstorm.io/en/latest/using/security-non-event...

This page has a more general overview of the concept: https://sandstorm.io/how-it-works

(It's funny how many people initially react to this idea with something like: "How is that not obviously wrong?" Guess what? It works. And no, it's not inefficient -- our managed hosting service runs a healthy profit margin.)

Yea, reading your page detailing the CVEs, you show that all reported grade 6 or higher CVEs against Wordpress in 2014-2015 were not ever exploitable against the Sandstorm hosted app. Of course, it's just a static page reflection, so that certainly helps your attack surface!

But I 100% agree with your premise, providing dependable security (even at a reduced functional footprint) is a key deliverable for Sandstorm and adds tremendous value to the platform. I assume you have found that adoption is hindered significantly by people "nervous" to try it? The premise is if you can make Sandstorm feel more safe, easy, reliable, it could it become mainstream. So security benefits are a huge bonus.

It also looks like the Sandstorm authentication design has really paid off. I think it's part of the initial complexity of evaluating your system, which is unfortunate, but it's great to see it providing real-world protection for a lot of your apps.

Yeah... Honestly Wordpress is my least-favorite example because it's the one case where the Sandstorm version of the app has significant features removed (namely, the ability to post comments). This is why we push it to the bottom of the app market, despite being a popular app. However, as noted in the document, we could produce a version of Wordpress on Sandstorm which has comments and is still just as secure. It's just that we'd need to spend some engineering time on it, and there are so many Wordpress hosting services out there that I just don't feel like it's the most valuable use of our limited resources. :/

For apps like Etherpad, on the other hand, Sandstorm has blocked several serious security vulnerabilities with zero loss in functionality -- in fact, Etherpad on Sandstorm has more robust sharing / access control than Etherpad stand-alone. :)

The depth you are going into security hardening and analyzing vulnerabilities potential impact on your system seems almost extreme ;-) https://github.com/seccomp/libseccomp/issues/27

I see you have an App Market -- is anyone selling apps for Sandstorm, or are they all free? If there was a way to monetize, I'm surprised someone wouldn't invest the time to make Wordpress support comments and then sell it on your market?

To me this is a really interesting monetization model... can a few small developers write a Sandstorm app which potentially 1M+ users could one day be deploying and self hosting, while charging some nominal annual fee to fund the development?

When I saw the YC W16 startup on the front page a few days ago selling the pretty box to enterprises who wanted to self-host, first thing I thought of was Sandstorm. Why sell hardware? You are making the platform which makes managing the apps possible for 90% of businesses, that has to be where the value is.

We plan to support paid apps at some point (more precisely, in-app purchases, which my friends who worked on Android say is far more effective than paying for the apps themselves), but haven't gotten there yet.

> (It's funny how many people initially react to this idea with something like: "How is that not obviously wrong?" Guess what? It works. And no, it's not inefficient -- our managed hosting service runs a healthy profit margin.)

It's natural to wonder why everyone isn't doing it, if it's this easy. Or where the innovative part lies. Whenever someone claims a major advance, some skepticism is probably correct.

Abstracting the storage/object model of a program as in Cap'N Proto is the new advance, though Cap'N Proto's security model isn't fully innovative -- it's based on object capabilities which have been around since the 70s and this particular model since the 90s in the E programming language. The isolation properties of capabilities have been well understood for quite some time.

Sandstorm just took this well understood security model and the innovative storage abstraction and applied it to any language with Cap'N Proto bindings. Pretty cool.

The reason most people aren't doing it is beacuse most people don't really understand capability security, despite its simplicity. They've been raised and trained in the access control list model and it's deeply ingrained at this point.

Song?

Reply on news.ycombinator.com