CAPs

[Robert Watson]

On Thu, 30 Sep 1999, James Buster wrote:

> On Sep 30,  7:34pm, Robert Watson wrote:
> } You may want to take a look at my capabilities-related post earlier this
> } year, and also at the Linux implementation.  My main object to the
> } POSIX.1e capabilities was that many of them seem equivilent when viewed in
> } the context of UNIX.
> 
> I assure you they aren't. they are only "equivalent" if you are
> maintaining the notion of a superuser.
> 
> } For example, the ability to read any file or write any file can give you
> } control over the authentication system
> 
> The ability to read things gives you no control. Only the ability to
> *write* authentication or audit data can do that. The read capabilities
> are relatively harmless as far as capabilities go. Except for the case
> of getting data like passwords, being able to read anything is not
> especially interesting as far as being able to take control of a system
> is concerned. What you really want is to be able to change authentication
> data and hide the fact by altering audit data.

With systems such as kerberos, or in the era of effective encrypted
password cracking programs, the ability to read all files would reveal the
authentication secrets, allowing the holder of the readall capability to
gain other privileges.  Secrets are fairly common-place in the presence of
distributed systems, as cryptographic techniques are used to protect most
network applications.  My observation was really just that I felt that the
capabilities in .1e are perhaps a little too strong--on the other hand,
.1e is just an interface, and doesn't actually significantly influence how
you actually implement things.  Overriding "read all" for specific data
would be quite feasible for a key-management system.

The other problem with read-all has to do with procfs, and the mapping of
other non-resources to file systems in that UNIX-esque kind of way.

> } However, the Linux people have defined a set of capabilities that are
> } perhaps more useful in a traditional UNIX environment rather than one
> } completely rewritten to be a trusted operating system.
> 
> The Linux people are 
> 	a) using an old draft of 1e
> 	b) unnecessarily conflating read and write privileges

I haven't looked all that closely at their implementation.  I will go take
a look in detail this evening.

> } The real barrier to plain-old-bitwise capabilities is getting file system
> } integration--as I understand it, this has held up the Linux folks.  I
> } believe they have all the code in a kernel, but that Ext2fs doesn't have
> } the meta-data available.
> 
> The kernel is completely missing inherited or permitted capability
> vectors.

Given the general good feelings about role-based access control in the
security research community, I'm a little surprised the POSIX.1e draft
doesn't try and map some of these things to roles, as opposed to directly
to fs objects.  Have any of you looked at the DTE work at TIS/NAI?

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message