Re: The curious case of pidfs and pidfds

On Thu, Dec 12, 2024 at 12:10 PM Stephen Smalley
<[email protected]> wrote:
> On Thu, Dec 12, 2024 at 11:19 AM Stephen Smalley
> <[email protected]> wrote:
> >
> > 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.
>
> 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