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

[David Wagner]

Jed Donnelley wrote:
>At 02:10 PM 9/23/2004, David Wagner wrote:
>>(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.

Oops.  Sorry.  Sloppy drafting on my part.  I had intended this to mean
that a process could manipulate its own privilege set, for instance to
(temporarily or permanently) drop privileges in the middle of execution.
Note that this is not a terribly ambitious requirement.

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

Again, probably sloppy drafting.  That was not my intent.  Rather, my
intent was that if process X has right R, then probably there should be
some way for X to convey R to another process Y (assuming both X and Y
would like this transfer to succeed).  Maybe that is passing capabilities,
or transferring a file descriptor, or cloning X asking the OS to clone an
ACL entry that X has and replace X's name with Y's name.  I don't care
how it is achieved; I was trying to be mechanism-neutral.  And I hadn't
intended to characterize this category by some kind of "nirvana".
Rather, my intention was that this category would include pretty much
any system with some way to do rights transfer, some way that is not a
total grody hack.

The claim later in my message is that surprisingly, (iv) does not seem
to be a critical requirement.  You can make some real progress even if
all you have is (iii) and no support for rights transfer.  For instance,
Systrace, Janus, and similar systems provide no way (or no clean mechanism)
to allow confined process X to tell the monitor (Systrace, Janus, whatever)
to convey one of its rights to confined process Y.  Instead, in those
systems, process Y is stuck with whatever rights it is given, and Y cannot
acquire extra rights from other processes, even if those other processes
want to lend their rights to Y.  The lack of support for rights transfer
is not an intentional design goal of those systems; they just didn't do
anything to support rights transfer, and the observation I was making is
that you might be surprised how much progress you can get without such
support.  This is probably more of a statement about how bad existing OS's
are at confinement than anything 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?

No.  It is highly ad-hoc, application-dependent, and unautomated -- in
short, an inelegant time-consuming kludge.  But I think it can be done for
a number of applications.

>>You can derive this set very elegantly using capabilities,
>
>I'm not aware of any way capabilities help you with the syntactic issues.

Not with the syntax, it is true.  If your interface is to pass a list
of capabilities (rather than a list of filenames) to the process, then
it makes it easier to tell what rights the process should be given.  But
if the user really wants to be typing in filenames rather than capabilities,
well, you still have to turn the filenames into capabilities, and that's
still a non-trivial problem, as you say.

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

Sure.  Systrace manages the rights for the process it confines.
It is analogous to the way that an OS manages the rights for the
processes running on top of it; there is no mutual suspicion between
the OS and user-level processes, since there is nothing user-level
processes can do to defend themselves from the OS.  If you think of
Systrace as an extension to the OS's reference monitor, you'll be on
the right track.  The interesting observation is that Systrace is
still useful even though we've violated mutual suspicion (between
the confined app and Systrace).

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

I'm not sure what I'm saying.  I probably was throwing around terms
like "ACLs" carelessly.  In retrospect, I think what I was trying to
say is that I can divide the world into two camps:
  camp (a)'s philosophy: "the solution is to use capabilities".
  camp (b)'s philosophy: "do whatever works, without regard to whether
      it technically uses ACLs, capabilities, or something else".
In practice, the "do whatever works" camp has often ended up building
solutions that use ACLs, not because they have some special preference
for ACLs, but as more of an accident and because ACLs happened to be
the easiest first thing to implement and because they seemed to work.
For instance, Janus and Systrace both specify and store their policy
in a way that I suspect probably qualifies as an ACL, and certainly
qualifies as an ambient authority system.

The claim I think I wanted to make is that existing practice (built
by people in the "do whatever works" camp, and usually is some naive
ACL system) gets you 80% or 90% as far as capabilities would, for the
problem of retrofitting least privilege onto legacy apps and failed OS's.

I suppose I was using the term "ACL system" to mean one where somewhere
there is a list of entries, where each entry says something like "process
X is allowed to perform action A on object O".  Somewhere there is some
reference monitor who consults this list when deciding which actions to
allow.  This is a somewhat sloppy use of the term "ACL system", I confess.

I think of an ambient authority system as one where the process has
a bag of rights, and when taking an action does not need to specify
which right is being wielded.  Rather, the reference monitor just checks
whether any of the rights in the process's bag would suffice to allow
this action, and if so, allows the action.  I don't know if this is
a very precise description, but I hope it makes sense.

All of the kind of projects I'm talking about here -- Systrace, Janus,
etc. -- are ambient authority systems.  If you're talking about confining
legacy apps, I think you're pretty much stuck with ambient authority.
If the program wasn't originally written to designate explicitly which
right (from among the program's bag of rights) was intended to be wielded
on each action, then I suspect you're stuck.  I don't see how to divine
the programmer's intent if all you are given is legacy code not written
according to capability style.

>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 don't see it.  I see systems like Janus or Systrace as the obvious
shortest path to make progress on the problem they want to solve.
(The problem they are trying to solve is (roughly) best-effort least
privilege for some large set of legacy apps running on failed OS's.)
If "do it right" means to re-write all apps in a capability style, well,
that's an entirely different universe.  The answer to "why not re-write
all our apps from scratch?" is pretty obvious.

>I'd like to make sure my question about networking gets answered if
>anybody responds to this email.

Sorry, I don't have any insights about the network case.  I tend
to think more about securing software.  I don't know what works for
securing distributed systems, and I don't know whether what works best
for distributed systems is the same as what works best for software
security on a single host.  I hope someone else will be able to respond
more usefully on this point.  My apologies.

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

I don't see it.  I'm not talking about a malicious process; I'm talking
about a well-intentioned process that is nonetheless somewhat gullible
and can be tricked into using one of its privileges in a way that it
would not have wanted to.  In particular, if your app uses capability
style programming, the confused deputy attack is prevented.  See Norm
Hardy's attack.  The problem comes when a process has two rights; if
the process asks the OS to take some action and does not communicate
explicitly which right the programmer had intended to use for this action,
then the process can (sometimes) be tricked into wielding the wrong
right for this action.  This is exactly the confused deputy attack.
Capability style programming prevents this by making explicit which
right the programmer intended to wield.

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

They're not.  Or at least, they're not pursuing ACLs specifically so
much as just trying to solve the problem whatever way occurs to them.
It's not that they've decided "ACLs are better, and darn it, I refuse to
use capabilities".  Rather, they're just building whatever is easiest
and works.  If you want to suggest to them that "no, you should only
use capabilities, and never use anything else; capabilities are better
than what you're doing now", you need to make the case that changing
what they do will provide sufficient benefits to be worth the change.
It's a question of where the burden of proof lies.