On Thu, Dec 12, 2024 at 12:10 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > 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? I haven't had the time yet to really dig into everything, but one of the things that I noticed very quickly is that the inodes are marked as S_PRIVATE which avoids a lot of the inode level access controls. I believe there are other concerns beyond that, but that is likely the biggest. -- paul-moore.com
