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

[Pierre THIERRY]

Scribit Marcus Brinkmann dies 08/01/2007 hora 07:11:
> > You claimed that it could be used to implement policies you consider
> > to be security threats. What harmful policies can be achieved
> > through this mechanism that cannot easily without?
> The canonical example is the encapsulated constructor: The developer
> of a program gives a capability naming a constructor to a user
> (confined or not confined, doesn't really matter).

I'm tempted to tell you you're speaking about mechanisms where it's
about policy. ;-)

IIUC, opaque memory only makes it easy to add resource accountability
and DoS resistance to processes hiding their code and data. But the
policy in itself (executing a program without enabling the user to
inspect it) is already achievable without opaque memory.

> This is the base scenario, required for implementation of blackbox
> algorithms and DRM, for example (usually not confined so billing can
> occur).

I don't know about effective DRM, but blackbox algorithms don't require
opaque memory.

> How can we ensure that it can not engage into a contract like the one
> above?
> 
> * We could inspect it statically or dynamically.  Unfeasible, except
> under very narrow assumptions.
> 
> * We could try to prevent it from getting any constructor capability
> such as above (more generally: any capability that would allow it to
> engage into harmful contracts). [...]
> 
> * We could not give it any capability that allows untrusted agents
> allocation of opaque storage.  This is what I proposed for sake of
> discussion.
> 
> The difference is that in the second method above, the shell gives the
> application access privileges and then tries to prevent it from
> exercising them.

Why should the shell in the system with opaque memory give more
authority? I don't see why POLA wouldn't be enforced as tightly as
possible when there is opaque memory.

As I said before, if you give to a process A, that you can inspect, a
capability to another process B, that you can inspect, and B ask A
opaque memory, you still have authority to inspect that memory, because
you can inspect B.

So it all boils down to avoid givind to a process you can inspect a
capability to a process you can't inspect.

But one of the very purpose of a capability-based OS is precisely to let
you use programs while giving them the least authority they need to
operate. So I don't see any conceptual difference between EROS and your
proposal (WRT to this specific point). If you want your processes to be
inspectable, don't give them authority to use memory you can't inspect.

Curiously,
Pierre
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature