[cap-talk] rights communication - hope? - tome - network

[Karp, Alan]

Jed Donnelley wrote:
> 
> I liked Ka-Ping Yee's example of $rm <whatever>
> In a previous generation of discussion on this list I tried to focus
> attention on the difficulties of getting <whatever> to define the
> rights passed to an application (e.g. rm in the above case) to
> severely limit its rights vs. ambient authority.
> 
 
The key is to separate the "installation endowment" used by CapDesk and the per instance authorities.  The installation endowment for rm is read access to its executable and other resources every running instance needs.  Granting per instance authorities with "rm foo" means that rm has access to all files.  Granting per instance authorities with "rm > foo" gives rm an "open w" filehandle for foo.  It's a change to the shell, but one that shouldn't require much training.  (This example is adapted from one in one of MarkM's talks.)
 
> 
> Is that right?  While I understand that in principle such 
> authorities can be
> determined from command-line arguments, for existing syntaces (plural
> of syntax in case it is confusing) doing such a determination seems
> difficult to me.  Is this problem better understood/handled that I am
> aware of?
> 
 
Inferring the authorities from the command line arguments would mean understanding the semantics of the application.  Additional syntax, such as the additional ">" in the rm example make it possible, at least for read- and write-like methods.  In other cases, I think you'll need a per command wrapper that understands what permissions are needed by the application.  In our Client Utility prototype we had separate names for distinct facets of an object, e.g., foo-r, foo-w, and foo-rw, with obvious extensions for other types of methods.
 
> 
> Perhaps I need some refining of my definitions here.  Are you saying
> above that ACLs are an ambient authority system?  What I thought
> was meant by that term was in systems (e.g. Unix fork) where processes
> are assumed to have the same (ambient) rights of those who created
> them - typically when an application is started.  I don't believe ACLs
> (at least on a process basis as you seemed to be discussing) fall
> into that category.
> 
 
The key distinction to me is whether I specify exactly what authority I convey with each request or the system selects them behind my back from the all the authorities available to me.  The latter approach is subject to confused deputy whether the process has all my authorities or only some of them.  Restricting the set of authorities available to the process limits the number of ways the deputy can be confused, but it doesn't prevent the confusion from happening.  This point is illustrated nicely by Norm's compiler example.  Even if I run the compiler in a process with exactly the authorities it needs, the attack succeeds in any ambient authority system.
 
Here's an analogy to explain how I distinguish ambient and explicit authority systems.  When I get home, I pull out my door key and unlock the door when I get to it.  If I walk up to my neighbor's door by mistake (as I've actually done; don't ask), the key doesn't work, and I go to my own door.  That's an explicit authority system.  If, on the other hand, I walk up to the door and start trying keys until I find one that works, I'll end up walking in on my neighbors.  That's an ambient authority system.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp


> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Friday, September 24, 2004 12:16 PM
> To: General discussions concerning capability systems.; 
> cap-talk at mail.eros-os.org
> Subject: Re: [cap-talk] rights communication - hope? - tome - network
> 
> 
> At 02:10 PM 9/23/2004, David Wagner wrote:
> >Ping writes:
> > >Shells don't have to violate capability discipline.
> >
> >Yes.  Absolutely.  If I understand one of the design goals behind
> >E, I believe it was intended as something that could be used as a
> >(capability friendly) shell -- so that's certainly one example right
> >there.  In general, I think there is a plausible argument that the
> >existing Unix shells are a hack and should have been replaced by some
> >scripting language with a cleaner design.
> >
> > >Being able to dynamically update a process's authorities at runtime
> > >is huge.
> >
> >Well, maybe there are four levels of support for least privilege.
> >   (i) the applications's authorities are chosen in advance 
> and are the
> >       same for all executions of that app;
> >  (ii) the process's authorities are determined, based on 
> context, at the
> >       time the application is executed, but then kept 
> static throughout
> >       the execution of that process;
> 
> I liked Ka-Ping Yee's example of $rm <whatever>
> In a previous generation of discussion on this list I tried to focus
> attention on the difficulties of getting <whatever> to define the
> rights passed to an application (e.g. rm in the above case) to
> severely limit its rights vs. ambient authority.
> 
> I belive that regarding shells this is the fundamental nut of the
> problem - regardless of the means of communicating rights to
> the application (e.g. ACLs or capabilities).
> 
> >(iii) the process's authorities can be freely modified in 
> the middle of
> >       the execution of a process; or
> 
> The above language concerns me a bit.  It seems to suggest 
> that somebody
> has the right to do such modification.  In general we're 
> talking about 
> interfaces
> between mutually suspicious processes.  If by the above you 
> are referring
> to a situation where a process needs to ask for additional 
> rights to complete
> its work (e.g. fetch a capability out of a directory) then 
> I'm with you.
> 
> >  (iv) (iii), plus there is a clean framework that allows 
> the process to
> >       safely communicate rights to other processes, and 
> receive them from
> >       other processes, in the middle of its execution.
> 
> I have to admit to being a bit dismayed that iv sounds like some sort
> of extreme nirvana that no reasonable person could expect.  To me it
> seems to be the minimum that a reasonable operating system's structure
> should provide.  I consider mutual suspicion between processes as the
> norm (e.g.consider processes communicating across a network which
> is always my default case of consideration).  Clearly there 
> must be some
> means to communicate rights between such processes.  No?
> 
> >For some apps, (i) suffices.  For example, think of daemons 
> or servers.
> >Those typically don't have a controlling user, and the 
> necessary privileges
> >usually don't depend on arguments or other context.  Or, 
> think of a mail
> >app that is allowed to read and write to ~/Mail and 
> /var/spool/mail/$USER
> >but nothing else.
> >
> >For many other apps, (ii) suffices.  For example, think of 
> most simple
> >command-line applications, where the set of authorities can 
> be determined
> >from command-line arguments and other contextual information.
> 
> Is that right?  While I understand that in principle such 
> authorities can be
> determined from command-line arguments, for existing syntaces (plural
> of syntax in case it is confusing) doing such a determination seems
> difficult to me.  Is this problem better understood/handled that I am
> aware of?
> 
> >You can derive this set very elegantly using capabilities,
> 
> I'm not aware of any way capabilities help you with the 
> syntactic issues.
> I'd be interested to hear about that.  I can see that our 
> experiences with
> "capabilities" differ significantly.  I find that dialogs 
> (multilogs?) like 
> this
> can sometimes help to fill for the lack of overlap in experiences.
> 
> >or you can do it less
> >cleanly in an ACL system by using various heuristics (such 
> as TRON used).
> 
> >For a large number of interactive apps, (iii) is useful.  
> For instance,
> >we might want to give it rights to a file F if the user has 
> selected file
> >F in a 'Open File' window.
> 
> I consider the above a very important example.  If applications can be
> limited in their rights so they aren't given a default 
> ambient set of rights
> but can ask for such rights as they might ask for names, then it seems
> one could get finer grained access control with little to no change to
> a known user interface.
> 
> However, if you try to do the above with an ACL model then it seems
> that you must have some process with the rights to manage an ACL
> for another.  This completely breaks the mutual suspicion paradigm.
> Also, lest that be considered only of academic interest I again point
> to the network communication situation.  In that case you must have
> mutual suspicion.  It's difficult for me to visualize how an ACL based
> mechanism can be used in that case.  Perhaps somebody can clarify.
> 
> >My main claim is that (iv) is not often needed, if you want 
> to talk about
> >confining legacy code at a process granularity.  Or, at 
> least, you can go
> >a really long way without every needing (iv), if your goal 
> is to protect
> >processes from each other.  Yes, (iv) is sorely needed if you want to
> >do things right, break down your app into many smaller 
> pieces that are
> >protected from each other (perhaps by language-based 
> security mechanisms)
> >-- but I don't think that's what Jed Donnelly was talking about.
> 
> Let me clarify my position (Donnelley by the way, like the 
> publisher) a bit.
> What I was saying is that I'm suspicious of efforts to protect parts
> of a shared memory process from other parts - e.g. through language
> module means, etc.  While such means may be useful for finding
> bugs or limiting errors (like automated bounds checking, O-O methods,
> etc.) I don't consider them adequate for security 
> protections.  By that
> I mean any situation where un trusted (read audited if you 
> like) code is
> being used.
> 
> >My second claim is that, for many or most legacy apps, you can do a
> >somewhat reasonable job of supporting (i), (ii), and even (iii) with
> >ACLs or other ambient authority systems.
> 
> Perhaps I need some refining of my definitions here.  Are you saying
> above that ACLs are an ambient authority system?  What I thought
> was meant by that term was in systems (e.g. Unix fork) where processes
> are assumed to have the same (ambient) rights of those who created
> them - typically when an application is started.  I don't believe ACLs
> (at least on a process basis as you seemed to be discussing) fall
> into that category.
> 
> Regardless, my belief (perhaps somebody can straighten me out
> on this?) is that ACLs are a huge perturbation to existing ambient
> authority systems (Unix, Window).  Given that one is going to make
> such a large perturbation anyway I argue, "why not do it right?" and
> use capabilities.
> 
> I'd like to make sure my question about networking gets answered if
> anybody responds to this email.  I am a very network oriented 
> person, e.g.:
> 
> http://www.webstart.com/jed/papers/Components/
> 
> I believe that anything that can be done within a shared memory system
> should also be doable - even with the same interfaces - in a 
> networked system.
> I believe there is substantial practical value in doing so.  
> Only by doing so
> can process interactions be extended across a network without 
> making what
> could be extensive changes to the code managing the 
> interfaces.  I don't see
> how the ACL model extends to network systems.  If it does can somebody
> give me the basic idea?  Of course capability systems have been shown
> to extend quite naturally across networks, e.g.:
> 
> http://www.webstart.com/jed/papers/DCCS/
> http://www.webstart.com/jed/papers/Managing-Domains/
> (one example each of classical c-list and capabilities as data,
> yes tooting my own horn.  Sorry, its easier to find examples.
> I'm sure there are many more - e.g. the Mach extension).
> 
> >No, you can't prevent confused
> >deputy attacks.  Yes, you're still susceptible to all the 
> problems of any
> >ambient authority system, where the app can get confused and 
> inadvertently
> >exercise one if its rights without realizing it.
> 
> That can happen in a capability system as well.  Once a 
> process has been
> given a right - that's it.  It has it and can exercise it - 
> whether in 
> confusion
> or not.
> 
> >It's not perfect --
> >not by a long shot.  But you can still do an awful lot 
> better than what's
> >provided in stock operating systems -- at least the app is 
> not running
> >with the full rights of the user.
> 
> You're right that first level restriction is a huge value to 
> add onto today's
> systems.  However, since in some sense whatever change is made has
> to be invisible to the application, I'm not sure whether the 
> distinction 
> between
> an ACL based approach vs. a capability based approach has any impact
> on the compatibility issue.  It does have an impact on 
> various other issues,
> however - including networking, simplifying interfaces, etc.  
> Can you tell
> me why people are pursuing ACLs rather than capabilities as a model
> for "communicating" rights in the examples you mentioned earlier,
> e.g. SELinux and Systrace?
> 
> --Jed http://www.webstart.com/jed/ 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp.vcf
Type: application/octet-stream
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20040924/3ebe8330/AlanHKarp-0001.obj