Re: [WEB SECURITY] On sandboxes, and why you should ca re

[leichter_jerrold at emc.com (leichter_jerrold at emc.com)]

| Stephen de Vries wrote:
| > Hi Dinis,
| > 
| > I think you're overestimating the effectiveness of a sandbox in
preventing
| > common web app vulnerabilities, and you're instead focussing on the tiny
| > fraction of specific attacks that can be stopped with sandboxes.
| Well Stephen, I would argue that you are underestimating that
effectiveness :)
| 
| I also don't think that I am focusing on a tiny fraction of specific
attacks.
| Sandboxes have the capability to resolve most of the current types of
attacks
| we have today. And the ones that it is not able solve, it will make them
easy
| to detect.
| 
| In fact, I would argue that Sandboxing could actually make the 'Sandboxed
| Application' more simple, effective, cheaper to develop and easier to
audit.
| > The fundamental point of departure between our points of view is that I
| > would argue that, the crown jewels are already inside the sandbox!
| I think that you are thinking of a unidimensional Sandbox model similar to
| the one created by the Operating system between user-land process and
| kernel, or the one implemented by .Net / Java for mobile code executed on
a
| web browser.
| 
| In the solution that I am envisioning, you will have multiple Sandboxes,
one
| inside the other, separated by very clearly defined layers (the input
choke
| points / attack surface) where each sandbox is allocated privileges
| accordingly to what it needs to get the job done (principle of least
| privilege),  the amount of trust that we have in that code (Code Access
| Security) and the identity used to executed it (Role Based Security).
Other than the nesting of the sandboxes - which can't possibly last, since
trust isn't uni-dimensional; I don't always trust code A "more" or "less"
than
code B, I may trust them to do different things - what you're proposing is
capabilities under a different name.  "Running in sandbox X" is the same
thing
as "running with capability set X".

On the one hand, there's 30 years of history that says capabilities do
indeed
give you a very powerful and effective way to define and enforce security
models.  On the other ... there's little in the way of fielded systems.
Capabilities have proven to be expensive to implement and, more to the
point,
difficult to understand and manage, once you get beyond the easiest
examples.
You can't just ignore this history - you have to show that you can do enough
better that your proposal won't be marginalized or forgotten the way most
capability-based systems have.

The big advantage of sandboxes as they are usually understood is their
simplicity.  They may not be able to model everything - in fact, they model
very few things - but those few things, they can model very simply and
manage
very effectively.  In their domain, they have no real competitors.

                                                        -- Jerry