[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Opaque storage
From: |
Pierre THIERRY |
Subject: |
Opaque storage |
Date: |
Wed, 10 Jan 2007 00:56:25 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Scribit Marcus Brinkmann dies 08/01/2007 hora 12:10:
> 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.
There's a very easy way to achieve that, without even A being able to
inspect B (so I'll describe it with a constructor):
A instantiates process B with B's constructor, and checks that B has no
extra authority. It then instantiate a reference monitor guard process
G, and gives B a capability to G that mediates access to A. All
authority B will ask for will be asked through that reference monitor.
The reference monitor's role is to keep any capability marked as
dangerous that B would receive and only give to B a no-op capability to
G. Whenever B gives the no-op capability to another process outside the
reference monitor, then the original capability is substituted to it.
Capabilities not marked dangerous are proxied by G to be able to do the
substitution.
When B needs access to trusted service process S, it asks for it, and if
A hands a capability s0 to S, not marked dangerous, it will then be
proxied by G, that would give B a s1 capability to itself.
Along with a (proxied) capability to S, and as part of the protocol to
use S, B receives a capability c0 to use opaque storage, destined to S,
and marked dangerous to the reference monitor. The guard will keep c0
and give to B a capability to itself c1 that is just a no-op (but it
could also be used to notify A of the hostile character of B...).
When B invokes the s1 capability to use S and includes the c1
capability, G will substitute it with c0, thus giving S authority to use
opaque storage.
You'll note that this doesn't need the introduction of any ACL like
tagging, and nowhere identity of processes is known. It's just one of
those scenarios where POLA shows it's incredible power (it took me about
an hour to sketch it, and I'm just dazzled by it).
The guard is a very small process pretty straightforward to implement,
AFAICT, and needs no special kernel support. It's sufficiently simple
that I'm confident it could be proven to be correct pretty easily (it's
only loop would in the access of a data structure holding capabilities
to be compared, and we know proven lists, and the rest is only about
value comparison).
Securely,
Pierre
--
address@hidden
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, (continued)
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Marcus Brinkmann, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Pierre THIERRY, 2007/01/08
- Opaque storage, Jonathan S. Shapiro, 2007/01/08
- Re: Opaque storage, Marcus Brinkmann, 2007/01/08
- Opaque storage,
Pierre THIERRY <=
- Re: Opaque storage, Marcus Brinkmann, 2007/01/09
- Re: Opaque storage, Pierre THIERRY, 2007/01/09
- Re: Opaque storage, Marcus Brinkmann, 2007/01/10
- Re: Opaque storage, Alan Grimes, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Anton Tagunov, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Marcus Brinkmann, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10