[cap-talk] Security by safe language processing (was: Re: Memory access based OS security)

[Ben Kloosterman]

<snip> 

>>The idea of depending on the compiler or byte code verifier in a
>"language
>>based system" (LBS) is quite attractive since it might result in a
>higher
>>performance system.
>
>Higher performance in that it can avoid hardware context switches that
>are typically rather expensive?  I'm sure we all know of many ways that
>this
>issue has been addressed (with whatever success or not).  If you mean
>more
>than this by "result in higher performance", please let us know.

LBS are strongly typed  which give many benefits ( better and more
maintainable OS code , less OS bugs , better apps as all are type safe etc
etc)   , it's more a question of why should I add Hardware memory protection
when it doesn't give me a lot but costs a lot . Another question is with the
extra performance what can I do with it hence there is an opportunity cost
with Hardware protected Type safe systems ( estimated at 16% by MS research
for a web server roll) .

 Many reliability compromises HAVE to be made to commercial OS to be
accepted , eg Windows user mode  video in NT 3.51 going into the kernel in
NT4  , Mac OSX dumping all  key drivers and systems in a single blob  ,
Minix /Mach3/L3  success vs Linux etc etc 

While the performance difference may be 10% now as the core count grows ,
apps become more internet /SOA linked and Asych and as context switches
become more expensive (due to  memory getting slower and slower vs CPUs) it
is quite possible it could be 30%  on a good server machine in say 5 years
time. People pay quite a premium for a CPU that's 30% faster especially if
you can deliver a more secure and reliable system as well.

>>However it does impact the assurance aspect of secure
>>systems.
>
>I agree - below.
>

<snip> 

>
>Not only that, but the LBS system compilers and/or byte code verifiers
>must be valid against all possible inputs over a long range of time -
>perhaps all time.
>
>I know of very few systems that depend on language processing for
>security.  One example that I'm aware of was the Burrough B* systems
>(B5500, B5700, B6500, B6700).  These systems depended on their
>compliers for security.  One problem with this approach is that if
>there is a bug in a complier that generates unsafe code at any
>time and one can save that code, then it is unsafe for as long as
>it can be saved.  I "owned" a B6700 system while I was in college
>because it briefly had a bad compiler that I used to generate unsafe
>code that I was able to save.

The same can be said with non type safe  protected memory OS's , I worked
with one around 1990 and there was a compiler bug in an obscure piece of
code. However under conditions of heavy load and the user using the floppy
drive ( pretty rare in a multi user system) the system would get a stack
corruption to a sys call lose a field on the stack and would write the
floppy FAT on top of the HD fat. Took like 12 months to find and lots of
angry customers with trashed drives. 

Agree it is a pretty new field , everything since the 70s has been Multics
based but there were some interesting systems earlier there was an ALGOL
based system I think.

>
>If you use this approach of protection by "safe" language processors,
>how do you save and later execute such processed (e.g. binary/byte) code?
>Is code that's considered safe at one time still considered safe
>at a later time?  If it's considered safe at one time but mistakenly
>isn't, how does this problem get corrected?

The compile is done as part of the install process of the application. There
is like no research but I was planning on something like if its compiled it
gets written to a non writable file that can only be altered ( deleted) by
the uninstaller.  A file capability execute can be used for this file ( and
file w undelete).    Sure you can have compiler bugs but these are MUCH
rarer these days , and 99% lead to the application not executing/crashing
,one of the compilers under development has 5000 unit tests so far.
Traditional systems also have some of the same issues with compiler bugs (
especially for the Kernel) . 

It is also worth stating that the compilers tend to be simpler than language
compilers  eg the developer uses the existing C# compilers  (Mono or ms) to
generate the CIL ( MISL) the actual compile we are talking about just
converts the Assembler like intermediate code into x86  .Its trivial for
unoptimized code there is some complexity for optimized code  but you don't
get all those weird issues you get with say a c compiler. It is also worth
noting in 9 years working with C# I have never heard of a compiler bug , the
chances of such a big existing and leading to a security breach are
exceptionally low.   

It's worth comparing a bug with the compiled code in a traditional system
like I mentioned above , the solution is to rebuild the files affected and
redistribute it . With a compiler bug in a managed system you would  patch
the compiler ( the same as the OS)  , uninstall the app and re-install.
Your probably should add another state to this eg   Install -> Install and
Compiled ( Install state)  ->  Patch Compiler -> Install  ( by the
de-installer just deleing the compiled versions) ->Install and Compiled ( by
recompiling with the new compiler from the original installed assembly/byte
code ). As you can see programs are much more tightly managed as well with
meta data describing requirements .



Regards, 

Ben