On Wed, Dec 11, 2024 at 10:49 PM Paul Moore <paul@xxxxxxxxxxxxxx> 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/da1d9efd-fdc1-4651-8a7a-30ae4a399926@xxxxxxxxxxxxxxxxxxx > [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.
