Sandstorm News

Why doesn't Sandstorm just run Docker apps?

By Kenton Varda - 19 Aug 2014

We get this question a lot. Sandstorm and Docker use the same Linux kernel features for containerization. Docker already has a large ecosystem of apps. Why introduce a new app format? Why not simply position Sandstorm as a UI for Docker? Wouldn’t that save a lot of work? Why reinvent the wheel?

The fact of the matter is, Sandstorm and Docker, despite similar underlying tech, are very different platforms. Asking why Sandstorm doesn’t run Docker apps is a lot like asking why Android doesn’t run Linux desktop apps. If it’s the same Linux kernel under the hood, shouldn’t it be able to run the same apps? Well, a Linux desktop app would have a lot of problems running on Android. Most obviously, a desktop app’s UX would be all wrong on a small touchscreen. Moreover, the app would not fit into Android’s security model. It would not understand Android’s battery-saving lifecycle rules. It would not know how to tap into the unique devices (e.g. accelerometer, GPS) and opportunities (e.g. connecting with nearby devices) commonly available on phones but not on desktop.

Asking why Sandstorm doesn't run Docker apps is a lot like asking why Android doesn't run Linux desktop apps.

Running a Docker app on Sandstorm would be much the same story. Docker is designed to run off-the-shelf server-oriented Linux software and distributions inside containers. Docker’s platform, from the app’s point of view, is just Linux. From the user’s point of view, you use Docker much like you’d use traditional VMs and compute clusters; it’s just a lot more efficient.

Sandstorm, though, is doing something completely different. We are trying to manage personal servers for end users. With Sandstorm, the person deciding what software to deploy is not necessarily a developer or system administrator. They may not know how to use a command line or edit config files. They may not know what a database is, and so aren’t likely to understand why they need to set up MySQL before they can run that app they’re interested in.

This use case calls for a completely different model, just as phones call for a different model from desktops. We need to design a bunch of things differently:

• Every app must have a web interface, and they must expose all configuration options through that interface.

• Users expect their data to be organized in units of documents or other semantic objects, not in units of databases or relational tables. Apps must set up their own database and encapsulate it appropriately; the user won’t do it for them.

• Users should not have to log into every app separately, especially when the app instance already belongs specifically to them and Sandstorm is already protecting access. So, apps must integrate with Sandstorm’s unified login system.

• It would also be nice if users did not have to master a different sharing model for every app. Sandstorm supports fine-grained containers, such that every document can actually be in a separate container. This way, the platform can handle sharing consistently across all apps, by applying sharing to the containers. But, apps have to be designed for this.

• Permission grants must be expressed in a way that users can understand. A user does not know what it means to allow an app to communicate on port 25, but they do know what it means to allow an app to send and receive e-mail under a particular e-mail address. In order for such permissions to be enforceable, the platform’s security model must actually operate in terms of these semantic permissions, not arbitrary TCP connections.

• Updating an app must be a one-click (or even automatic) process. This means there must be a clearly-defined separation between the app “image” and its instance data, so that the platform is able to replace the former without harming the latter.

• Users will install malicious apps from time to time, and they must be protected from these. The regular Linux kernel interface is far too wide, and critical exploits are found too often. We must instead present a much narrower interface and force apps to adapt. See our previous post on this.

For all these reasons, a Docker app simply would not be able to run under Sandstorm without modification. The modifications needed for typical Linux web apps tend to be light, but they are necessary.

Why not at least use the container tech?

So, we’ve seen that it wouldn’t make sense to run a regular Docker app on Sandstorm. But, why don’t we still use Docker’s tech, and simply define an extra set of rules which Sandstorm apps much follow? Sandstorm would only be able to run the apps explicitly targeted for it, but at least we wouldn’t be reinventing the wheel technically, right?

Well, first of all, we do use a lot of the same tech as Docker. Namely, we use the Linux kernel sandboxing features, such as namespaces and (soon) cgroups. These features do all of the heavy lifting of containerization.

