[cap-talk] Designation linux kernel patch concept

[Rob Meijer]

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?

Rob