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

[Jed Donnelley]

Ivan Krstić wrote:
> [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 agree completely on that.
> 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.
>   
I don't think anybody is suggesting avoiding doing such work.  There is 
a good
deal of such work going on.  We might point to Plash and Polaris as the most
obvious examples, but there are others.  I consider the Web Calculus (YURLs)
and Wideword to fall into another category of essentially new 
implementations
in new environments that don't require that large investment in backward
compatibility with legacy systems.   We can see work on object oriented 
access
control (capabilities) in both these and many other contexts ongoing today.
>   
>> 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.
>   
Smooth transitions are good.  Pragmatics are good.  My past experience 
suggests
that the simplest interfaces are likely to provide the smoothest 
transitions and be
the most practical.  For me dynamic object reference communication 
(communicable
permission tokens, call them capabilities if you like from a historical 
perspective)
are the simplest for of access control that can be effective in a POLA 
context.

I don't know how much time I'll have to look into more details of bitfrost,
particularly before the end of July, but I'll be interested to compare that
implementation with 'simple' dynamic communication of object references.
There may well be a good reason for multiple mechanisms (e.g. a static
mechanism coupled with a dynamic one).  Even with a supporting underlying
ocap communication facility there is still a need to provide initializations
for running programs.  There has been considerable discussion on this list
about that topic.  When I hear about the "static", per-application access
initialization that you suggest, for me it falls into that category - 
though of
course I could be way off.
>   
>> 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.
I think that's pretty much right - though of course the powerbox isn't 
an interface provided
by the TCB, but rather just an interface provide by a program that 
typically has access to
all a 'user's authority (e.g. somewhat like a shell) - running on top of 
a communication
facility that supports dynamic communication of permissions (e.g. like 
communicating
file descriptors through Unix pipes as Plash does).
> 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.
>
>   
See my comments above how this to me sounds like the 'initialization' 
problem that
we've often discussed on the cap-talk list, though perhaps not using a 
simple dynamic
object communication underlying model.
> 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.
>
>   
I'll see what I can do.  I hope to attend the Usenix HotSec workshop 
with MarkM
to participate in the discussion of the implications of Horton for 
general OO access
control (ocap/capabilities).  That meeting is on August 7.  I'm sure I 
won't be able
to attend the Symposium On Usable Privacy and Security at CMU just a few 
weeks
before (we all have to get real work done some time ;-), but I look 
forward to hearing
about the response to your work.
>> 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.
>   
It isn't a 'capability' because it doesn't appear in the running 
program's file system
as part of a message receipt?  Does this mean that it is somehow 
separately named,
resulting in a separation of designation and authorization?  I'm sure 
you are well
aware of some of the difficulties that can arise due to such a 
separation.  Still,
I hope it works out for you and we all keep moving at least generally in the
same direction.

Sincerely, Jed  http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070709/3316dd53/attachment.html