[cap-talk] /dev/fd/N and /proc/self/fd/N

[Mark Seaborn]

Kevin Reid <kpreid at mac.com> wrote:

> Hey, this generalizes. Given a shell at least as capable as bash, you  
> can pipe in multiple non-file sources. e.g.
> 
> foo-cap-receiver <(bar-cap-generator) <(baz-cap-generator)

Incidentally, this feature of Bash does not work under Plash because
the <(...) syntax evaluates to a reference to /dev/fd:

$ echo <(echo foo)
/dev/fd/63

/dev/fd is a symlink to /proc/self/fd, which does not work under Plash
even if you try to grant access to /proc.

It would be possible to implement this.  There are some complications:
 - Opening /dev/fd/N is not the same as dup(N).  Rather than copying the
   file descriptor, the former returns a new file descriptor with a
   different seek state.  It also does some ACL checks.
   (I don't *think* Linux documents this anywhere.)
 - Filename resolution under Plash currently does not know which process
   is asking, and it is done in a separate process from the requesting
   process.

But the deeper question is whether it is a good idea to implement
/dev/fd/N at all.  It looks like it could create new confused deputy
problems.

/dev/fd/N does not index into the list of FD arguments provided by the
caller.  It indexes into the FD table of the callee in whatever state
it happens to be at the time.

Would there ever be any case in which the FD table needs more
protection that the process's default file namespace (as used by
open())?

Or can we assume that if an attacker has got a process to open() an
arbitrary pathname, the process has already lost its ability to defend
itself from the attacker, regardless of whether /dev/fd/N is present?

Mark