
Sandstorm's security track record, and what it means for self-hosting - danboarder
https://sandstorm.io/news/2016-02-29-security-track-record
======
losvedir
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...)

~~~
smartbit
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.

~~~
kentonv
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. :)

------
mxuribe
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!

~~~
kentonv
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.

~~~
mxuribe
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](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. ;-)

~~~
kentonv
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.

~~~
mxuribe
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!!

------
zaroth
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!

~~~
kentonv
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...](https://docs.sandstorm.io/en/latest/using/security-non-events/)

This page has a more general overview of the concept:
[https://sandstorm.io/how-it-works](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.)

~~~
zaroth
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.

~~~
kentonv
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. :)

~~~
zaroth
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](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.

~~~
kentonv
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.

------
skibble
Song?

