linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).