[cap-talk] Horton at HotSec '07: How broadly object/capability?

[Jed Donnelley]

James A. Donald wrote:
> David Hopwood wrote:
>  > We cannot blame anyone outside the capabilities
>  > community for our collective failure to produce a
>  > capability OS that is complete enough to run even a
>  > few basic demonstration apps on a PC.
>
> The classic explanation of how a capabilities OS would
> work contrasts cp with cat, and a file chooser dialog
> box with a file chooser powerbox.   It is an explanation
> of how to do unix right - how to have something very
> similar to linux + gnome, but innately secure.  So where
> is something very similar to linux + gnome, but innately
> secure?
>   
If you had asked the above question in 1980 (using the equivalent best
computing systems facilities of the time) I could have answered you easily.
We had many such similar systems.

There are no such systems today - as you well know.  I believe the reason
there are no such systems is that during the 1980s an influential group of
people (mostly from the defense community) decided that communicable
permission tokens (capabilities) were way too dangerous.  They couldn't
be trusted.  They worked actively to block, defund, and generally to
make sure that no such systems prospered.

Then in the late 1980s and early 1990s when the home computer and
Internet explosions took off we effectively had a huge inflationary
period (analogous to the early universe) where the system architectures
in place at the time were frozen into place (Unix and the following
Windows and X-Windows being prominent examples).  What we have
today is the legacy of that history.
> If the objective is to have something very similar to
> linux + gnome, but innately secure,
The objective (mine anyway) is POLA.  That is to be able to run
programs with just the permissions they need.  To be able to dynamically
communicate just those needed permissions (e.g. but not necessarily
as object references - capabilities - I don't care about the technology,
just the results) to programs both at their initialization and dynamically
as they run.

Such an environment will indeed be more secure.  I wouldn't call it
"innately secure" since of course a program misbehaving can still
misuse the permissions it does have.  Still, the gain I believe will
be huge.  In my opinion the 'only' difficulties are the practical ones
of transitioning legacy systems - as huge as these practical difficulties
are.
> you want to be able
> to reuse as much linux and gnome code as you can - plash
> on steroids with a cap shell in place of bash shell.
> (Bash shell would run inside a plash sandbox, cap shell
> runs above the sandboxes, and can interactively create
> sandboxed bash shells with particular ambient
> capabilities.)  The cap shell should be as much like
> bash shell as it possibly can be, and the install time
> specification of plash sandboxes needs to be integrated
> with something very like Synaptic Package manager -
> which integration is a large part of what Bitfrost is,
> though Bitfrost is very specifically written for an
> alarmingly minimal laptop.  If the user installs a
> standard linux program outside the package manager, he
> can do it but then faces the alarmingly nerdly task of
> specifying plash sandbox rules, for only programs
> specifically written for the capabilities OS can run
> outside a sandbox.
>   

The above is at least moving in what I consider to be the right direction.

Go for it!  Let's get past the mostly theoretical concerns about MAC/MLS,
covert channels, and tracking (auditing/logging, etc) responsibility for
actions by person and get on with implementing a POLA infrastructure
(I suggest one that allows object reference communication - capabilities,
but really I'm open to anything that will work) for running our programs
so we can get out of this horrific situation were we are in constant fear
of running something that will damage our systems and generally our
personal interests (e.g. financial, etc.).

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