[cap-talk] Mungi, Iguana and Ambient Authority

[Toby Murray]

This message came up a while ago but its taken me a while to get onto 
it. If possible, I'd like to probe deeper here to get a better 
understanding of exactly the limitations imposed by the Mungi/Iguana 
ambient authority APIs. What is gained by these APIs and what exactly is 
sacrificed?

Charles Gray wrote:

>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.
>
>  
>
<snip>

>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
>
>  
>
I don't see how this affects confused deputy attacks. Could you explain 
further?

>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.
>
>  
>
If I take your meaning, then the "server" who receives a client request 
must explicitly check each tmie after a capability invocation, what 
capability was used and whether it was a capability the server already 
held or whether it was passed by the client, and which is the correct 
kind that should have been used.
I feel that this sort of explicit checking is totally error-prone. I 
suppose it could be managed by a library below the server but it seems 
convoluted. I'm not sure what you're gaining for losing the ability to 
explicitly invoke invidivual capabilities.

>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).
>
>  
>
 From what limited experience i have in this area, I believe that all 
capability validation should be done by the underlying security kernel, 
rather than the services ("objects" if one prefers) that run on top of 
it. Forcing each object to explicitly validate capabilities it is 
presented by clients is error-prone and tends to duplicate large amounts 
of security-critical code. The previous paragraph aboove seems to imply 
that this must occur for service providing objects. Is this true? could 
you perhaps provide an example to illustrate further?

thanks heaps,
Toby

	



-- 
Toby Murray
Software Engineer
Advanced Computer Capabilities Unit
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.