[e-lang] "Capability Myths Demolished" (was: Software security workshop)

Hal Finney e-lang@mail.eros-os.org
Wed, 27 Nov 2002 14:34:18 -0800


Mark Miller writes:
>                "Capability Myths Demolished" 
> at http://www.erights.org/elib/capability/duals/index.html
>
> As the red text at the top explains, I already know this essay is broken in 
> some ways. But without more feedback I'm not getting around to fixing it, so 
> fire away.  Even in its current flawed state, I think many of you will still 
> find it quite interesting -- perhaps even outrageous.

I find one thing confusing about the question of whether capabilities
and ACLs are two different ways of looking at an accessibility matrix.
This also appears in the linked-to essay by Jonathan Shapiro at
http://www.eros-os.com/essays/ACLSvCaps.html.

Both essays claim that while this equivalence might be true in a trivial
mathematical sense, it overlooks the fact that ACLs are described in
terms of principals, aka users, as the accessors.  Capabilities on the
other hand are owned by processes or programs, such that their ownership
is at a finer level of granularity than ACLs.  Each user will in general
be running multiple programs over a period of time and each could have
its own set of capabilities, while they would in general all be treated
the same in an ACL.

The problem with that is that it is quite common on my Linux system,
which I believe would be considered an example of a use of ACLs, to have
more access rules than just those associated with users as principals.
In particular, programs can be associated with accounts who don't
correspond to any real individual.  In fact my /etc/passwd file looks
like:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/home/ftp:
nobody:x:99:99:Nobody:/:
hal:x:500:500:"Hal Finney":/home/hal:/bin/bash
xfs:x:100:233:X Font Server:/etc/X11/fs:/bin/false
gdm:x:42:42::/home/gdm:/bin/bash
named:x:25:25:Named:/var/named:/bin/false
mailnull:x:47:47::/var/spool/mqueue:/dev/null
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/bin/false

(Hopefully I haven't opened my system up to attack by publishing this;
if so please let me know, and perhaps we can remove this message from
the archives!)

Anyway, I don't even know what most of these accounts are.  I didn't
put them there, and they certainly aren't people who ever log in to
my computer.  In fact, new ones seem to appear from time to time as I
upgrade my system, which causes me some uneasiness from the security
perspective, but most of them seem legitimate enough.

Clearly most of these names are associated with programs and processes.
They exist so that particular programs can be run with a specific set of
access permissions.  They are a mechanism by which an ACL can be expanded
beyond the simple model which seems to be expressed in these two papers.

Now it may still be true that in practice, capability systems have far
finer granularity even than my Linux system with its 20-odd accounts.
I could imagine a Linux system with perhaps 100 or even 1000 accounts;
but not one with a million accounts, and perhaps a capability system
could have that many or more capabilities in action over a period of time.

So the point may still be valid that capabilities lend themselves to an
architecture with extremely fine-grained granularity of access, and that
distinguishes them from ACLs.  But the exposition is a little unclear for
users whose familiarity with ACLs comes from widely used free software.
Perhaps the notes could address the issue of having accounts for the
special use of particular programs.

Hal Finney