From: Filip Hejsek <filip.hejsek@gmail.com>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module@vger.kernel.org,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
regressions@lists.linux.dev
Subject: Re: [bug report] [regression?] bpf lsm breaks /proc/*/attr/current with security= on commandline
Date: Thu, 25 Sep 2025 18:25:39 +0200 [thread overview]
Message-ID: <9df66167c205e341bd5896376e06950aa7bd7240.camel@gmail.com> (raw)
In-Reply-To: <CAHC9VhQ-c65UJS+dRaRFn_D=Sq++QXePTsCkN+cV5BVQEbf9fQ@mail.gmail.com>
On Thu, 2025-09-25 at 11:28 -0400, Paul Moore wrote:
> On Thu, Sep 25, 2025 at 10:56 AM Filip Hejsek <filip.hejsek@gmail.com> wrote:
> > On Wed, 2025-09-24 at 17:24 -0400, Paul Moore wrote:
> > > On Sat, Sep 13, 2025 at 1:01 PM Filip Hejsek <filip.hejsek@gmail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > TLDR: because of bpf lsm, putting security=selinux on commandline
> > > > results in /proc/*/attr/current returning errors.
> > > >
> > > > When the legacy security= commandline option is used, the specified lsm
> > > > is added to the end of the lsm list. For example, security=apparmor
> > > > results in the following order of security modules:
> > > >
> > > > capability,landlock,lockdown,yama,bpf,apparmor
> > > >
> > > > In particular, the bpf lsm will be ordered before the chosen major lsm.
> > > >
> > > > This causes reads and writes of /proc/*/attr/current to fail, because
> > > > the bpf hook overrides the apparmor/selinux hook.
> > >
> > > What kernel are you using?
> >
> > I'm using Arch Linux kernel, which is very close to mainline. I have
> > also tested my own build from git sources (I used a stripped down
> > config which I based on config from Arch). Example in QEMU:
> >
> > $ qemu-system-x86_64 -nodefaults -accel kvm -cpu host -smp cpus=2 -m 1G -display none -kernel ~/git/linux/arch/x86/boot/bzImage -initrd ./initramfs.img -serial mon:stdio -append 'console=ttyS0 security=selinux'
> > :: mounting '' on real root
> > mount: /new_root: no valid filesystem type specified.
> > ERROR: Failed to mount '' on real root
> > You are now being dropped into an emergency shell.
> > sh: can't access tty; job control turned off
> > [rootfs ~]# uname -a
> > Linux archlinux 6.17.0-rc7-00020-gcec1e6e5d1ab #3 SMP PREEMPT_DYNAMIC Thu Sep 25 16:28:02 CEST 2025 x86_64 GNU/Linux
> > [rootfs ~]# mount -t securityfs securityfs /sys/kernel/security
> > [rootfs ~]# cat /proc/cmdline
> > console=ttyS0 security=selinux
> > [rootfs ~]# cat /sys/kernel/security/lsm; echo
> > capability,landlock,lockdown,yama,bpf,selinux
> > [rootfs ~]# cat /proc/self/attr/current
> > cat: read error: Invalid argument
> >
> > (Note: In this example, uname reports archlinux, but that's only
> > because I based the config on Arch config, it's not actually an Arch
> > kernel.)
> >
> > Maybe the different behavior is caused by a different config? You can
> > find the Arch config at [1]. Based on Fedora package sources, I think
> > their config has
> >
> > CONFIG_LSM="lockdown,yama,integrity,selinux,bpf,landlock,ipe"
> >
> > while the Arch config has
> >
> > CONFIG_LSM="landlock,lockdown,yama,integrity,bpf"
>
> That's interesting, you're running a LSM that isn't normally run in
> your distro and you're not properly initializing it (no policy load).
> Both are acceptable, but you're definitely operating in the
> corner-iest of corner cases ;)
>
> I'd have to look at the relevant code, but I suspect that with
> "selinux" missing from the CONFIG_LSM list and you manually specifying
> it on the kernel command line with "security=selinux" you are getting
> it placed at the very end as opposed to what I saw (I have "selinux"
> in my CONFIG_LSM list). It's further complicated by the fact that the
> procfs call into the LSM's security_getprocattr() hook is going to
> pass a 0/zero into the hook as the @lsmid which means "first
> available".
>
> Considering that the "security=" parameter is a legacy option, I'd
> encourage you to try the "lsm=" parameter (make sure you specify the
> full list of LSMs you want, in order) to see if that works.
Yes, that works.
The problem isn't that there wouldn't be any working configuration. The
problem is that a userspace program (in my case CRIU) was broken and I
had to spend time figuring out what the cause of the issue was. I'm not
the only one who encountered this issue [1]. I know that at least
Manjaro Linux used to ship a grub config with security=apparmor at some
point (and maybe still does). I no longer use Manjaro Linux, but I
still had this parameter left in my grub config.
[1]: https://github.com/checkpoint-restore/criu/issues/2033
So in reporting this issue, I was just hoping to help future users
avoid the same problem. If you think this is a waste of time, feel free
to ignore this (and sorry I didn't make this clear in the first email).
Lastly, I will offer a few thoughts:
* The fact that the security parameter can break programs like this is
highly non-obvious and undocumented.
* The BPF LSM hook which causes this breakage is useless, because a
BPF program cannot be attached to it. I think it would make sense to
just remove it.
* Switching to using /proc/*/attr/<lsm>/* solves the problem from the
userspace side. Unfortunately, selinux does not have its
subdirectory in attr.
Kind regards,
Filip Hejsek
next prev parent reply other threads:[~2025-09-25 16:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-13 17:01 [bug report] [regression?] bpf lsm breaks /proc/*/attr/current with security= on commandline Filip Hejsek
2025-09-24 21:24 ` Paul Moore
2025-09-25 14:56 ` Filip Hejsek
2025-09-25 15:28 ` Paul Moore
2025-09-25 16:25 ` Filip Hejsek [this message]
2025-09-25 19:07 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9df66167c205e341bd5896376e06950aa7bd7240.camel@gmail.com \
--to=filip.hejsek@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=regressions@lists.linux.dev \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.