Re: On sandboxes, and why you should care

[jeff.williams at aspectsecurity.com (Jeff Williams)]

I don't really see this as two approaches.  At one end of the spectrum, you
can do security inside your code. But there are many underlying "sandboxes"
that restrict what your code is able to do. Each of these may be
configurable to be 'semi-permeable' for your app.

My opinion is people should locate the security where it's most effective
and easiest to build, configure, maintain, and operate. For example, you
could enforce access to local files in your code, in the VM, or in the OS.
Where is best?  Depends on what you're doing and your environment.  The
important point is that everyone involved understands the approach and that
it's simple to verify.

I'm confused about how your "fix the tools" approach is any different from a
sandbox. Building APIs that prevent developers from making security mistakes
is just the same.

And there's another important use of sandboxes that I think you're ignoring.
When you have to run code that you didn't develop, the end-user can use the
sandbox to protect their underlying platform. It's a question of control.

--Jeff

> -----Original Message-----
> From: Brian Eaton [mailto:eaton.lists at gmail.com]
> Sent: Friday, May 26, 2006 10:54 AM
> To: jeff.williams at aspectsecurity.com
> Cc: Dinis Cruz; Stephen de Vries; Secure Coding Mailing List; owasp-
> dotnet at lists.sourceforge.net; websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] RE: [SC-L] Re: [WEB SECURITY] On sandboxes,
> and why you should care
>
> On 5/26/06, Jeff Williams <jeff.williams at aspectsecurity.com> wrote:
> > Dinis Cruz wrote:
> > > If you do accept that it is possible to build such sandboxes, then we
> > > need to move to the next interesting discussion, which is the 'HOW'
> > >
> > > Namely, HOW can an environment be created where the development and
> > > deployment of such Sandboxes makes business sense.
> >
> > It's the "business sense" part of this that's really difficult.  It
wouldn't
> > be *that* hard to put sandbox enforcement into all libraries.  If you
want
> > to protect against XSS, put a validation and encoding sandbox into
> > HttpServletRequest.  If you want to stop SQL injection, get rid of
> > non-PreparedStatement and build in some control for direct references.
>
> Two distinct approaches to fixing software are described here.
>
> With one method, sandboxes, developers need to do a bunch of extra
> work to define sandbox policies for their applications.  Sandboxes
> don't have a great track record because it is too much work to do them
> properly.
>
> With the other method, better tools and APIs, developers do less work
> and get better results.  The reason buffer overflows are relatively
> rare in web applications is because web applications aren't usually
> written in C.  They are written in high level languages that do bounds
> checking automatically.  XSS is endemic in web applications because
> the tool sets encourage people to generate HTML on the fly.  The
> evidence is clear: fix the tools and you'll end up with more secure
> apps.
>
> Sandboxes are best understood as band-aids on buggy, broken
> applications.  Band-aids have a place, but avoiding the errors in the
> first place is more effective.
>
> Regards,
> Brian