On Thu, Dec 12, 2024 at 11:19 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > 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. Apparently I'm wrong. If you take the sample program shown under EXAMPLES in the pidfd_open man page, you can seemingly run it on any PID in your PID namespace, irrespective of whether you are related to said process, have a different UID, a different context, etc. What am I missing?
