Sandstorm Blog

Graphics and one-click installers for everyone

By Jade Wang and Asheesh Laroia - 10 Nov 2015

Open source web app developers build great apps. But sometimes, backend-minded developers need a little help, from making it easy for end users to install their apps to making their icons and other graphics visually appealing. To make open source web apps viable as an ecosystem, the apps must be easy to install and use, and to get the attention they deserve, they should have good-looking icons that convey the purpose of the app.

Graphics for everyone

Lately, we’ve been running an experiment – will app authors be interested in custom graphics, designed by Néna Nguyen at Sandstorm? So far, the response has been positive!

So I’m excited to announce we’ll do this for everyone who packages their app for Sandstorm: To support app authors, we are happy to help with graphics. This is on top of the one-click install for your app that Sandstorm enables, which works just as well in the cloud as it does for self-hosters (see below). For instance, Néna will make an icon for you if you need it. Check out this awesome icon set that Néna made for Wekan (kanban board):

Wekan (open source Trello alternative) icons in varying contexts. Check out Wekan on the App Market »

One-click installers for everyone

An app written using Meteor is the easiest to package – there’s a special tutorial for Meteor apps. If you input the URL of your GitHub repo below, we can even do a first-run of the packaging for you and ping you with a live demo featuring your own spk (Sandstorm package):

Meteor or not, any web app that runs on Linux can be packaged for Sandstorm. Get started with this documentation link.

Packaging docs »

Drop a line to community@sandstorm.io with any questions and we’ll make sure you succeed.

Upcoming Sandstorm meetups in Palo Alto & San Francisco

By Jade Wang - 22 Oct 2015

Live in the Bay Area or passing through? Come out and meet other awesome folks working on cool projects on Sandstorm.

We’ve got two meetups coming up on Weds., 10/28 in Palo Alto and Tuesday, 11/3 in San Francisco.

Sandstorm BBQ in the Park (Palo Alto)

RSVP link Time: 5:30 PM - 9PM-ish Date: Wednesday, October 28, 2015 (next Wednesday!) Where: John Boulware Park (street parking available) 390 Fernando Ave, Palo Alto, CA

• 5:30PM: BBQ in the park

• Dusk: When it gets too dark to eat, we can all head back to Sandstorm HQ (nearby) to hang out and have more unstructured discussions. Personally, I (Jade) want to see Citizen Four because I haven’t seen it yet. Come watch with me.

Hands-on Sandstorm Q&A (esp. app packaging), and lightning talks (San Francisco)

RSVP link Time: 6:00PM - 9:30PM Date: Tuesday, November 3, 2015 Where: ThoughtWorks HQ (near Powell St. BART) 814 Mission St, 5th Floor, San Francisco, CA

• 6 PM: If you want to talk tech details about Sandstorm, show up at six! Core developers, app packagers, self-hosters, and others will be helping each other with app packaging questions, installation issues, and more. We’ll have food!

• 8 PM: Lightning talks. Leave a comment to sign up for one!

• 8:30 PM - 9:30 PM: Socializing and informal Q&A.

Hope you can make it!

Hanselminutes features Sandstorm.io

By Jade Wang - 20 Oct 2015

Last week, Scott Hanselman interviewed Kenton Varda for his Hanselminutes podcast. Check out the half-hour interview in which they discuss Sandstorm, from big-picture vision (e.g., making the web safe for open source web apps) to how Sandstorm’s security features work.

Free, automated SSL certificates for Sandstorm self-hosters

By Asheesh Laroia - 01 Oct 2015

TL;DR: If you install Sandstorm and choose to use a subdomain of our dynamic DNS service sandcats.io, we’ll automatically set you up with an HTTPS certificate from GlobalSign. The private key never leaves your machine and is automatically rotated every week.

People who run their own servers often do it for privacy. Many of them use our open source Sandstorm software to easily run apps like document editors, group chat apps, task management, and more.

But a private server is not really private if you’re communicating with it in plaintext. So, starting today, if you install Sandstorm on your own Linux server, and you choose to host at a subdomain of our free dynamic DNS service sandcats.io, you will have free, automatically-renewing HTTPS certificates by default. That means you get privacy on the network without any hassle.

For companies and individuals who run their own Sandstorm servers, it’s now easy to secure yourself with HTTPS. Here are the steps.

1. Download and run the Sandstorm install script.

2. Choose a subdomain of sandcats.io you want to register (and tell us how to contact you to recover the domain).

