From: David Wagner <daw@cs.berkeley.edu>
Date: Tue, 3 Dec 2002 15:43:05 -0800 (PST)
Subject: [e-lang] capability myths demolished!

Zooko writes:
>I believe that ACLs can also implement the same text editor POLA story,
>but only 
>by using the superuser/administrator account to create a new principal, and 
>changing your UID to that principal before running the text editor.

It depends what you mean by ACLs.  Some ACL systems can readily support
the same POLA story without requiring the involvement of the superuser. 

There's a key principle here: 
  Programs ought to be able to voluntarily relinquish privileges
  before undertaking certain operations.
It is essential that this can be done in a fairly fine-grained and
flexible way, if we want to fully take advantage of the principle of
least privilege (what you'd call POLA). ping

Some ACL-based systems do support this.  Some don't.   But my claim is
that whether you support this principle is largely independent of whether
you use ACL's.

For instance, standard Unix systems have only limited support for this
principle.  A process can be running as root, or as a non-root user. 
Root processes can relinquish some privileges by calling setuid() to
become a non-root user.  However, this has a lot of limitations.  It is
very coarse-grained.  It is not available to ordinary (non-root) programs.
And so on. cg

But we could certainly imagine a Unix derivative with much better support
for this.   For one example of what such a design might look like, have a
gander at the following papers:
  Sotiris Ioannidis and Steven M. Bellovin,
  "Building a Secure Web Browser", Usenix Conference, June 2001.
  http://www.research.att.com/~smb/papers/sub-browser.ps

  Sotiris Ioannidis, Steven M.  Bellovin, and Jonathan Smith,
  "Sub-Operating Systems: A New Approach to Application Security",
  SIGOPS European Workshop, September 2002.
  http://www.research.att.com/~smb/papers/subos.pdf
Basically, every user can dynamically create a sub-userid and delegate
some of its authority to that sub-userid.  For instance, if I ("daw")
want to download Netscape and run it in a restricted execution environment,
I can create a new userid ("daw.netscape") for it (you can imagine I
might give it access only to "~/.netscape/*" and "/tmp/*").  If Netscape
then wants to run a plugin in a further-restricted environment, we
could imagine it creating a new userid ("daw.netscape.shockwave") with
some further delegation.  There would be a lot of details to work out,
and I don't claim to have a full idea of what such a system would look
like or how well it would work, but it seems plausible that this could
support the POLA story in an ACL-like world.

My conclusion is that there are two different goals one might shoot
for in a security-aware programming environment: good support for 
the principle of least privilege, and combining designation with
authorization.  (It seems ACLs can provide the former, even if they
don't provide the latter.)  And it seems to me that we ought to try
to understand each of these different goals, if we're going to make
a fully persuasive case for E-style capabilities systems. marcs
_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang