sandboxing security and privacy

[Allison Randal]

On 17/08/10 13:13, Robert Collins wrote:
> 
> One thing to note is that security and privacy researches have found
> whole new ways for these apps to misbehave. Some staggering percentage
> ( I don't recall what it was offhand ) of legitimate phone home with
> personal details garnered from the phone, that the user wouldn't
> consider reasonable to be gathered and transmitted.
> 
> In some countries these apps will be illegal because they violate
> privacy laws :)
> 
> I'm very interested in how we'll ensure that this sort of bad
> behaviour doesn't sneak in.

(We'll all talk about sandboxing together at UDS-N, so I'm talking about
general possibilities here.)

It's technically feasible to wrap an application in such a tight sandbox
that it has no access to a network connection, no access to a file
system, no access to user/system data, no access to do *anything*
outside a tiny set of operations internal to the sandbox. From a
security and privacy perspective, this is good. You can guarantee that
there's no bad behavior because you've made it completely impossible.
Unfortunately, there are very few useful apps that can be developed
under such a limited feature set. Mostly it's only good for simple
games, which is why it works for Scratch.

So, sandboxing is all about compromises, about deciding which features
to allow and when to allow them, even though they could be misused. (If
you want to get philosophical about it, it's about "free will" versus
"determinism".) Once you step away from total control over the app
behavior through technology, you have to bring in human factors to
compensate: a review process, developer and app reputation, etc.

Android's approach is a one-size-fits-all model, where all apps are
treated as equal no matter what features they use, with an ad hoc
review process by community users. Their sandbox seems to be good enough
to protect the users from destructive apps (at least so far), but there
are plenty of ways to leak out private information, and no guarantees
that the app delivers what it promises. They rely on the pruning process
of user ratings and user comments. This means that you never install an
Android app without checking the rating and comments. It also means that
if you're looking for an app for a specific purpose, you may have to
wade through dozens of bad ones to find a good one. The two biggest
motivators for this approach are encouraging rapid development for
lightweight apps (easy to ship, easy to update, survival of the
fittest), and creating a process that requires very little top-down
intervention.

Apple has taken the completely opposite approach (a "Cathedral" to
Android's "Bazaar"), of tightly controlling what apps will appear in
their store. They've even gone to extremes of squashing apps that
compete with their own apps, or that offer ways around their tight
control (like Flash and Scratch). I'll ignore the business motivations
here, but the technical motivations for the restrictive approach are
security and privacy, and also user experience, making it easy to find
good choices.

Those are pretty much the two extremes for lightweight apps, and between
the two extremes are a whole range of options. One possibility in the
middle is a tiered approach, applying more restrictions when they're
needed, but allowing more freedom where it's safe. It goes something
like this:

- Apps that use no capabilities (no network connection, no features
outside the most tightly controlled sandbox) can pass with either a
light review, or user-based review. You don't need a core developer to
review an application that has absolutely no impact on the rest of the
system.

- Apps that use some capabilities are subject to a review that's
appropriate to the features they use. An app that uses networking
capability (for example, to pull in news feeds) gets careful review in
that area, but doesn't need review for file system access if it doesn't
use that feature.

- Apps that have full access to the system (no sandboxing) are subject
to the same restrictions that a regular application would be, even if
they're only short-lived, because they have the same potential for
causing damage.

The hardest part about the first two is developing the sandbox. The
hardest part about the third is that it still requires an
industrial-strength review process, still requires core developers for
the review, and may still require the full power of Debian packaging.

Allison