When it comes to userspace tools, it turns out that we just don’t really need anything Docker provides. Docker’s tools are designed to be highly adaptable and configurable in order to accommodate a wide range of Linux software without modification. Sandstorm, however, isn’t trying to run arbitrary Linux software. Apps already have to be adapted to Sandstorm’s environment. So, we are actually better off providing minimal configurability in order to keep the core system simple.

Setting up a Sandstorm sandbox, based on raw Linux system calls, takes only a few hundred lines of code. Using Docker, it would probably be a few hundred lines of configuration instead, while adding a huge new dependency and all the maintenance issues that come with that. We would probably regularly find ourselves needing to push features upstream to Docker which Docker doesn’t otherwise need or want. It’s a lot of burden that wouldn’t buy us anything.

We do often use Docker’s build tools in the process of building Sandstorm packages, simply because they provide a structured and reproducible way to gather an app and its dependencies into a chroot environment, which we can then package up. This is a fine option for app developers that does not affect the runtime system.

To be clear, Docker is awesome

We aren’t trying to dis Docker here. For what it’s trying to do – replace VMs with something not as horribly inefficient – Docker is amazing. We are excited to see it replace legacy IaaS solutions, and we will likely be targeting it as a way to run Sandstorm itself.

But despite an initial appearance of similarity, Docker and Sandstorm simply aren’t the same thing, and forced sharing of code for very different purposes would not benefit either project.

If you want to see Sandstorm succeed, there are 13 days left to contribute to the campaign.

WordPress on Sandstorm

By David Renshaw - 18 Aug 2014

WordPress is the world’s most popular web publishing platform, and we are excited to announce today that we’ve ported it to Sandstorm.

You can try it now in the demo or on your personal Sandstorm server.

Like the existing HackerCMS and Ghost apps, WordPress on Sandstorm lets you publish content to a custom domain. You can use it to create all kinds of web sites, including blogs, magazines, and webcomics. WordPress has an enormous ecosystem of themes and plugins, and our port grants you the power to install any of them and to modify them through the built-in editor.

Moreover, the app’s integration with Sandstorm’s login system makes it easy to collaborate with multiple authors; you can add new authors simply by sharing a link.

A few features of WordPress require us to make more progress on Sandstorm before we can support them. We would like to allow the app to make remote HTTP requests – a feature that would simplify the process of installing add-ons and importing media content – but we also want to tightly control that capability, so that an evil plugin can’t leak data. This will require the Powerbox. We would also like to integrate WordPress’s comment system with SandStorm’s web publishing, but before that’s possible Sandstorm apps need to be able to export public HTTP APIs.

Fortunately, these are things we’d like to add to Sandstorm anyway. And, of course, the more help we get from you in our crowdfunding campaign, the sooner we will be able to add them.

In any case, we think that among WordPress hosting options, WordPress on Sandstorm offers a uniquely high degree of convenience, freedom, and security.

Fundraising Updates and Corporate Sponsorships

By Kenton Varda - 15 Aug 2014

We’re now nearly 60% funded with two and a half weeks left in the campaign. Crowdfunding campaigns usually end with a spike, so we will likely exceed our goal. Plus, we have a couple of really exciting announcements lined up for next week.

If you haven’t contributed yet, now is the time to do so! For all you Bay Area hackers heading to Burning Man, don’t forget to contribute before you leave, as the campaign will be over when you get back.

If you were hoping to get us to port your favorite open source app, note that there is only one more “Choose an app” slot left. Also, there are only five more LAN party invites available.

Finally, don’t forget that when you share our campaign with your friends, you should use the special referral link in order to get credit under our referral program. (See details below.)

Contribute on Indiegogo now »

Corporate Sponsorships

We have our first corporate sponsor: draw.io.

draw.io is a powerful web-based diagram editor, and we’re excited that it will be coming to Sandstorm. The developers decided to sponsor us because we are solving a problem they have struggled with: how to allow users – especially enterprises – to run the program “behind the firewall” on their company networks. Anyone who has developed enterprise-oriented web apps is no doubt familiar with this request.

