[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    [cap-talk] Are we allowing the mistakes of the past to be repeated?
From:       Toby Murray <toby.murray () dsto ! defence ! gov ! au>
Date:       2005-05-23 0:35:09
Message-ID: 4291226D.2030504 () dsto ! defence ! gov ! au
[Download RAW message or body]

Jonathan S. Shapiro wrote:

>Suppose that we revise Norm's "Confused Deputy" example as follows:
>
>  Imagine that designation and authority are separated. If a process
>  P invokes an operation designating an object O for which the
>  process holds authority, it is as though the process P held
>  some set of capabilities to O, and acts with the *union* of the
>  authority provided by these capabilities. [Note that not even
>  UNIX makes this mistake.]
>
>  
>
Can anyone confirm my belief that the Mungi (and potentially Iguana) 
APIs specifically suffer from the above. ie. they give the process the 
union of the authorities provided by their caps. This is exactly the 
sort of issue I was hoping to have discussed when I raised these examples.
In this case, it appears that capability systems can be more "dangerous" 
than what we currently have (eg. UNIX) if not implemented "correctly" 
(for appropriate definitions of these two words).

For this reason, I'm suprised I haven't seen more discussion here 
regarding the Mungi (and related) systems.
Specifically, we have a  really good chance to "get it right" on the 
embedded device front over the next 5 years or so in terms of OS design 
and implementation to achieve the promotion of least authority. Given 
that this is (I believe) exactly one of the goals of the Iguana efforts, 
why haven't the capability proponents more noise about the fact that the 
current Iguana APIs appear to perpetuate the (alleged) mistakes of Mungu 
all over again?

It appears as if the Iguana team recognises the benefits of capability 
systems and want to expose these. However, there is obviously (to me) 
consensus that the current APIs are "broken". Can anything be done? Or 
is this not the appropriate forum for these sorts of discussions?

If the more experienced practitioners on this list are disappointed 
about the way it went over the last 20 years, do we not now have a 
second chance in the embedded space? Why aren't we making more noise if 
we can see it happening right in front of our own eyes? It would be a 
shame to repeat the mistakes of the past, especially if we believe we 
know better.

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

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic