[cap-talk] Designation linux kernel patch concept

[David Hopwood]

Rob Meijer wrote:
> --------------------------------------------------------------------
> This short text describes a possible patch to the linux kernel that
> would allow linux security modules to use file descriptors and directory
> file descriptors as tokens of authority, [...]

It seems to me that using fds as (essentially) capabilities for files
does not quite work, because:

 - an fd to an open file can't be safely used to designate the file
   itself, if duplicates of the fd are to be shared between processes.
   That is because the duplicates share attributes that you don't want
   to be shared, such as the O_NONBLOCK flag (see
   <http://plash.beasts.org/wiki/UsefulKernelChanges>
   and <http://lkml.org/lkml/2007/8/14/135>).

 - there is no fd type that designates just a file inode.

 - to do system call interposition in a way that is safe against
   race conditions, you *really* need an fd type that designates a
   file inode. Let's say that you are interposing on one of the "at"
   calls, and you do a security check based on the dirfd and the
   relative path. The check passes, so you forward the call to the
   kernel. But how do you know that by the time the kernel
   interprets the dirfd and path, it is pointing to the same file?
   You don't. As pointed out in
   <https://db.usenix.org/events/woot07/tech/full_papers/watson/watson.pdf>,
   such race conditions are quite exploitable in practice.

   If you could resolve a dirfd and relative path to an inode fd,
   *and* could then perform an equivalent operation to the original
   call on that inode fd, then no race condition could occur. In
   that case you could also share the inode fds safely between
   mutually untrusting processes.

> and to distinguish between
> situations were access is requested directly and situations where a
> delegated Fd is used as a source of delegated authority.
> 
> The linux syscall API basically has 3 sets of system calls where
> both a path based and an Fd based version exists, and from recent
> discussion on the cap-talk and AppArmor mailinglist it is asumed
> that an LSM may wish to implement aditional sets.

Each path-based call is always equivalent to the corresponding "at"
call with a dirfd of AT_FDCWD. So it's the "at" calls that are
(currently) primitive, and the path-based calls are just convenience
functions -- whatever the historical order of development.

However, the "at" calls don't have the right interface to be used with
an inode fd. It would be bordering on insane to add yet another set of
API calls and/or syscalls (and it would beg the question, "how many
more iterations will we need to get this right?"). Maybe the "at"
calls could be used with NULL for the relative path (but that's
off-the-cuff invention, and I haven't thought very hard about whether
it is a good idea).

-- 
David Hopwood