Re: Codezero v0.2 Capabilities

[Bas Wijnen]

Hi,

On Sun, Dec 13, 2009 at 01:48:00PM +0200, Bahadir Balban wrote:
> the current set of capabilities I implemented  
> are rather rigid in their definition. The kernel strictly defines the  
> resources that it manages, and those capabilities are not really open  
> for different implementations. I think I would prefer to keep the kernel  
> interfaces to have well-defined behavior so this would not be a relevant  
> requirement from a kernel interface point of view.
>
> As a next step though, it might be a good experiment to see if userspace  
> processes can provide their own user buffers to install custom  
> capabilities. The kernel, then would not care about the capability  
> details, only check them on behalf of the owner. Such user-defined  
> capabilities could be invoked with an opaque, user-defined capability  
> invocation protocol over the ipc call.

Then you lose the proxy feature.  I really like the idea that I can wrap
a device driver in some proxies and test the driver using only a device
emulation, for example.  This can be done with proxies, because the
driver cannot see if it talks to the kernel or not.  If it can, it may
respond differently to an emulation, and that means you're not really
testing the driver as it will be when used "normally".

This may not be a big thing for you.  It's only a feature, and certainly
something you can do without.

On Sun, Dec 13, 2009 at 02:16:00PM +0200, Bahadir Balban wrote:
> I didn't get how a process would exercise authority in error.

Example on a pure capability system: To run a file, a call is made to
a run-time linker/loader (ld.so on Linux).  A capability to a memory
container with the file is provided.  The linker/loader will build an
address space for you, with all the memory in the right place.

Now, how would address space creation work?  A capability which is
provided by the caller is used for this.  This means that anything the
linker/loader does could in principle be done by the caller (except that
it doesn't (want to) know how).

On the other hand, if address space creation is a kernel call that may
not be allowed, then the linker/loader cannot know if it may do this on
behalf of its caller.  If it does, it may excercise authority in error.
If it doesn't, it isn't able to properly do its job.

This probably means things for how you set up the system.  Perhaps you
don't want to do resource accounting as much as I would.  Perhaps there
are other things which you can do to solve this problem, for example
turning the linker/loader into a library.

I can't oversee what is possible to solve the problem, but looking at it
from a capability system point of view, there are things missing that
need a solution.

> If you  start the process with a single capability, it may try all it
> wants with  the syscalls. It will always end up with an -ENOCAP error
> unless it is  that very operation that corresponds to that possessed
> capability.

The problem is that threads may want to do things on behalf of others.
You are in principle right that correct programs have no problem with
accidentally using a capability they didn't mean to invoke, but on the
other hand you make it very easy for accidents to happen.

> When you say the code is directly naming the authority you are  
> approaching it with a pure capability way of thinking. It is doing that  
> because it comes natural to name entities with their direct name when  
> you get to use them. I believe this is more practical. While this might  
> be an issue on a capability way of thinking, I think it is an  
> aesthetical one, security-wise it seems to me that they are no different.

There is security in making it hard to make mistakes.  The above
paragraph of mine was about this.  Furthermore, using opaque
capabilities it is possible to proxy, as I wrote further above.  Being
able to do this makes certain designs possible which seem (with only a
casual view) to be more secure that what you can achieve with your
system.

Note that this does not need to bother you.  Maximum security doesn't
need to be everybody's priority.

Thanks,
Bas

signature.asc
Description: Digital signature