8 ms·

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

98 points by danboarder 11y ago

losvedir 11y ago
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 11y ago
  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.
  - ocdtrekkie 11y ago
    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.
  - kentonv 11y ago
    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. :)
  - sciurus 11y ago
    What do you want the mobile app to do?
zaroth 11y ago
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 11y ago
  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-events/ 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 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 11y ago
    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.
skibble 11y ago
Song?
mxuribe 11y ago
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 11y ago
  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 11y ago
    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. ;-)

98 points by danboarder 11y ago

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 11y ago
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.
- ocdtrekkie 11y ago
  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.
- kentonv 11y ago
  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. :)
- sciurus 11y ago
  What do you want the mobile app to do?

zaroth 11y ago

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 11y ago
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-events/ 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 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 11y ago
  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.

skibble 11y ago

Song?

mxuribe 11y ago

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 11y ago
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 11y ago
  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. ;-)