CAPs

[Robert Watson]

On Thu, 30 Sep 1999, Aleph One wrote:

> On Thu, Sep 30, 1999 at 07:34:11PM -0400, Robert Watson wrote:
> > 
> > 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.
> 
> I am suprised no one has coded a capd deamon that maintains a filename 
> (or inode) to capabilities mapping that the kernel can query. It would
> get rid of the filesystem problem until cap in ext2fs get implemented.

I guess my concern with this, and some of the other proposed work-around
schemes, has been the race condition issue.  We'd like to avoid any
situations where, through crashing the system or a race condition, a
user-owned file can end up with undesired capabilities.  Quotas maintain
consistency across crashes by regenerating the quote information through a
disk scan each boot ("Checking Quotas..."), but it's not clear whether
that's something you can do with capabilities.  The kernel could be
modified to watch for changes to capability-owning files, but this becomes
a little more kludgy, and still leaves open some races.  Having the
capability mask in the inode probably makes most sense, as we usually
assume atomic disk writes to a single block.

An interesting approach someone raised a little while back on one of the
FreeBSD mailing lists, but that I assume originated on Linux-kernel or the
like, was including the capabilities of a binary in an ELF segment, and
using a digital signature to protect it.  This of courses adds extra
computation in kernel, not good in FreeBSD or Linux as their processes in
kernel aren't preemptible, and also fairly inefficient.

Binding capabilities to a name would probably work -- perhaps a privileged
syscall that binds a name to a capability mask at runtime (via sysctl or
the like) -- the kernel would store it as a binding from vnode to mask,
and on exec, walk down the list of capability vnode list, and if it
matches, provide the rights.  Could also hook modifications to the vnode
to remove the capabilities, in the style of the setuid bit getting removed
on modifications to the binary.  Downside: you'd have to reenter the
capabilities each boot, but upside you lose all the synchronization
issues, et al.

  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