On Thu, Dec 12, 2024 at 12:48 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > 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. I think that part is ok - IIUC the inodes are just anon inodes and don't actually contain any of the process state and reads/writes of the pidfds don't return or modify process state. The question though is whether any of the pidfd syscalls or ioctls allow one to access the process state without going through some kind of permission check on the task label. It appear that some of the pidfd syscall do apply checking, e.g. pidfd_getfd() checks ptrace access to the target task, pidfd_send_signal() likely hits the usual hook in kill, but others do not, like just polling the pidfd to see when the process exits or the PIDFD_GETINFO ioctl. We're not just talking about a lack of LSM/MAC checks there - there don't appear to be any DAC restrictions either.
