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

[David Wagner]

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;
(iii) the process's authorities can be freely modified in the middle of
      the execution of a process; or
 (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.

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.  You can
derive this set very elegantly using capabilities, 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.

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.

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