[cap-talk] Designation linux kernel patch concept

[David Hopwood]

Rob Meijer wrote:
> On Mon, December 3, 2007 01:52, David Hopwood wrote:
> 
>>  - 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.
> 
> The proposed patch would not do any access controll or dereferencing at
> the system call interposition level, but would only 'record' (within the
> task struct) the designations made by the system call to make it available
> to any LSM that would want to make use of it. I would think that this
> would eliminate any TOCTTOU vulnerability considerations, or am I missing
> something here?

My comments weren't directly about the changes made by the patch,
but they are relevant to the motivation behind the patch.
*If* it isn't feasible to use system call interposition to add
access controls in a TOCTTOU-safe way using the current kernel
interfaces, then that problem is more fundamental than an LSM not
currently being able to get at the fds.

Of course capability systems don't perform access control checks at
the call point anyway. But the design seems to be intended to be more
general than required just to implement a capability system. Also, if
the only safe way to use this interface is not to perform any access
checks on the passed fds, then what are the fds useful for (assuming
that the module can allow the unmodified call to be passed on to the
kernel without knowing them)?

As a separate issue: the patch works by essentially adding the fds to a
dynamically scoped context, in order to avoid changing the LSM interfaces.
Does changing the LSM interfaces really have such a high cost as to
justify this approach? I tend to think that using dynamically scoped
contexts to avoid passing information in parameters is usually a
bad idea that increases complexity. (In this case it requires a mutex
that would not otherwise be necessary.)

--
David Hopwood