Today, supporting “behind the firewall” is a big pain. No small developer wants to deal with getting their code to run in all the diverse environments found on corporate networks. No one wants to talk IT people through setting up their server over and over again. But with Sandstorm, you just give the customer a package. They upload it to their Sandstorm server, and they’re done. Updates are just a matter of installing a new version of the package.

Does your company develop a SaaS product for which you’d like to offer an “on-prem” / “behind-the-firewall” version, but don’t have the resources to support such a thing? Consider becoming a corporate sponsor. In addition to displaying your logo in our web site and credits, we will work with you to make sure that your app runs great on Sandstorm, and that Sandstorm meets the needs of your customers. You will also become one of our launch partners for our eventual enterprise release, where we’ll help you sell your app to corporate Sandstorm users that didn’t already know about it.

Or, perhaps your company is on the other side of the equation: you’d like to be able to deploy apps internally, and would like this to be much easier and more secure than it is today. Do you find that every time you install an app on your network, you are frightened by the possibility of security bugs providing hackers with a new back door into your company? We can help with that. We are developing a suite of tools that make Sandstorm integrate well with enterprise environments. As a corporate sponsor you will get early access to these tools and dedicated help getting them to integrate with your environment.

If you’d like to become a corporate sponsor, choose the “Corporate Sponsorship” perk (the bottom one) on our Indiegogo campaign. Feel free to e-mail me ([email protected]) for details, or to work out a custom arrangement.

Referral program reminder

We mentioned this a few weeks ago, but for those who missed it:

If you refer someone, and they contribute, we’ll give you your choice of:

a) 1GB bonus storage for every $10 referred (on our managed hosting service, for one year).

b) 10% of your referral total in app store credit. Remember that our app store will support a pay-what-you-want model for open source apps, so this basically means you can donate your credit to the developers of an open source Sandstorm app of your choice.

The top referrer will additionally receive their choice of a LAN party invite (see the $512 perk) or a seat on the app committee (with $256 voting rights).

In order to receive credit for your referrals, be sure that you are logged into Indiegogo, then use the buttons under the video on our campaign page to share. These buttons will generate links that track the fact that they came from you.

Tip: Don’t spam. It’s more effective and less annoying if you speak directly with individuals who are likely to be interested. Think of people you know who love open source, value privacy, or like to tinker with their stuff and void warranties.

Sandstorm vs. Kernel Exploits

By Kenton Varda - 13 Aug 2014

A few weeks ago, I discovered a vulnerability in the Linux kernel that may allow sandboxed programs to break out of a container. The same problem can also be exploited in a different way on many typical Linux systems to gain local root privileges. I reported the problem to the kernel’s security team. Yesterday, upon release of a fix for the issue, the vulnerability was disclosed publicly (CVE-2014-5206 and CVE-2014-5207).

Docker, in many configurations, is likely vulnerable to this exploit. Sandstorm, however, is not.

To be fair, Docker is not primarily designed to be a sandbox. It is instead designed to run arbitrary off-the-shelf Linux applications and distributions in a clean, hermetic way – and at this, it excels. There are some provisions for security, but the general recommendation is to avoid deploying anything that could be actively malicious.

Sandstorm, on the other hand, cares deeply about sandboxing, and is willing trade off compatibility for security. We are happy to hide or disable whole swaths of the Linux platform that most apps don’t need, at the expense of having to develop work-arounds for the few apps that do need them. By doing this, we reduce the “attack surface” of the Linux kernel – any vulnerabilities found in the features we disabled do not affect Sandstorm. Of course, it is exactly these rarely-used obscure features which have received the least scrutiny and thus are the most likely to contain vulnerabilities.

Some examples of features we remove:

• We use seccomp-bpf to disable system calls that are not needed by apps. For example, by disabling the mount(2) system call as well as blocking the creation of new UID namespaces, Sandstorm sidesteps the vulnerability I discovered. (Ironically, Sandstorm itself relies on these very features to set up the sandbox, but apps do not need them.)
• We do not mount /proc or /sys, which are filesystem-based interfaces exposing myriad kernel features.
• The only devices we present to apps are /dev/null, /dev/zero, and /dev/urandom.
• We prohibit sandboxes from using setuid binaries to gain privileges by setting the no_new_privs process flag and other measures.

