[9fans] capability-based design (Re: permissions idea)

[Richard <greon@best.com>]

Douglas A. Gwyn writes:

>  The only
>viable solution I know of is for *every* mode of access
>to *every* object to require the accessor to possess an
>appropriate "capability".

word.  let me give the reader a little taste of capability-based
design, for those who might not know it.  In a capability-based OS, a
program does not have free access to the filesystem.

suppose that in Plan 9 the shell and the rm command were rewritten so
that in the execution of the command

  rm foobar

the shell opened the file foobar and passed the open file descriptor to
rm.  (this would of course mean expanding the argc/argv interface so
that not only strings but also file descriptors can be passed in.)
suppose further that all commands worked this way, and that the OS
prevented commands (programs) from directly opening files.  well, more
precisely, suppose that the open subroutine would obtain the user's
permission before opening the file.

in such an OS, a command cannot modify the filesystem behind the user's
back.  in contrast, in Unix and Plan 9, a command written by a malicious
programmer can, eg, erase or introduce errors into a user's data files.

the risk of inadvertently running a malicious program is not a big
problem in practice for many of us, so the reader might not be attracted
to the idea of changing things just to avert that risk.  note though
that the capability ("capa") design averts the risk without adding a lot
of new code (as the stupid idea of digital immune systems does), but
rather mainly by readjusting the interface between shell and command.
elegant!

a more practical benefit of the capa approach that might appeal more to
the average desktop user is the discipline it imposes on app writers.
specifically, the app must asks permission (from the OS, which
then might ask the user) before doing anything significant to the user's
software environment.  

eg, if a community of users got into the habit, for example, of guarding
the ability to display animated graphics behind a capability, then an
app writer who wanted to distribute an app into that community would
have to write code that explicitly asks permission to display
animations, even if the app already had permission to write static
graphics to the screen.

another, classic example is that if you install Internet Explorer on
Windows, it or its installer is free to fuck up your already-installed
Netscape.  in a capa OS, the IE installer cannot make IE your default
browser without obtaining permission.  this restriction is enforced by
the kernel just like the restriction that the IE installer cannot access
memory belonging to another process.

a typical desktop computer is used by only one person but contains apps
written by thousands of programmers.  if you are like me, you would like
app writers to have less power over the other apps on your desktop and to
make fewer assumptions about your software environment.  this of course,
takes us outside of security per se, into the realm of giving users
more control over apps, not by exhorting app writers to change, but
by introducing a new platform that forces them to change or else
their code does not run.