[cap-talk] Security by safe language processing

[Jed Donnelley]

At 10:36 PM 9/6/2009, Ben Kloosterman wrote:
> >
> ><snip>
>...
> >The first time the bug is exploited maybe somebody could get ahold of
> >a system dump and find the user code that has the problem.  At that point
> >what do they do?
>
>Check the list of fixed bugs ( like you did in the Linux example) which is
>highly likely to have been found and patch the compiler.

Fine.  Suppose that there is a patch.  You apply it to fix the compiler,
but then what about the codes that have already been compiled?

David-Sarah Hopwood has presented a solution for this issue (invalidating
code "caches"), though it has some issues.  Do you agree with that approach
or have your own?

Mark Miller (at least) argues that the costs aren't 'too' high for
this approach.  This of course requires a cost benefit analysis.

>...
>
>Every executable that is not in the TCB.

Hmmm.  Because of the language protection isn't every executable program
in the TCB?  That means (I believe, as David-Sarah suggests) that every
binary/byte executable must be invalidated.

>Binaries in the TCB could be
>distributed as native code the same as an existing OS and obviously such a
>patch requires the same care.

I need to hear how the TCB is defined in such a system.

<snip>

> >Ah.  Now we may be getting down to it.  Do you assume then that
> >applications
> >can't be imported in an executable form (e.g. over the network)?  You
> >understand I'm sure that this approach would be considered to at least
> >provide a less flexible execution environment than "traditional" kernel
> >based systems with hardware protected context switches.
>
>Yes it is a little less flexible. However for Java and .NET apps these are
>always distributed and run in non binary form and it doesn't appear to be an
>issue.

I think I need to have clarified where the trust is placed in the compiler.
Is it in the high level compiler or in a compiler of intermediate code?
The high level compiler approach seems impractical to me (too many compilers
to trust), so I'll assume the trust is placed in an intermediate
interpreter.  I guess you are assuming that there is one agreed upon
language for such a language protected system?  Is there universal agreement
on intermediate code these days?  Does everybody agree on Java byte code?
How would interpreters like Perl and Python work?

If not, there's a problem.

Let's assume there is such agreement.  Is it a known problem:

1.  How to insure that only safe code is accepted at this 
intermediate level, and

2.  How to protect and safely generate the necessarily unsafe code that is
needed for things like drivers and handling module to module transitions

??

<snip>

>...Any experience you had on the Burroughs system maybe insightful here.

In the case of the Burroughs systems they had a special language,
"Communications Algol" that was trusted to generate the unsafe binary code
that was needed for things like device drivers and to support transitions
between "modules".  It was my getting access (once) to DC Algol that
allowed me power over all Burroughs B6700 systems - as they allowed
saving and later execution of executables.  This got particularly dicey
for the case of executables from other systems (e.g. on a network).  Who
do you trust?

The people at Burroughs apparently didn't feel that they could afford
to require recompilation of everything whenever a compiler bug was
found or use of an unsafe compiler was inadvertently made available.
Of course times have changed.  Compilers are considerably more
efficient and hardware is faster.  Still ... back to the cost/benefit
analysis.

>...
> >My.  "in 9 years working with C# I have never heard of a compiler bug"
> >That's a pretty amazing record.  Still, as you can see from my example,
> >even with no bugs in the "safe" compiler, security problems with binary
> >(or I expect byte) code are possible, unless such code is somehow scanned
> >before being executed.
>
>I see where you are coming from but I think you're not considering that the
>TCB is treated differently.

Right, because it seems to any executable is in the TCB.  If not, please
describe how not.

> >Presumably they can only be compiled and loaded from safe executables on
> >the system?  If somehow an unsafe library routine (e.g. my "execute this"
> >routine) gets on the system, I guess that it will be unnoticed until
> >exploited.
>
>Assuming it is compiled and passes those checks it is ready to run , if not
>compiled it is just a piece  of data.
>It is certainly possible to force recompilation when a Compiler is patched
>invalidating the existing exes.

That does sound like David-Sarah's approach - where the case of an unsafe
compiler being made available for a time is treated like a compiler bug.
I can see how this approach works - as noted - but it does come with it's
own performance and flexibility baggage.

> > Are you arguing that once it is exploited that analysts would
> >have about the same chance to find the problem as with a kernel bug in
> >protected context switch system?  That is, they would dig into what
> >happened,
> >ultimately finding the unsafe code - perhaps loaded into an executable
> >application.  From there they would track the code (good accounting for
> >loaded executables would be needed here) until the library routine at
> >fault was found.
>
>Honestly we have little or no idea..I would say looking for unusual libs not
>signed by an authority would be the place to start , Professional .NET libs
>are normally signed. You are right regarding  accounting and in the fact
>most of these systems have strong MetaData , and unalterable processes and
>exes

I'm not sure, but I don't see this problem as substantively more difficult
than the equivalent for systems with hardware memory protection.

> >Fundamentally I think what you are depending on is that there is no
> >way to import already compiled and vetted code into your system that
> >is made safe by language processing.  Is that right?
>
>Yes all user installed apps MUCT be a standard format CIL( MISL) or bytecode
>and optionally signed. Compiled code will be secured with no direct user
>access as users will only ever get an execute reference Capability  to  the
>binary.

We seem to be agreeing on the above essence of this approach.  As noted
earlier in this message there are some costs.  Perhaps that's a good
place to leave this discussion - unless you have something to add
about defining the "TCB".

--Jed  http://www.webstart.com/jed-signature.html