[cap-talk] Mungi, Iguana and Ambient Authority
Charles Gray
cgray.captalk at cse.unsw.edu.au
Tue Jun 14 21:26:40 EDT 2005
Hi All,
There has recently been a lot of discussion on this list regarding
ambient authority and the Mungi and Iguana systems. Being part of the
Mungi group, I thought I should respond.
While both Mungi and Iguana use ambient authority, there are two
issues to address related to ambient authority and the 'Confused
Deputy' problem.
Firstly, Yes, Mungi and Iguana APIs use ambient authority, and thus
have the potential for 'Confused Deputy' attacks. (I will take up the
discussion of the risks of this kind of attack in another thread)
The standard programming model of both systems is that of a
single-address-space. This works neatly with an ambient authority
model (however this is not a requirement, see below).
In general, in order to avoid 'Confused Deputy' attacks, a service
must do what operating systems traditionally do: treat every user
pointer with suspicion. In the Mungi case this means that:
- each (buffer) capability passed from a client must be explicitly
validated (using the respective system call) before adding it to
the receiver's Clist
- on de-referencing user pointers, a range check is required to
ensure that the pointer is inside the buffer passed by the client
It is important to note that neither system is vulnerable to the
'union' attack described previously on this list. (That is, when a
client provides a valid READ capability for a object to which the
service also has WRITE authority, and attempts to trick the service
into writing there). When access to an object is validated in Mungi
and Iguana the system tells you which capability gives you that
access. A client trying to fool a service by providing a lesser, but
valid, capability will be detected.
However, both Mungi and Iguana are still proper capability systems
that can implement POLA and confinement. Both APIs allow you to
confine programs by not granting them the ability to add capabilities
to their clists.
For a confined program to use a capability it must pass this to an
external party which has the ability to enforce the necessary checks
and act on these capabilities. This allows you to build systems on top
of the generic Mungi and Iguana APIs which are not vulnerable to
'Confused Deputy' attacks. Such systems can not take advantage of the
native programming model, however they do fully support programs
written to an explicit capability presentation model and can provide
the exact same security guarantees. (The assumption here being the
party that does handle the caps is part of the TCB).
Chuck
More information about the cap-talk
mailing list