Subject: Re: POLA and Mungi / Iguana style APIs - msg#00086

Previous Message by Date:

Re: POLA and Mungi / Iguana style APIs

Toby Murray wrote: I'm writing to see if I can get the list's opinion on APIs that attempt to "hide" capabilities from the programmer. The specific examples I have in mind are the Mungi / Iguana systems from Uni NSW (http://www.disy.cse.unsw.edu.au/Software/Iguana/). In the Iguana API (which I believe inherits a lot from Mungi), the programmer presents an "Object ID" which designates the target of a method invocation. The kernel then searches the c-lists of the caller to find a capability that might grant the access. I believe that this is done to hide the capabilities form the programmer in the common case where operations on the protection domain aren't required (eg. to achieve confinement or whatever) With this system, has designation and authorisation been separated? Does this separation reduce the ability to provide /enable POLA? More specifically, does it allow the application to become "confused" and use the wrong authority at the wrong time. Yes, it does. If you look at Norm Hardy's original motivating example of the Confused Deputy problem <http://www.cap-lore.com/CapTheory/ConfusedDeputy.html>, a system like Iguana would still be vulnerable to it, as well as to most other confused deputy situations. Despite the terminology used in Iguana, IMHO it should not be considered a capability system, precisely because it separates designation from authority. (Unfortunately many people don't see the importance of confused deputy attacks or have a "blame the user/application" response to them. For example see <http://c2.com/cgi/wiki?ConfusedDeputyProblem>.) Another unhelpful aspect of the Iguana design is that domains using External Address Spaces are second class (page 4 of <http://www.disy.cse.unsw.edu.au/Software/Iguana/userman.pdf>): # External Address Spaces are provided for support of legacy applications # and applications too big to share the Iguana AS [Address Space]. An # external space (EAS) is the equivalent of a Linux process. External # address spaces operate to a restricted API (mostly raw L4 system calls) # with little access to Iguana services. They are as such not well # integrated into the Iguana system, and are in fact firewalled off # the rest of the system in most respects. [...] # An EAS cannot present any capabilities to the system. Hence, threads # running in an EAS are operating to a restricted system API. They can # only perform operations which are allowed without capability # presentation. There is no good reason to firewall off legacy applications like this [*]. It prevents apps from being incrementally changed to use capability-based APIs, which would help with the "applications barrier to entry" problem. In general, I find the differences in the design of Iguana/Mungi relative to capability systems to be poorly motivated, and I think it's unfortunate that the L4 folks have chosen not to adopt a design that is strictly layered on a capability-based interface (in which legacy APIs are supported in addition for domains that need them). It's also unfortunate that they have used capability terminology for something that is not a cap system. This is yet another of the frustrating "near misses" in which system designers have been partly motivated by capability systems, but have misunderstood one or other of the characteristics that make cap systems work. [*] It would be possible to get around this restriction by doing IPC between an EAS domain and another domain, but that would be unnecessarily complicated, and just demonstrates the pointlessness of the restriction. My suspicion is that it does allow the application to become confused and as a result, reduces the ability of the capability system to promote least authority. That said, I'd be interested in the opinions of others here with more experience. Particularly those of Professor Heiser, who I believe is the main architect of these systems. While I understand the potential benefits of hiding the capabilities from the programmer in order to provide a more comfortable system, Perceived benefits. I don't agree that this is an actual benefit. Rather than making programming "more comfortable", Iguana avoids benefitting from one of the improvements in comfort and simplicity that cap systems enjoy when used from object-based languages: instead of unifying OS-level designators, OS-level authorities, and programming language references, the Iguana design requires programmers to continue to deal with these concepts separately. Contrary to what the user manual referenced above says (page 3), the fact that capabilities don't appear explicitly in the API doesn't mean that most applications "never need to deal with them"; an application programmer still has to be aware of what capabilities a domain has. Also, applications won't gain any of the security benefits of POLA unless they explicitly separate an app into multiple protection domains and delegate caps between them. Although the design of Iguana makes that possible, it doesn't do much to encourage it. I believe that if the API instead called capabilities "object pointers" (or some equivalent) then we get the familiarity without fear of losing POLA. (I'm thinking Joe-E). The irony is that cap systems have retained a reputation for being "too different", even though the design of programming languages in common use has moved most of the way toward capability systems (in particular toward Dennis & van Horn's design). A purely object-capability-based OS API would have less of an impedence mismatch with modern OOPLs than a "conventional" Unix-like API. -- David Hopwood <david.nospam.hopwood-QgLWrMLu8clzjhtm8Ag3mw@xxxxxxxxxxxxxxxx>

Next Message by Date:

Re: attacking a capability system

On 5/14/05, john.carlson3-rphTv4pjVZMJGwgDXS7ZQA@xxxxxxxxxxxxxxxx (John Carlson) wrote: >Suppose someone got a hold of an active object on any capability system >or network. Then they used that object to generate new capabilities, >and communicated them far and wide (massive emailings, postings to >websites, etc. etc.) Capability OSes (KeyKOS, EROS, etc.) use capabilities to control access to computational resources. This control limits the impact such a denial-of-service attack will have on other parts of the system. However, the target object is effectively attacked. By having a separate object for each external use (e.g. "legitimate" user), the damage is limited to the external use that let the capability loose in the first place. I don't know that you can do much better than this. It also might be analogous to having ISPs cut off service to accounts whose machines have been turned into spam-bots. IMHO, if combined with instructions for bot removal and updates to prevent future infection, cutting them off would be a useful step forward for spam reduction and general network security. >The capability to be able to send a capability to an object is very >important and must be carefully guarded. Agreed. In most capability systems, it is just another capability. "Only connectivity begets connectivity" <http://www.erights.org/elib/capability/overview.html>. >I like how IM systems ask you if you want to add a buddy to your buddy list. This ability to prevent communication based on who the sender is, is the realm of access control lists. You can do something similar with capabilities where adding a buddy sends that buddy a capability for sending you messages. However if your buddy gives that capability to others, they can use it as if they were your buddy. After a number of annoying messages, you might decide that buddy is no longer your buddy. >Do you still >publish your phone number in the phone book? ... I suspect >no one here subscribes to donotcall.gov. Well, my phone number is in the phone book, and also on donotcall.gov. YMMV >Is communication the Achilles' heel of capabilities, or the forte? Control of communication is the forte of capabilities. Using that control wisely is not guaranteed. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032

Previous Message by Thread:

Re: POLA and Mungi / Iguana style APIs

On Mon, May 16, 2005 at 06:35:20PM -0700, David Wagner wrote: > Toby Murray <toby.murray-7BNmJD1m9TP299njBJCvBrpzq4S04n8Q@xxxxxxxxxxxxxxxx> > >The kernel then searches the c-lists of the caller to > >find a capability that might grant the access. [...] > > That's an ambient authority system. > > >With this system, has designation and authorisation been separated? Does > >this separation reduce the ability to provide /enable POLA? More > >specifically, does it allow the application to become "confused" and use > >the wrong authority at the wrong time. > > The system is vulnerable to confused deputy attacks. Sure, but it's still loads better than no capabilites at all. With this system you can run untrusted non-capability code. You give that code a c-list taken or generated from a minimal subset of your own capabilities, the code makes system calls, and the kernel checks that the code has a capability granting the access in its c-list. The code might be vulnerable to confused deputy attacks, but since it's untrusted, why should you care? It's a question of granularity. In this case the L of POLA is just above the untrusted code, and that's where it should be. I would love to be able to run openoffice of firefox or mplayer in such a box.

Next Message by Thread:

POLA and Mungi / Iguana style APIs

Jonathan Shapiro writes: >What I am coming to question is whether ambient authority is really the >problem in this [confused deputy] situation. Jonathan, I'm glad you are asking these questions. I think this is absolutely central to the study of capability systems. When I ask what the benefits of capabilities are, I keep coming back to only two compelling answers: POLA for free, and avoiding confused deputy. So I'm glad you are asking about what capabilities do for confused deputy attacks. The good news is that I think capabilities really do help with confused deputy, maybe more than you realize. Let me try to argue why, by walking through Norm Hardy's confused compiler example. I hope you will do your best to poke holes in my reasoning -- if I'm being too optimistic, I'd definitely like to know. Here is the ambient authority compiler, in pseudo-Java: void compile(String srcfilename, String billfilename, String objfilename) { String programtext = new File(srcfilename).readAll(); byte[] objdata = compileString(programtext); new File(objfilename).write(objdata); new File(billfilename).write(... billing record ...); } byte[] compileString(String s) { ... do all the real work ... } Notice how it is susceptible to a confused deputy attack, because opening the billing file is done with the compiler's authority, not the client's authority. How would we implement this in capability style? The first rule of capability systems is to pass object references, not names -- e.g., pass Files, not Strings. That rule suggests something like this: void compile_capstyle(File src, File bill, File obj) { byte[] objdata = compileString(src.readAll()); obj.write(objdata); bill.write(... billing record ...); } byte[] compileString(String s) { ... do all the real work ... } Once you have determined that the interface to this method should use Files, not Strings, then the latter is in some sense the "obvious" and "natural" way to implement the method. Now, please notice how the latter implementation is automatically secure against the confused deputy attack. I've deliberately picked a simple example that is ideally suited to illustrate the advantages of capability style programming, but I hope you can see how this generalizes. Since there is no ambient authority, the deputy can only use authority that it got either from its parent or its client. Moreover, when working with an object designated by the client, the right thing is to use the client's authority, while when operating on an object designated by the parent, the right thing is usually to use the parent's authority -- and this is exactly the policy that capabilities give you, for free. In principle, we could defend against confused deputy attacks (without capabilities) by having the deputy carry around, next to each resource designator, a flag indicating the source of that designator. When it comes time to side-effect that resource, we could tell the operating system which authority-context to use based on the value of the associated flag. But, this is error-prone, because the programmer has to carry around the flag explicitly. What capabilities do is manage this flag for you automatically, for free, with no programmer effort required. Do you buy it? Does this make sense to you? >The question that the service needs to be asking is always: > "Is it okay to be performing this operation on this object on > behalf of the current authorization context" This is the wrong question. The very notion of a "current authorization context" is a form of ambient authority. Capability style says you have to avoid the notions of "current security context" -- for much the same reason we encourage our students to avoid using global variables. >Fusing authority with designation does not evade the need to ask this >question. It simply re-manifests as: > > "Which capability index should I be passing to this operation > given the current authorization context" I disagree. When you use capability style properly, there is no longer any notion of a current authorization context. See my compiler example above. >Ironically, the confused deputy is not an example of *either* of these >problems. The confused deputy arises entirely because the compiler >instance needed to perform an "open" in order to access the log file. >This is a namespace and binding issue, not an ambient authority issue. I disagree. I do think of this as an ambient authority issue. If you want to think of it as namespace and binding, the question is whose namespace to use. The way to fix the compiler flaw is to do the "open" in the client's namespace. The easiest way to force the client to do the "open" in its own namespace is to insist that the client provide the compiler with a open file handle (not with an unopened filename). In a capabilities program, I suppose we could say that the effective namespace of a program P is determined by the capabilities program P has. For instance, say P has a File object ``d'' representing some directory in the filesystem. Then P can execute, e.g., ``new File(d, "foo")'' to get the file "foo" under directory ``d''. In effect, P's namespace is restricted to the directory tree under ``d''. I don't know if this is a helpful way to think about things or not. It's not how I think about it, but if you find this a more convenient way to think about it, great.