[cap-talk] Another "core" principle - virtualize capabilities

[Marcus Brinkmann]

At Thu, 04 Jan 2007 17:51:12 -0800,
Jed Donnelley <capability at webstart.com> wrote:
> >Consider the Linux kernel to be a single object, for example, with
> >every system call being a method.  Then clearly we have a
> >object-capability interface, and it is wrappable and mappable by
> >either of several methods (whole-system emulation, virtualization,
> >user-mode kernels, ptrace, libc) depending on the level of mapping
> >desired.
> 
> I actually think such a network "object" could be useful.  Of course
> the devil is in the details.  Before I can get access to such an "object"
> it would seem that the object would need to be identified with a
> specific Unix user.  That is, my object could be "user:jed,
> system:ungwe.pair.com".

Yeah, well.  That would be part of the initial state of the
capability.  It could be configured so that its initial state
resembles a freshly booted kernel, in which case you would be a root
user within the system, as is partly realized by the fakeroot program
at a completely different level of abstraction of course.

> If I had a generic Unix object interface (e.g. "system:ungwe.pair.com")
> that I could invoke to "login" and receive back a system call object, that
> could suffice.  If that was all Unix is capable of it, would be better than
> nothing.  Better that than the application specific protocols that we have
> today (e.g. ftp, ssh, http, etc., etc.).  At least then we could send users
> such capabilities in protected email and such.

I don't think I agree that this would be "better".  I think that the
protocols you named provide additional functionality (for example of
translation) that would be lacking in your direct object access.  I
consider the question of authentication to be orthogonal (even though
for ftp this isn't true, obviously, but that's a small detail).

> However, notice that there are no such network objects.  I can't
> get a YURL or a wideword for such an object, much less any
> finer grained objects (e.g. to a file or a directory or a process) out
> of Unix systems.

Yes, but that is true for many other capability systems as well.  I
can't claim complete knowledge, but the systems I know about (EROS,
L4) are decidedly single-host systems.  Any network layer has to be
implemented on top in user space.

The main reason is that (1) it is possible to do it this way, which
allows for microisher microkernels, and (2) putting the network layer
policy into the kernel for all IPC is a failure, because it tends to
preclude optimizations.

As an example, the Mach message format was developed with network
transparency in mind, and this additional feature comes at a cost that
can't be avoided even if network transparency is not required (ie, for
local messages).  In particular, the type information in the message.

This is not to invalidate your point.  Certainly this is not the only
reason we don't have "Unix system objects" in todays Unix systems.  I
just want to point out that what you criticize will remain to be true
even if you do everything "correct" at the OS level.

> The fineness of the grain provides added value (POLA, etc.).  I'd
> be delighted to see competition arise for value in such standardized
> network, OS, or language objects.  Given that any could be mapped
> and thus available in any other context, software written for object-capability
> interfaces would have a wide variety of objects to chose from.  I expect
> at that point a winnowing out would happen with survival of the fittest
> objects.  I'm not sure if a Unix:user:systemcall object would be among
> the finalists, but perhaps so.

It remains to be seen how much of this will be accepted by application
developers.  Current developments are decidedly monolithic (D-BUS
etc).  In those areas where benefits are immediate and transparent,
such developments already seem to happen, slowly, giving SSH privilege
separation again as an example.

> >In light of this, which parts of the discussion are you still
> >interested in?
> 
> I'm sorry, but while I consider the example a mildly interesting one,
> I disagree with your statement that my clarified claim above, namely
> 
> "a wrappable and mappable object-capability interface is sufficient for all
> applications"
> 
> is a null-statement.
>
>  Still, I'm happy you agree that at least it's true.
>
> I've thought this was obvious for most of my career.  However, some
> people (e.g. recently on this list) have objected that such an interface
> can't be made to perform well at the OS interface level.
>
> If we can accept that such an interface can be designed to perform
> well for all "system call" functions, then I believe the value in such
> an interface, wrappability for higher level functions like revocation,
> monitoring, remoting, responsibility delegation, etc., argues for the
> use of such an interface to systems at the network, OS, and language
> levels.  Unfortunately, while people may believe that they have wrappable
> interfaces (e.g. even with wrappability as a design goal), until some
> wrapping (virtualizing) is actually done, often times the belief turns
> out to be false.  Of course I suggest network "remoting" (along the lines
> of the DCCS) as an effective test case that also has the side benefit of
> allowing any such objects to participate in network commerce.  Naturally
> there will be pressure on such remoting mechanisms to standardize their
> communication protocols - object sharing protocols.
> 
> For me such standardization pressures are all to the good.

Can you give a recent example for a failure to virtualize?  I had the
impression that virtualizable architectures were reasonably well
understood since the 70s.  I also think that any disagreement on
virtualizability could probably be redefined as a disagreement on
object definition.

Thanks,
Marcus