3. Visit your server’s new web dashboard by clicking the URL printed out by the install script.

Sandstorm automatically enables HTTPS as part of step 2. There’s no setting up reverse proxies, no creating certificate signing requests, no waiting on a CA. Your private key is on your machine and never leaves.

Why you need HTTPS

HTTPS (also commonly but incorrectly called “SSL”) is important because the web’s original protocol, HTTP, is insecure – anyone in a coffee shop near you can see what you’re browsing or modify your traffic. This is a real threat; here’s a video of someone stealing HTTP traffic that was made as a school project.

Over the past five years, web companies like Google, Facebook, and Twitter have been switching their sites to require HTTPS. Sandstorm.io and all of its subdomains have always required HTTPS. The Chrome team is planning to show a broken padlock for plain HTTP sites. Companies that are responsible for a lot of user data have been making time to secure their sites with HTTPS.

Our search for a certificate vendor

Providing automatic HTTPS is more than just a technical problem. To be trusted, the certificates must come from a Certificate Authority that is already trusted by your browser. To deliver certificates to you, we needed to work with such an authority.

So, earlier this year, I began to talk to people at CAs. But there was a complication: Sandstorm requires a wildcard certificate to achieve some of its security properties. That is, if your server is example.sandcats.io, all subdomains *.example.sandcats.io must be covered as well. Wildcard certificates are usually expensive – an order of magnitude more so than normal certificates. And when I talked to the inspiring folks at Let’s Encrypt, I discovered that they weren’t ready to issue wildcard certificates.

I was lucky enough to find Michael Trotta at GlobalSign. He believed in our mission of making servers safe and easy for more people to run. Working together, we were able to set up a deal allowing us to offer free wildcard certificates under sandcats.io. Contracts were signed, and then it was time to write some code.

Defending against the next Heartbleed: Weekly key rotation

We want Sandstorm to require as little maintenance as possible, so that there’s no reason not to run your own server. We especially want security problems to be solved with no action on your part.

One of the biggest headaches for server admins in recent memory was Heartbleed, a bug in the popular OpenSSL library which could have revealed people’s private encryption keys to attackers.

Patching the bug is the easy part: If you have automatic updates enabled, your Sandstorm will be updated within 24 hours of any release without any action on your part.

What made Heartbleed so bad, though, was not just that systems had to be updated, but that all HTTPS keys and certificates had to be revoked and regenerated, in case they had already been stolen. This was a huge pain for sysadmins, and a huge pain for the certificate revocation infrastructure, which was not designed for everyone in the world to revoke certificates simultaneously.

To solve this, Sandcats issues certificates valid for only seven days. Your server will automatically generate a new key and receive a new certificate every week. So, any compromise of your private key “fixes itself” over time. Granted, a week is a long time to live with the possibility of an active MITM attack, but realistically it took much longer than that for most revocations to take effect after Heartbleed (if they ever took effect at all).

The result: Every Sandstorm app is secure for self-hosters

Because Sandstorm handles HTTPS, rather than the app or the system administrator, the Etherpad package in Sandstorm doesn’t need to have any kind of special integration, nor does the Rocket.Chat package, nor does the Brainstorm package, nor any other.

So take a moment and install Sandstorm now to securely enjoy these kinds of apps, or at least try the online demo.

And if you already have a Sandcats-enabled install of Sandstorm from before today, check out the documentation to enable HTTPS!

Is curl|bash insecure?

By Kenton Varda - 24 Sep 2015

Since the early days of Sandstorm, we have offered the following mechanism for installing it:

curl https://install.sandstorm.io | bash

As it turns out, a lot of people object to curl|bash. In fact, some people object very strongly to it, going so far as to scoff publicly at how obviously terrible it is and smugly proclaim that they dismissed our entire project when they saw this line. Usually, the loudest objectors claim that curl|bash is bad for security.

Sandstorm is a security product, so we want to address that head-on.

The Bogus Argument: Code Execution

I’ll admit: curl|bash certainly smells funny. To anyone with a basic understanding of Unix, the construction makes it really obvious: This command will give the named web site direct access to your system, with the ability to do anything that you could do. This feels very wrong: We should be able to install software without giving the developers full access to our systems, right?

