By Kenton Varda - 10 Jun 2015
Google’s Android team has announced that in Android M, users will be prompted to grant permissions to apps at the time the permission is used, rather than an the time the app is installed. That’s great! This will make it much easier for users to understand how permissions are being used and allows them to perform a “line-item veto” without uninstalling the whole app. This puts much more power in the hands of users, as it should be.
Unfortunately, permission to access the network is now going to be granted totally automatically. Is this the right thing to do? Android Police argues that it’s “probably okay”. But some of the arguments feel unconvincing.
At Sandstorm, we have some strong opinions on this. Sandstorm, like Android, seeks to run apps in an environment that enforces a strong permissions model (but Sandstorm targets servers rather than phones). Part of Sandstorm’s security promise to the user is that apps are “confined”: they have no communication with the outside world unless and until the user grants them permissions. This promise is probably the most controversial part of our security model, but we continue to believe it is the right thing to do. (Note: Sandstorm’s confinement guarantee is not fully enforced at this time, as we have intentionally poked holes in the sandbox during alpha testing in order to work around missing features. But, these will be closed over the next few months.)
So, let’s take a look at the arguments the Android team is making for abandoning confinement.
The Android team apparently argues that being able to disable an app’s network access is not very important as long as all of your sensitive data (say, contacts) is guarded behind other permissions checks. If you don’t want the app to upload your contacts to the developer’s server, they say, don’t give it permission to see your contacts.
This argument, to be frank, makes no sense. What if I want the app to organize my contacts (e.g. because it is a contact manager app), but still do not want it to upload my contacts to the developer’s server? The Android model seems to say that I must treat the app and the developer as one entity, which is unfortunate, but perhaps consistent with the SaaS model that Google is used to. We’d like to do better.
In fact, proper confinement allows us to do something rather magical which the Android team seems to be overlooking: If I can confine an app, then I can safely load sensitive data into the app even if the app is malicious! This in turn makes it much easier to feel comfortable using apps from random developers I don’t know. It also means I don’t need to worry too much about bugs in the app.
Moreover, even if I don’t plan to give the app any other permissions, I may still worry about whether the app might consume my resources in order to participate in a DDoS attack, anonymizing proxy service, or bitcoin mining rig behind my back.
The Android team argues that an app can always use Android Intents to ask Chrome to open the developer’s web site, encoding my sensitive data as a URL parameter, thereby leaking my data. Because this is possible, they say, trying to provide confinement is pointless.
First, two simple responses:
More importantly, though, if intents allow trivial data leakage, perhaps that is a problem in intents. Perhaps the user needs to be asked whether or not they really want to open that link.
But would that be annoying? I actually don’t think it would be too bad. People who have installed multiple browsers on Android today are, in fact, already protected: Android prompts the user to choose which browser to use. The user can, at this point, press “back” to avoid the interaction altogether. Perhaps Android Intents should in fact prompt the user to choose an app even when there is only one choice: in fact, there is always a second choice, which is “don’t open this at all”. Meanwhile, this interstitial lets the user know that they are switching apps, which may help them be less confused.
I think that the real reason the Android team doesn’t want to implement internet access as a permission is because getting the UX right is legitimately hard. Pushing an “allow/deny” prompt in the user’s face on the first packet sent is genuinely annoying and not very helpful to the user, and the Android people aren’t feeling particularly excited about trying to develop something better, perhaps because they think that users don’t care (a popular but incorrect assumption).
I believe there is a better way: Instead of prompting the user to allow or deny internet access as a whole, prompt them for individual capabilities that the app needs, and then merge that prompt with a choice that they were already making. It turns out that most security decisions, if you look carefully enough, are in fact paired with some functionality choice. If you merge the choices together, then one of two things happens:
Let’s illustrate with some examples:
Android actually provides a contact picker UI which can be invoked via an intent. When used, instead of requesting permission to your whole contact list just to show you a picker, the app asks Android to display the picker, and receives permissions only to the contacts you choose. To the user, the UX is exactly the same (they choose whom to invite), but there is no security prompt, and yet illegitimate use is blocked. Hooray!
Sadly, many apps choose not to use this built-in picker, perhaps because developers think they can draw a prettier picker themselves and that the user doesn’t care about granting the extra permission. In my opinion, the Android-provided picker should be improved and the contacts permission discouraged – or disabled – in order to push developers away from drawing their own pickers.
What if the platform implemented a “server picker” UI, so that the mail app merely says “I need a server address, username, and password”, the platform displays a form to the user, and then the requesting app not only receives information back, but also receives permission to access specifically that server? The user is, again, only doing something they had to do anyway: choose their server. No security prompt was ever presented, and yet the security ends up correct. (Plus, if you take it a step further by having the app proxy requests through the platform, then the platform could in fact hold on to the user’s mail server password, preventing the app from accidentally leaking it.)
In this case, Android actually has an account management system and picker UI which handles the first two choices as one unit, exactly as I’d like. But I am not allowed to choose which server to use – I am locked into Google’s server. What if there is a third-party service – or open source server app – which I would like to use which has implemented a Google-calendar-compatible API? As long as the API is implemented correctly, I ought to be able to make apps use the alternate service, rather than be locked into Google.
If the security choice is mandatory anyway, and it is done in a fine-grained way (i.e. the request is for a specific server, rather than arbitrary network access), then the freedom choice can naturally be provided at the same time, without the app even knowing about it.
All of the examples above will be supported through Sandstorm’s “Powerbox” UI. In general, the Powerbox is an arbitrary picker which can be invoked by any app and extended by any app. Underlying the Powerbox is the Cap’n Proto RPC protocol, which naturally represents capabilities (as granted by the powerbox) as RPC object references, automatically taking care of permissions and message routing.
We have been laying the groundwork for the Powerbox for some time. The infrastructure is ready, and we are now working on giving it a UI. This will happen gradually over the next couple months.
Even without the Powerbox, Sandstorm is highly usable today. Try the demo, install your own (it’s open source), or preorder hosting.
By Asheesh Laroia - 18 May 2015
Sandstorm is open source server software that makes it easy to install web apps like Ethercalc or Let’s Chat. But that’s not much use if your server doesn’t have a name, and setting up DNS correctly for Sandstorm has until now been a complicated, fiddly process.
That’s why today I’m announcing sandcats.io, a free dynamic DNS service for Sandstorm users. It now takes 120 seconds to go from an empty Linux virtual machine to a working personal server, DNS and all.
The Sandstorm install script asks you what subdomain you want; if you type alice, then your server is online at alice.sandcats.io.
It’s as simple as that. Check out this 30 second ASCII screencast.
I say it solves DNS for Sandstorm users because the sandcats.io service handles all the following complications:
Domain provisioning. You type the name you want for your server while running the install script.
Wildcard DNS. Sandstorm needs wildcard DNS because, with its security model, each session of each app runs on a unique unguessable subdomain. This protects against most cross-site request forgery attacks, for example. Sandcats.io provides wildcard DNS; this also means that any time a user runs a new app on your personal Sandstorm server, DNS is already configured.
Automatic updates. Every 60 seconds, your Sandstorm server sends a small UDP message to the Sandcats.io service. If your IP address has changed, the service replies with another short message. Upon receipt of that, your server sends an authenticated message, and sandcats.io updates its records. Our DNS records have a 60 second TTL, so if your IP address changes, it will propagate out within two minutes, and you never had to lift a finger.
Domain recovery. If you lose your authentication keys, you can recover
the domain by typing help
into the Sandstorm installer.
I’d love to hear your feedback; I’m asheesh@sandstorm.io.
The code is open souce, and you can read more in the technical documentation, but what I really recommend you do is try it out.
The Sandcats service is optional. If you already have a domain of your own, you can join the many other people actively running Sandstorm on their own domain.
If you know you want to go it alone, the install script allows you to opt out and configure DNS yourself.
Moreover, if you start out with a
sandcats.io sudomain, and you decide you want a little more personality to
your server, you can reconfigure it at any time. Look for your server’s
sandstorm.conf
file.
Sandstorm exists to make it easy to run web apps like Etherpad, HackerSlides, Let’s Chat, and others as easily as you install apps on your phone. If that’s something you want on a server for you or your organization, I hope you install Sandstorm right now.
By Asheesh Laroia - 14 May 2015
Last Thursday, May 7, I helped organize the first event of the new Sandstorm SF Bay Area meetup group. The event was a Project Night, modeled after the Boston Python Project Nights that Jessica McKellar, Ned Batchelder, and I helped start a few years ago.
Project nights are unstructured chances for Sandstorm developers & users to work together, mentor each other, connect socially, teach, learn, or do whatever else it is Sandstorm users & developers want to do together.
I started with a brief introduction to Sandstorm, to ensure new people had some context.
After that, we laptopped and chatted. Here are some highlights from photo album.
Thanks to Jack Singleton and Thoughtworks for hosting the event, and to Ti Zhao for the wide panoramic shot.
If you’re near the San Francisco Bay, get notified of the next event and join the Meetup group!
By David Renshaw and Kenton Varda - 05 May 2015
We sometimes describe Sandstorm as: “Like Google Docs, except open source, you can run it on your own server, and you can extend it with apps written by anyone.”
Sandstorm is all about collaboration – we have apps for real-time collaborative document editing, chat rooms, even collaborative music streaming. Collaboration, of course, requires access control. Sometimes you want some people to be able to edit a document while others can only read. Up until now, Sandstorm relied on each app to implement its own access control model, and many simply did not. For example, with Etherpad on Sandstorm before now, you could only share full write access.
Today, we’re introducing Sandstorm’s new built-in sharing model. With it, apps can define a set of “permissions” (like “read” and “write”) which make sense for the app, and then Sandstorm itself will present a user interface by which the user can grant these permissions to other users. Since Sandstorm is designed to support fine-grained app containers (where, for example, each Etherpad document runs as a completely separate instance of the app in its own container), Sandstorm can implement this access control model at the container level, freeing the app of most of the work. The app need not track users itself; Sandstorm will tell it (e.g. through HTTP headers) exactly which permissions the current user has, so all the app needs to do is implement those.
Moreover, Sandstorm implements a radical capability-based sharing model, which emphasizes the importance of delegation. Under our model, if you have access to a document, you can share that access with others, without requiring the document owner to intervene. This is important, because any obstacle to delegation is an obstacle to getting work done. Marc Stiegler said it best:
The truth of the matter is: delegation cannot be prevented. The further truth of the matter is: we do not appreciate how fortunate it is that delegation cannot be prevented. Because in fact, delegation is the cornerstone of civilization. - Marc Stiegler
More on this in a bit, but first let’s look at how it works.
Consider the GitWeb app. With the new sharing features in place, after Alice creates a new repository she can, for example, share read-only access with Bob and share read/write access with Carol.
Then, in turn, both Bob and Carol can reshare the repo to other users. If they both share their full access to Dave, then Dave gets read/write access.
If Alice now unshares with Carol, then Carol loses all access and Dave loses write access. Dave continues to hold the read-only access that he received from Bob. Carol’s share to Dave continues to exist, but it no longer carries any permissions, as Carol herself no longer holds any permissions.
Throughout this whole interaction, the app itself has no need to keep track of users! It only needs to know how to filter requests based on permissions. Teaching GitWeb to do this was easy, requiring only a few small changes in configuration files. The app remains dead simple. The only data that it stores is the Git repository that it hosts. There is no in-app user database.
Apps have complete control over the meanings of permissions. While “can read” and “can write” permissions will be sufficient in many cases, some apps, such as Groove Basin, might support a much wider range of permissions. In our updated Groove Basin package, sharing carries such diverse permissions as “can listen,” “can control the audio stream,” “can upload music,” and “can edit tags and delete music.”
Traditional access control is accomplished using “access control lists” (ACLs), in which a document owner (Alice) maintains an ACL for the document specifying exactly who has access (Bob and Carol). In many systems, Bob and Carol cannot directly add a new person (Dave) to this ACL – they must ask Alice to do it. Usually, this is treated as a security “feature”.
Preventing delegation is not a feature. It provides no security benefit, and it creates obstacles to legitimate work.
For example, say Alice has asked Carol to update the document to add some data that Carol has collected, with a deadline of 6PM. Around 4PM, Carol realizes she won’t have time, so she asks her assistant, Dave, to do the work. Unfortunately, Dave doesn’t have access, and Alice is unavailable because she’s in a meeting. Now what?
Here’s what inevitably happens: Carol copies the whole document into a new document, and then shares that with Dave. Later, when Dave is done, Carol copies the contents of the new document back into the original, overwriting it.
Or, worse, Carol just gives Dave her password.
What just happened? Carol bypassed the access control that prevented delegation to Dave! In fact, she did so trivially; no “hacking” required. It is obvious, in fact, that there is no technology which would prevent Carol from delegating access to Dave, except to cut off all communications between Carol and Dave, which would be silly. So, our security “feature” actually provided no security benefit.
With that said, what Carol did was annoying and error-prone. It took time, and the document could have been damaged, especially if someone else were editing at the same time and had their changes overwritten. It would have been much better if Dave could have simply had direct access to the document.
So, that’s what Sandstorm allows.
There is an objection to unrestricted delegation which has some merit: preventing delegation can help guard against accidental leaks. For example, I might share a sensitive document with a coworker for review, but I might not trust that my coworker really understands the sensitivity of the document. I trust my coworker not to violate my wishes, but my coworker might not understand that I don’t want them to reshare. I’d feel a lot more comfortable if I can simply prohibit resharing. Yes, they can always go out of their way to get around any barrier I put up, but hopefully it will be obvious to them that they shouldn’t.
This is a valid point, but solving it via the heavy-handed ACL model is overkill. As a user, what I really want is not a draconian security wall, but two things:
Sandstorm aims to provide both of these:
For enterprise users, we will further develop features that allow system administrators to set policies and audit access across an organization.
Many users may never need these features. That’s fine – the basic sharing interface works intuitively without requiring you to understand “sharing graphs” or “policies”. But for those who need it, especially in a business setting, these features will be invaluable.
Sharing is a new feature and we still have lots of work to do on it, but the initial version is already live. If you want to try sharing but have not yet set up your own server, you can use the demo. We’ve already enabled nontrivial permissions on GitWeb, Groove Basin, and Etherpad, and more app updates will be coming. Better yet, try writing an app that takes avantage of the new features. Enabling apps to easily support sharing is just one more way that Sandstorm makes open source web apps viable.
By Drew Fisher - 04 May 2015
Hi! I’m Drew Fisher, and I’m thrilled to announce that I’m the newest sandcat on the block! I’ll be working on various parts of Sandstorm’s software platform, developer tools, and user experience.
A little bit about me:
One of the reasons that I find Sandstorm so compelling is that I care deeply about security and privacy, but also about making delightful user experiences. These goals are frequently in conflict with each other, but Sandstorm is remarkable in that its design enables us to provide real security – isolation between orthogonal concerns, sandboxing, protections against whole classes of attacks – while also making that security useful and meaningful to users, by staying out of the way of user workflows, minimizing cognitive load, and capturing user intent instead of asking tons of questions.
I’ll be at the first Sandstorm Meetup this Thursday, May 7, in San Francisco, so if you’re in the area, come visit the Thoughtworks office at 315 Montgomery from 6pm - 9pm! I look forward to meeting some new faces!