[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Summer of Code
From:       "Mark S. Miller" <markm () cs ! jhu ! edu>
Date:       2007-02-27 4:34:55
Message-ID: 45E3B4EF.6060605 () cs ! jhu ! edu
[Download RAW message or body]

Ivan Krstić wrote:
> Bitfrost uses real container-based VMs,

Hi Ivan,

I've been curious about what the Bitfrost spec means by "virtual machine". 
 From a brief web search on "container-based", I found 
<http://www.cs.princeton.edu/~mef/research/vserver/paper.pdf>, which explains 
the Linux V-Server, comparing it to Solaris Zones and others. This 
OS-virtualization is indeed a lighter weight approach than the 
machine-virtualization of VMWare or Xen, and plausibly much more secure than 
user-mode Linux[1] or the account-based approach taken by Polaris. Are you 
building on V-Server itself? Are you doing a new container-based Linux VM?


> so I think I could reasonably
> get away with calling it a capability system at the granularity level of
> the entire program. If the goal is to do capabilities at the granularity
> level of the subcomponents of a running binary, not only do you have to
> write black magic kernel support for it, but programs need to be
> explicitly (re)designed to run securely on the resulting platform. This
> is a worthwhile goal, but one that I see as rather far off in the
> future, which is why I chose the pragmatic approach for Bitfrost.

Applying protections at the granularity of separate programs is a fine 
starting point. Polaris gains much benefit while operating only at this 
granularity. But Polaris is not a capability system.

Granularity aside, I'm quite curious about how capability-like Bitfrost is. 
Solaris Zones and Linux V-Servers do *not* interact by capability rules. What 
is the mechanism by which Bitfrost's virtual machines interact? What is the 
semantics of this interaction? How does a Bitfrost virtual machine come to be 
able to affect the world outside itself? How does one Bitfrost VM grant 
permissions to another Bitfrost VM? How is a world of these virtual machines 
presented to the user so they are not faced the complexities that VMWare or 
Xen users currently face?

I have read through the current "Bitfrost spec" document at 
<http://dev.laptop.org/git.do?p=security;a=blob;hb=HEAD;f=bitfrost.txt>. I 
like the stated goals. But beyond enumerating goals, I didn't get it. I didn't 
feel like I understood what you are actually planning or proposing to do. Any 
clarification would be greatly appreciated.


I am hopeful that OLPC will be *extremely* important. It seems amazingly well 
positioned to change the world in a big way. To realize its potential, OLPC 
doesn't have to get security right immediately, but it must avoid getting the 
security fatally wrong, and it must avoid painting itself into an ACL corner. 
Your statement of goals gives me hope that you may succeed. Best of luck!


[1] I do not understand User-mode Linux well enough to criticize its security 
based on my own knowledge. This statement is based on the opinion of people I 
have high respect for. But I here relay this opinion without permission, and 
therefore, currently, without attribution or substantiation. If this opinion 
is controversial, perhaps others can comment?

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

[prev in list] [next in list] [prev in thread] [next in thread]