Re: Challenge: Find potential use cases for non-trivial confinement

[Marcus Brinkmann]

At Tue, 2 May 2006 00:36:18 +0200,
Pierre THIERRY <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit Marcus Brinkmann dies 02/05/2006 hora 00:27:
> > By virtualizing a capability I mean the action of replacing it with a
> > different capability.
> > 
> > This simple definition makes clear that if an instantiated process has
> > access to capabilities provided by some other entitity than the
> > instantiator, the instantiator can not successfully virtualize these
> > capabilities.
> 
> Could you explain use cases of this, and maybe especially where this is
> a problem?

Sure.

(1) A program wants to monitor all communication going in and out of a
    child program.  Thus, it needs to insert forwarding proxy
    capabilities for all capabilities that the program has, and for
    all capabilities that go through these channels.

    This is what the rpctrace program does in the Hurd on Mach.

    If the child has extra authority, I can not capture all the
    information flow that actually happens.

(2) A program wants to run a child program in its own complete copy of
    the operating system.  We call this a sub-hurd.

    If the child has extra authority, it escapes the sub-hurd.

(3) A program wants to replace a selected system service with an
    alternative implementation for the child program.  For example, a
    program may want to run a child program with its own space bank
    implementation to change the way resource accounting works
    (throtteling, soft limits, etc).

    If the child has extra authority, it may refuse to run the parents
    implementation.

(4) Fakeroot in the Hurd on Mach used a proxy filesystem server to
    fake root access for file manipulation.  A similar pattern can be
    used to fake write access to read-only parts of the filesystem.
    In a similar spirit, fakeauth used a proxy authentication server
    to fake the root user id 0.

    If the child has extra authority, it may escape the
    parent-provided filesystem (if it is not confined), or refuse to
    use it.

(5) Any type of debugging and reverse engineering.

Note that the potential impossibility of any of this is not a defect
in Jonathans model.  In that model, it is intentionally the case that
the child can refuse the parent.  The system hierarchy is flat,
because through their constructor, all processes have direct access to
at least some system-capabilities that can not be virtualized.

Note that virtualization of trusted computing hardware is an unsolved
problem in academia.  Some people at one of the multinationals
probably have figured out how to do it, but they do not publish their
results to my knowledge.

In my model, the system structure is recursive, and children can not
resist their parents, because the whole existence of the child is
initially defined by the parent.

I consider the ability to do all of the above things so valuable that
I want to build a system that defends these possibilities.  The system
should allow debugging by default, and the user should not
involuntarily give up this right.  I believe it should be hard to give
up these rights, just as hard as it should be to invoke unconfined,
non-system services.

Thanks,
Marcus