Re: [Lit.] Buffer overruns

• Previous message: D. J. Bernstein: "Re: [Lit.] Buffer overruns"
• In reply to: D. J. Bernstein: "Re: [Lit.] Buffer overruns"
• Next in thread: Nick Maclaren: "Re: [Lit.] Buffer overruns"
• Reply: Nick Maclaren: "Re: [Lit.] Buffer overruns"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 18 Jan 2005 18:32:24 +0000 (UTC)

D. J. Bernstein wrote:
>Unfortunately, in most cases, the necessary access is also enough access
>that the program can do quite a lot of damage.

I don't know about "most". Certainly there are cases like this.
They are not uncommon. But, I also contend they are rarer than when
you do nothing.

>A classic example is the Janus confinement of Netscape's ``DNS
>helper''; it turned out that there was a buffer overflow in libresolv,
>and therefore a security hole in the DNS helper, _despite_ the sandbox.

I'm not familiar with this example. Can you say just a bit more?
How do you confine Netscape's DNS helper? (I don't think I remember
trying to confine Netscape's DNS helper process, though I do remember
thinking about applying a DNS proxy taken a application firewall.)
What was the impact of the vulnerability?

>A much better approach is what one might flippantly call ``the principle
>of _no_ privilege.''

Certainly. "No privilege" is even safer than "a few privileges",
when it is applicable. But this is just a special instance of least
privilege; we have an application that doesn't require any privileges,
and so we don't give it any. Granted, it is an important special
instance.

>What about a complicated program with many input sources that aren't
>authorized to have complete control over the output---for example, a web
>browser? This program doesn't fit into an extreme sandbox. Should we be
>satisfied with ``least privilege''? No! The program should be split into
>separate programs so that as many lines of code as possible can be put
>into extreme sandboxes, leaving only a small kernel of privileged code.
>For example, the browser should create an extreme sandbox for each JPEG
>to be decompressed. The benefit is that further JPEG decompression bugs
>no longer have any impact on security.

Absolutely. I agree 100%. Decomposition for security, where you
decompose the system into components whose privilege is minimized and
where the size of the TCB is minimized -- plus some mechanism for
enforcing least privilege and isolation constraints on every component.
A much better approach to software design than "it runs with all the
privileges of the user who executes it".

You said "split into separate programs". That is one way to split
it into components and enforce isolation and least privilege. But
it is not the only way. Another way is to use a language with support
for least privilege.

A key point here is that the application is designed from the start
with security in mind. If you can choose the structure your system
in a way that maximizes security, you can do a heckuva lot better than
if you're stuck with the structure of some legacy application. If you
can change how developers build systems, you can get a lot more leverage
than if you're trying to clean up their messes after the fact.

Out of curiousity, have you looked at the E language?
 http://www.hpl.hp.com/techreports/2003/HPL-2003-222.html
 http://www.skyhunter.com/marcs/ewalnut.html

• Previous message: D. J. Bernstein: "Re: [Lit.] Buffer overruns"
• In reply to: D. J. Bernstein: "Re: [Lit.] Buffer overruns"
• Next in thread: Nick Maclaren: "Re: [Lit.] Buffer overruns"
• Reply: Nick Maclaren: "Re: [Lit.] Buffer overruns"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]