[cap-talk] The last 10% and Bitfrost (now with paper)

[Ivan Krstić]

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

On Jul 9, 2007, at 7:03 AM, Jed Donnelley wrote:
> I believe a number of systems have completed what I consider
> to be that final 10% (I could name some - but:), I think
> the issue comes down to achieving 100% and at the same time
> sufficient compatibility with legacy systems to have enough
> code running to increase market share.  That hasn't happened
> that I know of.

That's precisely what I'm saying. If we want to see capabilities in  
the real world, the final 10% of the work *is* the integration with  
(at least a selection of) existing and entrenched operating systems,  
and the derivation of a compelling and smooth transition path from  
where we are today. That's the work that hasn't been done, and is  
very hard to do. We have strong evidence from history of what happens  
when people pretend that they can avoid doing this work: exactly  
nothing. And thus, one might wonder if it's the right thing to do at  
all.

> Probably best the subject of another message.  I think the key
> is the dynamics.  That is, from what I understand of your bitfrost
> mechanism, it is able to support fine grained access (though I
> didn't see how access to files is controlled/communicated),
> but the means for managing such access (e.g. running programs
> initializing by requesting access rights) seems to me rather
> ad hoc and a bit complex (e.g. "certain bundles of rights"
> allowed by policy).

It's neither ad-hoc nor complex, but it is static (allocated at  
install-time) and not very fine-grained (the entirety of the program  
has access to all its permissions, and it isn't possible to support  
different modes of operation of the program having different  
permissions). It's far less elegant than capabilities, to be sure,  
and the mathematician in me balks at this. But it's the tradeoff I  
chose to make because it brings very strong immediate benefits and  
creates a relatively smooth transition path from full ambient  
authority towards the kind of finely-grained permission model that I  
see capabilities as representing.

> When you say that "The laptop's user can use the built-in security
> panel to grant additional rights to any application" - this sounds
> like what's been referred to on this list as a "power box".

I understood the powerbox to be an interface put forward by the TCB  
that allows the user to grant a capability (such as dealing with a  
file) to an untrusted program in a secure way -- please let me know  
if this is a misunderstanding. We implement a powerbox file chooser  
in Bitfrost. That is not what the security panel bit refers to -- the  
security panel is an interface allowing advanced users to grant or  
revoke permissions (e.g. network access) to and from installed  
software, and which the software can't request by itself.

The Bitfrost paper I'm presenting at SOUPS (at CMU, on July 20th) is  
now up:

     http://radian.org/~krstic/bitfrost_2007.pdf

and has more detail in a format that's probably easier to read than  
the requirements spec. I strongly welcome feedback, either privately  
or on-list. If any of you folks are planning to come to SOUPS or are  
in the area, let me know off-list; I'd be happy to meet up and chat  
over a beer.

> How does
> such a "security panel" communicate additional permissions to a
> running program?  Sounds like capability communication to me - by
> whatever name.

It's not. Additional permissions are granted by having the TCB mutate  
the program's permission list in a trusted permission database it  
keeps. This permission list takes effect the next time that the  
security service, which is a part of the TCB, initializes the program  
in question. In many cases, the additional permissions can be given  
to a running program by making things (files, sockets, devices)  
appear in its file space. If necessary, the program can be  
asynchronously notified of the "thing" appearing by virtue of D-BUS,  
a standard IPC mechanism, but the message that's communicated isn't a  
capability; it's merely a "this thing just appeared at this place in  
your filesystem" message.

Cheers,

--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org