Re: [PATCH 2/2] pidfd: add pidfdfs

[Christian Brauner <brauner@kernel.org>]

On Sat, Feb 24, 2024 at 06:52:41AM +0100, Christian Brauner wrote:
> On Fri, Feb 23, 2024 at 01:58:36PM -0800, Linus Torvalds wrote:
> > On Fri, 23 Feb 2024 at 13:26, Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > So, the immediate fix separate from the selinux policy update is to fix
> > > dbus-broker which we've done now:
> > >
> > > https://github.com/bus1/dbus-broker/pull/343
> > 
> > Why is that code then continuing the idiocy of doing different things
> > for different error conditions?
> 
> Not under my control unfortunately.
> 
> > Also, honestly, if this breaks existing setups, then we should fix the
> > kernel anyway. Changing things from the old anonymous inodes to the
> > new pidfs inodes should *not* have caused any LSM denial issues.
> > 
> > You used the same pointer to dbus-broker for the LSM changes, but I
> > really don't think this should have required LSM changes in the first
> > place. Your reaction to "my kernel change caused LSM to barf" should
> > have made you go "let's fix the kernel so that LSM _doesn't_ barf".
> > 
> > Maybe by making pidfs look exactly like anonfs to LSM. Since I don't
> > see the LSM change, I'm not actually sure exactly what LSM even
> > reacted to in that switch-over.
> 
> This is selinux. So I think this is a misunderstanding. This isn't
> something we can fix in the kernel. If Selinux is in enforcing mode in
> userspace and it encounters anything that it doesn't know about it will
> deny it by default. And the policy is entirely in userspace including
> declaring new types for stuff like nsfs or pidfs to allow it. There's
> just nothing to do in the kernel.
> 
> The Selinux policy update in userspace would always have to happen just
> like it had to for nsfs. Usually that happens after a change has landed
> and people realize breakage or realize that new functionality isn't
> available. This time it's just interacting with bad error handling in
> dbus-broker.

I found the old thread for nsfs for example. Same thing:

https://www.spinics.net/lists/selinux/msg18425.html

"Since Linux 3.19 targets of /proc/PID/ns/* symlinks have lived in a fs
separated from /proc, named nsfs [1].  [...] 
When using a recent kernel with a policy without nsfs support, the
inodes are not labeled, as reported for example in Fedora bug #1234757
[3].  As I encounter this issue on my systems, I asked yesterday on the
refpolicy ML how nsfs inodes should be labeled [4]."

With the asker being pointed to a userspace policy update in

https://spinics.net/lists/selinux/msg18426.html

Honestly, my default reaction is always to test things like that with
various security modules and if I encounter anything that I can fix in
the kernel I do it. But the policies aren't in the kernel. The last link
above explicitly mentions this.