Re: [ANNOUNCE] Introducing Codezero

[Bas Wijnen]

On Sun, Jul 26, 2009 at 11:57:54AM +0100, Sam Mason wrote:
> On Sun, Jul 26, 2009 at 08:13:09AM +0200, Bas Wijnen wrote:
> > While the provided links may certainly help, I think the biggest
> > "conflict" is that Bahadir seems to be talking about unprotected
> > capabilities (but correct me if I'm wrong), while most people here
> > implicitly mean "capability" to be kernel-protected.  What I mean by
> > protection is that it is impossible (not just very hard) for a thread to
> > guess a capability, because when invoking, the kernel checks if you
> > actually have it.
> 
> I was under the impression that when you have protected capabilities
> you can make more guarantees about the ways in which capabilities can
> propagate.  In most practical terms, guessing an arbitrary 256bit number
> (say) is going to be just as secure as protected capabilities---you're
> looking for bugs in either system and you're not going to be able to
> brute force either.

Yes, that's the main point indeed.  Although passing 256 bit extra for
each capability may also be significant overhead.  But the important
difference for security (as opposed to performance) is that kernel
protection means that protected data can also be passed: a piece of data
which is inserted by the server before it handed out the capability, and
cannot be changed by the client; using the capability means passing the
protected data.  This is very useful.  Otherwise, the server would need
to have an array of random numbers mapping to its resources, or
something.  Because just putting the data in the capability would not
work: that can be changed by the user.

The ability to contact a thread is one thing you need a capability for.
But to contact a thread with a certain request (and no other) is also
something capabilities should allow for.  That is hard to implement
without kernel protection, AFAICS.

> In protected systems you can do things like garbage collect unreferenced
> objects, which would not be possible in an unprotected scheme.

I like reference counting better than garbage collection, but that too
is impossible without kernel protection.

> > This effect does indeed inflate the kernel, but it also has some good
> > effects on security, which cannot be achieved without kernel support.
> 
> I tend to interpret this as follows; if every piece of code ends up
> having to implement their own capabilities then that's going to be
> significantly more code written and potential for bugs.  Putting
> capabilities into the kernel allows some very useful design goals that
> would otherwise be difficult.

Yes, my statement was a bit too strong.  Without kernel support you can
have multiple request types for one thread, but only with very much
effort (probably at the cost of performance).  I don't worry too much
about the code; it can be put in a library, which makes it as
maintainable as the code in the kernel.

Also, if a capability-based system is your goal (and that is IMO a very
good idea, but that doesn't make it a requirement), then putting this
support in the kernel makes sense, as you write.  But if it is not a
goal, but only something which is nice for people who are interested in
it, the kernel support only bloats the kernel.  IMO, it would be wise to
make a choice about this, and either make a kernel where capabilities
have a central role, or omit them from the kernel completely.

> On a personal level I'd say capabilities are very cool and should be
> used much more than they are; I haven't thought about hurd for a while
> though.

Yes, I'd like to do a short advertisment for capabilities myself.  I'm
not sure if I'm saying anything new to anyone here. ;-)

With capabilities, every resource automatically has its own access
control.  And a resource is not just "a disk drive", but also "reading
from /home/user/file.txt", or "writing to network port 25944".  And
access control means any given thread either can or cannot perform the
operation.

This should be combined with a policy of "you only have what you get",
meaning that new threads initially have no capabilities at all, but only
get what is explicitly given to them.  Then any thread cannot destroy or
leak any information on the machine (not through a bug and not through a
malicious programmer), except the information with which the program is
trusted.

On Windows, people are used to "don't click on a program of which you
don't know the origin".  That's because they are so stupid to make "view
this data file with a trusted viewer" and "execute this file as a
trusted program" the same operation (clicking on it).  However, even
when this is done properly, it still allows "execute this file as a
trusted program", but not "execute this file as an untrusted program".
And that latter operation should in fact be the only way new threads can
be started.

This is only possible with capabilities.  Without capabilities, "only
run programs you trust" will always apply.  And even then, if you
(rightly) trust the programmer, but the programmer made a mistake, the
program can still ruin the entire system (oh no, wait, it only ruins my
home directory, what a relief).

Capabilities allow the user to trust the computer.  The computer will
always do what the user asks (if the system administrater doesn't do
very weird things).  On any system where it is possible to "run"
programs which are not known by the kernel, that is, any system except
some very low-resource embedded systems such as calculators, this is
such a great feature, that it is worth very high costs, IMO.  Luckily,
the costs aren't even that high. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html

signature.asc
Description: Digital signature