[cap-talk] Failure isolation (was: Re: images and capability security)

[Jed Donnelley]

At 01:39 PM 3/15/2008, Pierre THIERRY wrote:
>Scribit Jed Donnelley dies 15/03/2008 hora 11:47:
> > >Put the code wherever you like
> > seems to me overstated, since the authority a program has seems in so
> > many instances to depend on "where" it is.
>
>Isn't it precisely because POLA is not enforced? Kernel code compiled or
>interpreted with capability discipline shouldn't be an issue, should it?
>
>Of course, in general it would not be enforcing POLA to execute code in
>kernel mode when it's not really necessary, but it could be for
>performance or hardware-related reasons.

I think the only issue above is terminology.  I used the term
"kernel" to mean the fully trusted part of the system - part
of the "trusted computing base".  Many hardware architectures
do have a "kernel" mode that is usually used to run code
from the trusted computing base, but you are of course right
that other means could be used to set up separated domains
between distinct code sets (e.g. methods) run in "kernel" mode.

> > One straight forward approach to solving the computer security problem
> > hasn't been tried in the modern era.  This approach is that of
> > Principle Of Least Authority (POLA) computing.  Just as ship builders
> > learned that by having multiple water tight compartments in their
> > ships they could keep them from sinking if a compartment was breached,
> > computer systems can be made resilient to breaches (e.g. viruses or
> > other forms of "malware") if they are composed of multiple "water
> > tight" (mutually suspicious) compartments.
>
>If it's for a workshop about capabilities, doesn't it lack a mention of
>their relation to POLA? Something like:
>
>   Capabilities not only are a mean to achieve POLA in a both humanly and
>   technically manageable way, but they also provide an expressive
>   framework to reason about POLA formally and informally.

The above sounds nice.  I particularly like the wording about
using capabilities as "an expressive framework to reason about
POLA formally and informally."

I'm sure we can work in something like the above as we move further along.

>I like your comparison with water tight compartments. It calls for a
>graphical comparison...

Ah well, I guess I may as well include the rest of my draft
"prospectus" then for comment:
________________________
Computer security, recently ranked as tech's #1 all-time flop by 
InfoWorld, is such a well known problem that IT professionals have 
become inured to continuous computer security fire fights.  As 
InfoWorld said, "Thirty years into the personal computer era, and it 
seems like security is only getting worse."  We've gotten better at 
managing software patches, but software vulnerabilities seem to come 
up and get exploited faster than we can repair them, fast enough that 
exploiting computer security vulnerabilities is big business.

One straight forward approach to solving the computer security 
problem hasn't been tried in the modern era.  This approach is that 
of Principle Of Least Authority (POLA) computing.  Just as ship 
builders learned that by having multiple water tight compartments in 
their ships they could keep them from sinking if a compartment was 
breached, computer systems can be made resilient to breaches (e.g. 
viruses or other forms of "malware") if they are composed of multiple 
"water tight" (mutually suspicious) compartments.  In the early years 
of computer system development this was a rather popular approach to 
making systems more secure.

As the Unix and Windows paradigm of having two compartments, a "user" 
compartment (where application programs run with all of a user's 
authority) and a "kernel" compartment, came to dominate computing, 
things seemed at first to be working rather well.  Arguments were 
even made that POLA computing created more problems than it solved 
and that two "compartments" should suffice for secure computing.

Today this situation has changed dramatically.  "Things" are no 
longer working well at all.  Computer security is a serious problem 
and with the advent of the Web is getting much more intractable (e.g. 
the well known "mash-up" problem).  In recent years researchers have 
begun to revisit Principle Of Least Authority computing 
paradigms.  In particular the most popular POLA approach, the 
"capability" paradigm (where protected references to objects can be 
sent in messages) has been shown to not be subject to the problems 
that early critics had suggested.  In addition it has recently been 
realized that the popular "Object Oriented" programming paradigm is 
really just the same capability paradigm in another (language) 
context.  This realization has brought additional discipline and 
synergy to capability systems.  These developments, together with 
many other new developments in capability design such as user 
interface developments (e.g. the "power box") and underlying 
infrastructure developments (e.g. identity based controls and 
auditing), have resulted in resurgent interest in and development of 
modern capability systems.

The focus of this Capability Systems Workshop is to:

1.  bring representative researchers from past capability 
developments together with modern practitioners to bring forward 
relevant historical concepts to enhance modern work, and to

2.  bring together modern practitioners who haven't had a chance to 
meet and directly discuss capability mechanisms and systems and how 
they are being applied to solve the computer security problem in 
modern systems and networks.

We look forward to an exciting workshop that will go beyond the sort 
of sharing of security problems and patches typical of computer 
security conferences to change the computer security "game" with 
Principle Of Least Authority computing in Capability Systems.
_______________

We're still at a very early stage (working on sponsorship),
but feel free to comment.

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