[cap-talk] Concrete application, WebCVOS (was: Selling capabilities programming)

[Jed Donnelley]

At 07:58 PM 7/18/2007, Mitsu Hadeishi wrote:
> > ...All requirements on capabilities systems
> > need to be justified in terms of efficiency in
> > translating user attention to limits on the misconduct
> > of malicious software  and limits on the misconduct of
> > buggy software processing hostile data.  I am not seeing
> > any such justifications on this mailing list.
>
>Hi, I've been lurking on this list for a while, but I felt like
>writing a few contributions here.  First of all, I agree completely
>with you, James, that concrete use cases (from a user standpoint)
>ought to be the central factor in deciding to what extent a specific
>set of features ought to be central to a system.  This is a lesson
>that is frequently overlooked.

Certainly the primary concrete use case that I've been
focusing on has been discussed many, many times on
this list, but perhaps not every time new users are
added.  It has become perhaps a bit tired referring
to it simply as POLA, so let me make it more concrete
again for this discussion.  I see this as part of
my work on the general ocap context for the Horton
presentation and discussion at HotSec:

Presently I am afraid every time I find myself in
a position of running new software on my computers.
Afraid if I run Adobe reader or iTunes or Real's
video rendering.  Afraid if I run Turbotax or
Quicken or Powerpoint.  Afraid if I run a Web
browser or an email program or an IM program...

I am afraid for this very legitimate reason:

Law #1: If a bad guy can persuade you to run his
program on your computer, it's not your computer anymore.

I have no idea if there might be some "bad guy"
among the programmers of any of the above software.
This is a legitimate fear that limits the market
that I can get my software from.  I certainly never
run the odd Christmas card .exe that people used
to send.

An important (the most important?) concrete use
application of ocaps is the elimination of this
fear and the consequent opening of the market for
software.  Since I've been clarifying potential ways
to do this for some time on this list, let me
suggest my latest thinking as a possible concrete
realization and let people criticize it.

What I imagine is what might be called a
"virtual OS" that can be run in a single
program (may have to take over a bit to
get what amounts to a hardware VMM - let
me leave the details of that out for now)
on computers such as our current PCs, and
this program (think of it as an extended
or slight variant on a Web browser if you
like) can run other applications that can
be downloaded from the Internet in a pure
ocap execution environment.

This is much like a Java sandbox, but it
isn't Java (real hardware instructions),
and the system call environment is pure
ocap, with the capabilities being
network capabilities as data, many of
which will be made available by the
programming environment from my local
system.  The topics that JonathanS and
I have been discussing (capability
protection and confinement) apply, but
I'll not focus on those here.

Here is how the concrete use scenario
goes.  Next year instead of getting
Turbotax on a CD or downloading an
installation program from the web
and installing it, I point my WebCVOS
(just to have a name - Web Capability
Virtual OS) to the Turbotax site and
instruct it to download the Turbotax
application designed to run in this
environment.  As part of the download
it creates a directory for Turbotax
files, and under instructions from
the download sets up initialization
that will give the Turbotax application
running in this environment access to
the directory with these files - let's
say read/write - as part of it's
initialization as Web ocaps as data
(actually pointing back in most cases
to the environment program itself that
will supply access to these objects).
Since this is a new directory for
Turbotax's use is separate from anything
else I care about, I don't even need
to be asked for approval to allow this
much initialization.

A default part of such initialization
will provide ocap access to keyboard/mouse
input and window management (glossing over
some details), which I'm also not much
concerned about from a security (fear)
viewpoint - with the usual caveats about
not allowing snooping on keyboard input,
viewing other window output, etc., etc.

Now the 'application' is installed.  It has
read-only access to the Turbotax site.  If
it chooses to download more application
code and perhaps write it to files in it's
directory, fine.  What it has no way to do
is to even ask for access to any other part
of my system or the Internet or anything
else for that matter, except - of course
for the power box.

If it needs access to some other file
(e.g. last years tax return), it can
ask through a power box.  I can of course
grant such access (e.g. RO) or not.  If
I grant any such access the running
application receives it as an ocap
which it can store in it's directory
if it wishes.  I can of course revoke
this access at any time if I so choose.

If it needs some write (send) access
to something on the Internet - it can
ask.  If I am convinced, I can grant it
access to as little as one address.
This is of course a big giving up of
control (it can in principle send
anything it wants out), so I think
I would really need to be convinced
about the value to me of granting
the program such a capability.

I hope you get the idea.  I'll be
interested to hear any thoughts.  I'm
finding the discussion with JonathanS
(mostly) of value in determining what
limits there may be to the protection
that can be provided by such a system.

To me the value of this concrete
application is clear - the greatly
reduced fear and consequentially
great expansion of the opportunity
for drawing on a wider variety of
software sources.

Perhaps I should just say a bit about
backward compatibility/legacy issues.
Of course feel free to ignore if you
are already incensed about how ludicrous
you regard this proposal...

I don't see much difficulty in developing
Window and/or Unix compatibility libraries
that would run in this environment and
make much of their respective environments
appear to be there.  To me this is a bit
like the libraries that support cygwin
or any other compatibility package.  Since
the access to the "outside" world is fully
ocap (one system call - "invoke"), the
program supporting the environment, "WebCVOS",
can make available through capabilities
that it supplies any facilities that seem
appropriate.  Of course the simpler it is
the more we'll be able to trust it.  One
can easily imagine mechanisms to "crack"
this WebCVOS, but with the greatly reduced
interface (the one "invoke" call) I give
it a better chance of avoiding being hacked
than Windows or Unix.  As long as it is secure
then I can be confident that applications
I run under it can be limited to POLA.

Of course in thinking about this environment
it is really very much like NLTSS except
provided on top of Windows and/or Unix
and with confinement.

One thing that most appeals to me is the
opportunity to "compose" facilities made
available through network ocaps.  E.g. I
can receive such in email and make them
available through this WebCVOS powerbox
to any application.  The application can
store such and compose them to my benefit
(or detriment if they can), subject to
my revocation.  Since any such remote
objects are serviced remotely, they
provide no significant attack surface
to attack the WebCVOS.

Of course Horton may provide responsibility
tracking in such an environment, but I guess
that is then taking this concrete application
a bit too far for now...

>I believe the principles of capability security can be used in
>systems ...
>
>Thus, I would encourage people to think of capability security as an
>approach that can be used at many levels...

Above you have my thinking on a concrete application.
I believe the reduction of legitimate fear
(defeat of Microsoft's first law) and the
opening of a larger market for software is a
huge win - concrete application.

I'll be interested to hear the thoughts of others.

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