Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack

[Marcus Brinkmann]

At Mon, 8 Jan 2007 10:03:41 +0100,
Pierre THIERRY <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit Marcus Brinkmann dies 08/01/2007 hora 09:31:
> > > So it all boils down to avoid givind to a process you can inspect a
> > > capability to a process you can't inspect.
> > Uhm, but then it can't use any service requiring opaque allocation of
> > user-provided memory resources.  Wasn't that the whole point of the
> > exercise?
> 
> Well, obviously you will give such a capability if you trust the
> service. But at no point you have to give authority you'd like to
> prevent the use, and that's the point of a capability-based system.

We have three processes involved, so I don't know what you mean by
"you".  Remember that the scenario is that process A wants to give an
inspectable process B access to a service S which requires opaque
storage allocations, without giving B access to opaque storage
allocation.  The tagged resource container proposal (or any variation
of it) seems to be the minimal model that can achieve that.

If you have that situation, saying that "A" does not need to give "B"
such a capability is not helpful, because that means that "B" can not
use "S", thereby violating a requirement of the scenario.

You have made a convincing case (in my opinion) that such a scenario
is useful to support.  Why are you now giving up on it?

> As I trust the Ethernet driver, I will happily give to my TCP/IP stack a
> capability to it, but not to any other process. Same goes for some
> custom FS I use in my home directory, which could access the USB driver
> to store data in an USB disk. And if the USB driver happens to need some
> client-provided memory that the client can't even read, so be it, but I
> wouldn't give a capability to any other process to it.
> 
> Capabilities to processes able to opacify memory are no different than
> capabilities to any other process able to to do anything that could be
> turned against me. While adhering to POLA, I protect myself from any
> such threat...

You seem to be missing that in the discussed scenario we have three
processes A, B, and S, where the delegation chain is "A->B->S", and A
trusts S with a certain resource (like opaque allocation) but not B.

It is not the case, as you seem to consider, that "A->S".  If that
were the case, I agree that there is no issue in simply using direct
delegation.

Thanks,
Marcus