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@xxxxxxxxxx> 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.