We at Sandstorm would obviously be the first to agree that software you install should not be automatically fully trusted – that’s why Sandstorm itself runs every app in a secure, isolated sandbox by default. Unfortunately, however, traditional Unix software is always granted the full authority of the user who runs it. When you install software on Linux, no matter what package manager you use, you are giving that software permission to act as you. Most package managers will even execute scripts from the package at install time – as root. So in reality, although curl|bash looks scary, it’s really just laying bare the reality that applies to every popular package manager out there: anything you install can pwn you.

If you wish to install Sandstorm – or any software – without giving it full access to your system, you must install it on a dedicated machine, VM, or (perhaps, with caveats) user account. In fact, we highly encourage you to do so, for defense in depth. But, we know it’s more work than a lot of people want to deal with.

The Better Argument: Code Signing

Some of the objectors, though, go a bit further: They claim that curl|bash is more open to attack that other distribution mechanisms, potentially allowing a third party to replace our Sandstorm downloads with evil ones.

Of course, all content served by sandstorm.io – from software downloads to our blog – is served strictly over HTTPS (with HSTS).

Various people argue, though, that this is not good enough, and that we should be signing each release with keys kept offline.

In fact, I agree: where possible, we like to use two or more independent mechanisms of protecting against a security problem, so that when one breaks it’s not a big deal. So, as of today, it is possible to verify the Sandstorm installer from the PGP keys of various Sandstorm developers by following our “PGP-verified install” instructions.

Try PGP-verified Install »

That said, we do not think this issue quite warrants the visceral anger we’ve seen people express over curl|bash. Realistically, downloading and installing software while relying on HTTPS for integrity is a widely-used practice. The web sites for Firefox, Rust, Google Chrome, and many others offer an HTTPS download as the primary installation mechanism. It’s even the standard way to install most Linux distros in the first place (by downloading an iso from the web site). Many popular package managers, such as npm, rely only on HTTPS for integrity. curl|bash over HTTPS is just as “secure” as any of these.

Verifying Keys with Keybase

To get benefit from PGP code signing beyond what you get from HTTPS distribution, you must verify that the software is signed by the specific developer you are expecting – and to do that, you need a way to bootstrap trust in their PGP key. This means you can’t simply fetch the key from the developer’s own server. You can use PGP “Web of Trust”, but sadly few people really understand how to do that.

Recently, though, a fairly plausible option has emerged: Keybase.io. Keybase has implemented usable tools and techniques to bootstrap trust from a variety of sources, including social networks like Github and Twitter, all without trusting Keybase. It’s unlikely that an attacker could compromise all of these sources at once. Once you’ve used Keybase to verify our PGP key, then you can verify the signed packages downloaded from our servers, and actually have a higher degree of confidence that the software is authentic than you would get from HTTPS alone.

Non-security Concerns

curl|bash is not pretty, and people have raised some legitimate non-security-related concerns about it:

• If the connection dies mid-line, bash will execute the incomplete line – however, this can be mitigated by wrapping the whole script in a bash function executed on the last line, as we do. (This is actually arguably a security concern if an attacker can induce a disconnect at a chosen point, but in any case it doesn’t apply to our script.)
• Although almost all package managers allow packages to run arbitrary install-time scripts (often as root), it is far more likely that a wholly hand-rolled install script will be sloppy and harm the system. In the case of Sandstorm, we have taken care to avoid interfering with your system in any way – in fact, Sandstorm self-containerizes in its own chroot under /opt/sandstorm, meaning that for the most part it does not touch the rest of your system at all. See comments at the top of the script for more details.
• Installing software not managed by the distro’s package manager can be inconvenient for system administrators, especially those who are deeply familiar with the inner workings of their distro.

On these concerns: We hear you.

For now, we believe that having our own install scripts allows us to iterate faster, compared to maintaining (and testing) half a dozen package formats for different distros. However, once Sandstorm reaches a stable release, we fully intend to offer more traditional packaging choices as well. We still have lots of work to do!

FAQ

Does Sandstorm’s auto-updater verify signatures on updates?

As of this release, yes. (This is in addition to using HTTPS, as it always has.)

What happens if the release-signing private key is compromised?

We can rotate the key at any time. Certificates on the old key expire in about a month. The auto-updater will begin using the new key as soon as it has installed an update that is aware of the new key. We sign updates with all old keys as well so that old Sandstorm installs continue to be able to update even after key rotation.

Are the installer and updater resistant to downgrade attacks?

Yes. The installer will not install a release more than a month old. The updater will never “downgrade” to an older version. We also plan to add an alert to the Sandstorm UI if the Sandstorm build is more than a month old, which could indicate that an attacker is blocking access to the update server.