By Kenton Varda - 11 Jul 2014
A few quick updates today.
It’s now possible to try out Sandstorm without an invite, and without installing it locally. Just go to demo.sandstorm.io.
On the demo server, anyone can create a one-hour trial account. We hope that this will make it much easier for people to understand what Sandstorm does, before they install it or wait in line for an invite. If a picture is worth a thousand words, a demo is worth ten thousand.
We’ve posted updates to several apps with bug fixes and other improvements. Currently, in order to update an app, you must re-install it from the app list. (Push updates for apps are on our todo list.) So, if you’ve installed any of the following, install them again.
Several people told us they were not comfortable contributing to Sandstorm when licensed under the GNU AGPL, or that their employers were hesitant to allow them to contribute. We think this is entirely understandable. We have always intended to switch to Apache 2.0 after gaining some momentum (which is why we have asked contributors to sign a CLA allowing us to make this change). So, we’ve gone ahead and made the switch now.
By Jason Paryani - 07 Jul 2014
Hello, I’m Jason, a new member of the Sandstorm team. Today I’m excited to announce that I’ve extended Sandstorm to support e-mail, and ported Mailpile Alpha II to demonstrate. Mailpile is available on the Sandstorm app list right now, so go ahead and try it out.
You may know Mailpile from their successful Indiegogo campaign last year. They’ve been working hard to create a web mail app that is designed to be self-hosted, which makes it a perfect fit for Sandstorm. It’s worth noting that Mailpile itself is, like Sandstorm, still in alpha. It is still somewhat rough around the edges, and may not quite be ready to replace your regular e-mail client yet. We will be updating our port as Mailpile matures, and we’re also looking at porting some other web mail apps so that you can choose the one that’s right for you.
We know that switching people over to using Sandstorm for e-mail will take time. So, we are starting with a design that makes it safe and easy to try out Sandstorm without committing.
When you launch an e-mail application on Sandstorm, it is assigned a random e-mail address at your server, like “JBuaKxjkwiJq7oksS@alpha.sandstorm.io”. Any e-mail sent to that address is delivered to the app. The idea is not that you’d actually use this address publicly, but rather that you should set up e-mail forwarding from your real address to this address. For example, GMail allows you to set up such forwarding while still keeping a copy in your GMail inbox, and even lets you do the forwarding conditionally based on a filter. Additionally, most domain registrars have the ability to set up basic e-mail forwarding, so if you have your own domain, it’s easy to set up an address that redirects to a Sandstorm app.
When you send e-mail from a Sandstorm app, we allow you to set the “From” header either to your app’s random address or to your verified Sandstorm login address. In the future, we’d like to add the ability to attach additional verified addresses to your account. Either way, the message’s envelope return address is always the app’s address. As a result, the mail recipient may see that the message was sent “via” your server.
For more details on how to write an app that uses e-mail, and how to set up your Sandstorm server to support e-mail, check out the docs:
A key feature of Mailpile is its support for PGP / GPG encryption and signatures. Unfortunately, this is not yet supported by our Sandstorm port, as we need to do more work to get crypto right.
The simplest way we could support crypto would be to have you upload your private key into the app, to be stored on the server. This is not a good idea! In an ideal world, your private key would live only on a physical token or smart card and never even touch the storage of a real computer. Barring that, you should at least keep your key only on systems you own. If you run your own Sandstorm server, then uploading your key might be OK, but for anyone using a shared server, it’s not a good idea. We want a solution that works for everyone.
Therefore we are looking into how we can make crypto available to Sandstorm apps without sending your key to the server. We are hopeful that the nascent WebCrypto API might solve this problem, but at present the standard is still under development and there is apparently some controversy over its design. In the meantime, browser-extension-based approaches like Google’s End-To-End provide an intriguing alternative, although Chrome’s decision to kill off NPAPI may make it impossible to access hardware tokens or your local GPG agent in this way.
In any case, this is something we’ll be investigating further in the future.
By Kenton Varda - 03 Jul 2014
We have a bunch of updates for you today.
We’ve ported a number of interesting apps to Sandstorm and will begin releasing them within the next few days. First up will be Mailpile – yes, e-mail in Sandstorm! Expect a full announcement on Monday, and other app announcements over the following days and weeks.
The Sandstorm team is no longer just me. I’d like to introduce all the new faces that you now see on our front page:
We also have a couple of key advisors. These guys are contributing advice, resouces, and the occasional patch in their spare time; Sandstorm is not affiliated with their respective employers.
Jason has implemented the ability to back up and restore grains (app instances) from you Sandstorm server. Just click the new download icon on the top bar when viewing a grain. You will get a zip file containing the grain’s storage, which you can re-upload to the server (or to a different server) later on.
Sandstorm can now be installed and run without root privileges or setuid binaries. To accomplish this, we use Linux’s “UID namespaces” feature, which essentially allows other sandboxing features to be accessed by an unprivileged user.
Unfortunately, if you are developing Sandstorm apps, it is still necessary to install Sandstorm with root privileges because the dev tools rely on FUSE and FUSE filesystems cannot currently be mounted inside UID namespaces. We hope the Linux kernel will eventually add this feature.
Due to the use of UID namespaces, Sandstorm now requires Linux kernel version 3.13 or better. The installer will verify that you are ready to run Sandstorm.
Thanks to Andy for contributing much of the work on this.
We’ve now enabled a basic seccomp filter to disable some dangerous system calls. Seccomp is a Linux feature that makes sandboxing more secure by disabling system calls (OS features) that apps don’t need. A typical web server uses only a tiny fraction of Linux’s system calls. By disabling the rest, we make sure that if a kernel exploit is found in one of them, it won’t allow an app to escape its sandbox.
For now, we’ve disabled a few calls that provide complicated functionality that has been the subjects of vulnerabilities in the past, and that no web server rightly needs. We plan to expand on this in the future, eventually implementing a small whitelist and probably moving many system calls to userspace. All of this will be totally transparent to apps.
Again, thanks to Andy for getting this started.
Linux Weekly News wrote about Sandstorm last week!
By Kenton Varda - 04 Jun 2014
Sandstorm now supports apps that publish content to your personal web domain, such as blogging apps and content management systems.
While we already had an app that claimed to do this (the “Hacker CMS” app), it previously required manual configuration of nginx to actually serve the content. Users of alpha.sandstorm.io actually had to ask me to manually set things up. But as of build 0.20, you can host your site in a completely self-service way.
To try it out, install the latest version of Hacker CMS from the app list and click the “Setup DNS” button. (If you already have the app installed, install it again to get the latest version; we’re still working on automatic updates.)
Hacker CMS is still mostly a tech demo, and we’d like to replace it with ports of some better-known blogging platforms. That said, our own blog at blog.sandstorm.io is actually hosted using Hacker CMS.
Want to write your own app that does web publishing? Check out the wiki page to see how.
We’ve been hard at work improving Sandstorm’s developer experience. Some highlights include:
spk tool.Everyone who was on the mailing list as of yesterday should have received an invite to alpha.sandstorm.io by now. Please let me know if you are on the list but didn’t receive one. Sorry it took so long! We will continue sending invites to new sign-ups as long as we can handle the server load.
We are @SandstormIO on Twitter and Sandstorm.io on Google+. We want to keep the mailing list non-spammy, so follow us there for more frequent updates!
By Kenton Varda - 12 May 2014
Sandstorm employs a native-code sandbox. App servers may be written using any technology stack that runs on Linux. The app provides all of its own libraries; all Sandstorm provides is a filesystem and HTTP routing.
Up until now, porting apps to Sandstorm was a rather tedious process involving carefully figuring out dependencies and building a chroot environment. But now, we’ve written a tool that automates the process. It’s so easy that if you have a traditional web app server already running on your Linux machine, you can probably turn it into a Sandstorm app package in five minutes or less.
The trick is actually quite simple: we run your app in a special version of the Sandstorm sandbox running on top of a FUSE filesystem that detects exactly what files your app tries to open, satisfies those dependencies just-in-time, and then makes a list so that you can build a package later. By default, the tool just pulls binaries and libraries from your local system. Just make sure to test all of your app’s features in dev mode, and you should have a complete package.
Check out the porting guide for details.
Glad you asked. Obviously, pulling whatever happens to be installed on your own machine into a package is a huge hack. A serious project will probably want to do something more hermetic and reproducible. Sandstorm supports that just fine. You can configure excatly where the dev tool looks for dependencies; it doesn’t have to be your own root directory. So, set up a chroot environment in whatever way suits you, and point it at that.
You could, for example, use Docker. Once you’ve set up an appropriate Docker container for your app, point the Sandstorm dev tool at it and build a package. But it’s also possible to use the package management systems of various Linux distros directly. We didn’t want to constrain you to any one toolchain, because we know everyone has different tastes.
Many people have asked how Sandstorm is different from Docker. The answer is in the user interface. Docker is essentially a set of command-line tools for building chroot environments and deploying them. It is meant to be used by developers and sysadmins, to deploy software that might have any arbitrary number of users or, indeed, not be user-oriented at all. Docker is awesome at what it does, but what it does is actually not at all the same thing as what Sandstorm does.
In contrast, Sandstorm is a user interface for a personal cloud server. It is perfectly possible for a non-technical end user to install new apps to their Sandstorm instance and use them. Moreover, Sandstorm provides and integrated login and sharing model, so that individual apps do not have to implement this themselves. The Sandstorm platform sits between the user and the app, so when an HTTP request arrives at the app, it is already annotated with information about the user’s identity and permissions as authenticated by the platform. Eventually, Sandstorm aims to provide a user interface that allows end users to connect their apps to each other and to other users’ app securely through an intuitive UI – think OAuth, except streamlined because all the apps already share an authentication system. Meanwhile, until two app instances have been connected by the user, they are completely isolated from each other, so that you need not worry that one insecure app might compromise your whole server.