Re: The curious case of pidfs and pidfds

On Wed, Dec 11, 2024 at 10:49 PM Paul Moore <[email protected]> wrote:
>
> Late last year Chris sent an email[0] about the increasing use of
> pidfds on modern systems and the difficulty in distinguishing between
> pidfds and other file descriptors when passing or inheriting fds
> across a process boundary.  A few months later there was a similar and
> very brief discussion on a related GitHub PR[1] to add some basic
> enablement in refpol.  Unfortunately both discussions faded without
> much in the way of resolution and I'm concerned that we don't have a
> (good) plan for handling pidfds.
>
> As we are starting to see pidfds become more common (which I view as
> an overall positive), the lack of a good way to handle pidfds is
> becoming more of an issue.  Having just started to look at some of the
> kernel code a couple of hours ago (see fs/pidfs.c) I'm worried that
> many of the access controls we have for /proc/PID may be missing or
> bypassed with pidfds and their associated inodes.  I haven't spent a
> lot of time on this just yet, and with the upcoming holidays it isn't
> clear how far I'll get before the end of the year, but I wanted to
> send out another email on this topic to see if anyone else has spent
> any time looking at pidfds and pidfs.
>
> Anyone?
>
> [0] https://lore.kernel.org/selinux/[email protected]
> [1] https://github.com/SELinuxProject/refpolicy/pull/762

I could be wrong, but I think pidfds are controlled via ptrace hooks
and those check the task label rather than whatever random inode is in
the pidfd.