Many of these things can be enabled in Docker as well, but only by manual configuration.

All of these things potentially break some applications, but when problems do come up, it’s usually easy to work around the issue by tweaking the application code. Sandstorm’s willingness to require such changes is a key design difference from Docker. To be clear, I am not criticizing Docker’s choice – it makes tons of sense for what Docker is trying to accomplish. But Sandstorm is trying to accomplish something different.

In the future, we hope to further improve the Sandstorm sandbox by moving more kernel functionality to userspace. Using seccomp-bpf, we can actually cause some system calls to raise SIGSYS, thus allowing us to “virtualize” the call by implementing it in a signal handler. Through this, we can do anything from mocking out an irrelevant system call to implementing a whole virtual filesystem (by intercepting open(2)).

One thing in particular that we’d like to do is implement exec(2) in userspace. Parsing ELF binaries is non-trivial, and there have been vulnerabilities in the kernel’s ELF parser in the past. But, this work does not actually need to happen in the kernel. The main function of exec which cannot be performed in userspace is granting privileges to setuid binaries – but we actively don’t want that feature anyway.

Two of Sandstorm’s advisors – Andrew Lutomirski (a security-focused kernel developer) and Mark Seaborn (a member of Chrome’s Native Client sandbox team) – are experts on these issues and have been helping us work out the details. Andy actually implemented the no_new_privs kernel feature and contributed Sandstorm’s seccomp filter. He has been keeping us informed as new kernel vulnerabilities arise. Mark has implemented several Linux native code sandboxes before and is helping us design what we hope will be the best yet. (Note: Our advisors contribute in their spare time, not on behalf of their employers.)

Of course, to see any of this happen, we need your help. :) Please fund our Indiegogo campaign.

Porting Meteor apps to Sandstorm in three minutes

By Kenton Varda - 12 Aug 2014

As you know, Sandstorm apps can be written using any tech stack that runs on Linux. We have apps written in PHP, Python, Node.js, C++, Go, and even Rust.

But if you’re starting from scratch and need to choose, the easiest way to write a Sandstorm app today is using Meteor. Meteor is a modern open source web framework that makes it ridiculously easy to build high-quality, low-latency, real-time web apps quickly. Sandstorm’s own front-end is built on Meteor.

I recently gave a lightning talk at Meteor Devshop where I demonstrated porting a Meteor app to Sandstorm. The app I chose was written by independent developers with no intent to target our platform. As you’ll see, it took me under three minutes to port live on stage:

Note: The video shows the process for older versions of Meteor, in which packages had to be installed with the separate tool Meteorite (mrt). This blog post has since been updated for Meteor 0.9.x, which has its own built-in package repository.

When it comes to writing a Sandstorm app, Meteor works particularly well as a platform because it tends to produce self-contained apps. Meteor’s tools already know how to construct a “bundle” containing all of the app’s dependencies. From there, we just need to add Node and Mongo, and we have ourselves a Sandstorm package. We don’t even need to use our trick to automatically detect dependencies.

To make this even easier, we’ve written a tool called meteor-spk which automates this. We’ve also published a Meteor package kenton:accounts-sandstorm which integrates Meteor’s accounts system with Sandstorm’s unified login. Together, these mean that porting a Meteor app to Sandstorm usually involves three commands:

meteor add kenton:accounts-sandstorm
meteor-spk init
meteor-spk pack myapp.spk

Our intrepid fan Jake Weisz – who previously contributed a port of EtherCalc – has used this tool to port Meteor Blocks, a simple voxel-based model editor written using Meteor. You can find it on the Sandstorm app list now – try the demo if you don’t already have your own server.

We hope to see tools like this developed for other frameworks in the future. meteor-spk is just a simple bash script wrapping Sandstorm’s spk tool and providing a dependency bundle to merge into the package. If you’d like to contribute a similar script for your own favorite framework, let us know!

Disclosure: Jade Wang, a member of the Sandstorm project, also works for Meteor, but Sandstorm and Meteor are not affiliated.