l4-hurd
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]