From: Nicolas Iooss <hidden> Date: 2021-02-08 20:37:19
Hello,
Recently there was a bug in Arch Linux where SELinux was no longer
enabled after booting [1], because the default kernel configuration
changed recently [2]:
-CONFIG_LSM="lockdown,yama"
+CONFIG_LSM="lockdown,yama,bpf"
By doing so, setting "security=selinux" on the kernel command line
seemed to break the system, because reading /proc/$PID/attr/current
resulted in "Invalid argument" errors. Replacing "security=selinux"
with "lsm=selinux,lockdown,yama,bpf" fixed the issue and everything is
now fine, but now I am wondering: how should CONFIG_LSM (and option
"lsm" on the kernel command line) be set, on a system which is using
SELinux?
Such information is lacking from the documentation [3] [4]. Therefore
I took a look at Fedora [5] and RHEL [6]:
* Fedora uses CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor",
which was the default value until Linux 5.4 [7].
* RHEL uses CONFIG_LSM="yama,integrity,selinux".
It seems to be strange to have an "outdated" configuration value in
the configuration file, but this could be fine if the new modules are
not expected to be used without the kernel being booted with a
"lsm=..." option.
But there is something that I did not understand: setting
"lsm=selinux,lockdown,yama,bpf" worked, /sys/kernel/security/lsm
showed "capability,selinux,lockdown,yama,bpf", but this violated what
the documentation stated [3]:
"A list of the active security modules can be found by reading
/sys/kernel/security/lsm. This is a comma separated list, and will
always include the capability module. The list reflects the order in
which checks are made. The capability module will always be first,
followed by any “minor” modules (e.g. Yama) and then the one “major”
module (e.g. SELinux) if there is one configured."
Is "lsm=selinux,lockdown,yama,bpf" really problematic?
TL;DR: It would be very helpful if there were some clear guidelines
which were documented in the kernel documentation about how to
configure CONFIG_LSM on SELinux systems.
Thanks,
Nicolas
[1] https://github.com/archlinuxhardened/selinux/issues/81
[2] https://github.com/archlinux/svntogit-packages/commit/69cb8c2d2884181e799e67b09d67fcf7944d8408
[3] https://www.kernel.org/doc/html/v5.11-rc7/admin-guide/LSM/index.html
[4] https://www.kernel.org/doc/html/v5.11-rc7/admin-guide/LSM/SELinux.html
[5] https://src.fedoraproject.org/rpms/kernel/blob/dd9f5d552f96c5171a0f04170dbca7e74e8d13c7/f/kernel-x86_64-fedora.config#_3232
[6] https://src.fedoraproject.org/rpms/kernel/blob/dd9f5d552f96c5171a0f04170dbca7e74e8d13c7/f/kernel-x86_64-rhel.config#_2834
[7] commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=000d388ed3bbed745f366ce71b2bb7c2ee70f449
Hello,
Recently there was a bug in Arch Linux where SELinux was no longer
enabled after booting [1], because the default kernel configuration
changed recently [2]:
-CONFIG_LSM="lockdown,yama"
+CONFIG_LSM="lockdown,yama,bpf"
Neither of these settings will enable SELinux by default.
By doing so, setting "security=selinux" on the kernel command line
seemed to break the system, because reading /proc/$PID/attr/current
resulted in "Invalid argument" errors.
Is this in addition to an "lsm=" specification on the command line?
Replacing "security=selinux"
with "lsm=selinux,lockdown,yama,bpf" fixed the issue and everything is
now fine, but now I am wondering: how should CONFIG_LSM (and option
"lsm" on the kernel command line) be set, on a system which is using
SELinux?
Such information is lacking from the documentation [3] [4]. Therefore
I took a look at Fedora [5] and RHEL [6]:
* Fedora uses CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor",
which was the default value until Linux 5.4 [7].
* RHEL uses CONFIG_LSM="yama,integrity,selinux".
It seems to be strange to have an "outdated" configuration value in
the configuration file, but this could be fine if the new modules are
not expected to be used without the kernel being booted with a
"lsm=..." option.
Keeping the "outdated" configuration values is necessary for
compatibility. We never intended that specifying either of
security= or lsm= on the boot line be required. Because there
is no way to maintain the old behavior of security=selinux
while allowing security=lockdown,yama,selinux we had to introduce
lsm=.
But there is something that I did not understand: setting
"lsm=selinux,lockdown,yama,bpf" worked, /sys/kernel/security/lsm
showed "capability,selinux,lockdown,yama,bpf", but this violated what
the documentation stated [3]:
"A list of the active security modules can be found by reading
/sys/kernel/security/lsm. This is a comma separated list, and will
always include the capability module. The list reflects the order in
which checks are made. The capability module will always be first,
followed by any “minor” modules (e.g. Yama) and then the one “major”
module (e.g. SELinux) if there is one configured."
Is "lsm=selinux,lockdown,yama,bpf" really problematic?
The documentation is out of date regarding the "major" module
having to be last. That was true before the lsm= option was introduced.
TL;DR: It would be very helpful if there were some clear guidelines
which were documented in the kernel documentation about how to
configure CONFIG_LSM on SELinux systems.
Thanks for the feedback. We are at a mid-point in the development of
module stacking. It's not too late to make things better based on your
experience.
From: Nicolas Iooss <hidden> Date: 2021-02-09 06:53:37
On Mon, Feb 8, 2021 at 10:38 PM Casey Schaufler [off-list ref] wrote:
On 2/8/2021 12:35 PM, Nicolas Iooss wrote:
quoted
Hello,
Recently there was a bug in Arch Linux where SELinux was no longer
enabled after booting [1], because the default kernel configuration
changed recently [2]:
-CONFIG_LSM="lockdown,yama"
+CONFIG_LSM="lockdown,yama,bpf"
Neither of these settings will enable SELinux by default.
quoted
By doing so, setting "security=selinux" on the kernel command line
seemed to break the system, because reading /proc/$PID/attr/current
resulted in "Invalid argument" errors.
Is this in addition to an "lsm=" specification on the command line?
My description of the issue was not very clear, my apologies. Here is
another tentative.
For some years, Arch Linux developers have been compiling their
official kernel (https://archlinux.org/packages/core/x86_64/linux/ ;
https://github.com/archlinux/svntogit-packages/tree/packages/linux/trunk)
with CONFIG_SECURITY_SELINUX=y even though SELinux was disabled by
default. In order to use SELinux, users were required to install some
packages (such as systemd with SELinux support) and to add "selinux=1
security=selinux" to their kernel command line. Last week, the
official Arch Linux kernel was updated to use
CONFIG_LSM="lockdown,yama,bpf". Booting a system with this kernel and
"selinux=1 security=selinux" was broken (D-Bus refused to start, as
well as all network services, because systemd failed to get some
important SELinux contexts through /proc/$PID/attr/... files). But
using "selinux=1 lsm=selinux,lockdown,yama,bpf" fixed this issue
(before, there was no lsm= command line).
quoted
Replacing "security=selinux"
with "lsm=selinux,lockdown,yama,bpf" fixed the issue and everything is
now fine, but now I am wondering: how should CONFIG_LSM (and option
"lsm" on the kernel command line) be set, on a system which is using
SELinux?
Such information is lacking from the documentation [3] [4]. Therefore
I took a look at Fedora [5] and RHEL [6]:
* Fedora uses CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor",
which was the default value until Linux 5.4 [7].
* RHEL uses CONFIG_LSM="yama,integrity,selinux".
It seems to be strange to have an "outdated" configuration value in
the configuration file, but this could be fine if the new modules are
not expected to be used without the kernel being booted with a
"lsm=..." option.
Keeping the "outdated" configuration values is necessary for
compatibility. We never intended that specifying either of
security= or lsm= on the boot line be required. Because there
is no way to maintain the old behavior of security=selinux
while allowing security=lockdown,yama,selinux we had to introduce
lsm=.
quoted
But there is something that I did not understand: setting
"lsm=selinux,lockdown,yama,bpf" worked, /sys/kernel/security/lsm
showed "capability,selinux,lockdown,yama,bpf", but this violated what
the documentation stated [3]:
"A list of the active security modules can be found by reading
/sys/kernel/security/lsm. This is a comma separated list, and will
always include the capability module. The list reflects the order in
which checks are made. The capability module will always be first,
followed by any “minor” modules (e.g. Yama) and then the one “major”
module (e.g. SELinux) if there is one configured."
Is "lsm=selinux,lockdown,yama,bpf" really problematic?
The documentation is out of date regarding the "major" module
having to be last. That was true before the lsm= option was introduced.
quoted
TL;DR: It would be very helpful if there were some clear guidelines
which were documented in the kernel documentation about how to
configure CONFIG_LSM on SELinux systems.
Thanks for the feedback. We are at a mid-point in the development of
module stacking. It's not too late to make things better based on your
experience.
On Mon, Feb 8, 2021 at 10:38 PM Casey Schaufler [off-list ref] wrote:
quoted
On 2/8/2021 12:35 PM, Nicolas Iooss wrote:
quoted
Hello,
Recently there was a bug in Arch Linux where SELinux was no longer
enabled after booting [1], because the default kernel configuration
changed recently [2]:
-CONFIG_LSM="lockdown,yama"
+CONFIG_LSM="lockdown,yama,bpf"
Neither of these settings will enable SELinux by default.
quoted
By doing so, setting "security=selinux" on the kernel command line
seemed to break the system, because reading /proc/$PID/attr/current
resulted in "Invalid argument" errors.
Is this in addition to an "lsm=" specification on the command line?
That would imply you do not have CONFIG_DEFAULT_SECURITY_SELINUX=y
That's completely reasonable.
In order to use SELinux, users were required to install some
packages (such as systemd with SELinux support) and to add "selinux=1
security=selinux" to their kernel command line.
Sensible.
Last week, the
official Arch Linux kernel was updated to use
CONFIG_LSM="lockdown,yama,bpf".
This is a list of the modules to be active at boot if
they are available.
Booting a system with this kernel and
"selinux=1 security=selinux" was broken (D-Bus refused to start, as
well as all network services, because systemd failed to get some
important SELinux contexts through /proc/$PID/attr/... files).
Because selinux isn't in the CONFIG_LSM list it is not
going to available from the command line.
But
using "selinux=1 lsm=selinux,lockdown,yama,bpf" fixed this issue
(before, there was no lsm= command line).
The security= and lsm= command line options should not be used
together. The lsm= option is the complete security module list.
The security= option only changes the "major" module for backward
compatibility.
quoted
quoted
Replacing "security=selinux"
with "lsm=selinux,lockdown,yama,bpf" fixed the issue and everything is
now fine, but now I am wondering: how should CONFIG_LSM (and option
"lsm" on the kernel command line) be set, on a system which is using
SELinux?
Such information is lacking from the documentation [3] [4]. Therefore
I took a look at Fedora [5] and RHEL [6]:
* Fedora uses CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor",
which was the default value until Linux 5.4 [7].
* RHEL uses CONFIG_LSM="yama,integrity,selinux".
It seems to be strange to have an "outdated" configuration value in
the configuration file, but this could be fine if the new modules are
not expected to be used without the kernel being booted with a
"lsm=..." option.
Keeping the "outdated" configuration values is necessary for
compatibility. We never intended that specifying either of
security= or lsm= on the boot line be required. Because there
is no way to maintain the old behavior of security=selinux
while allowing security=lockdown,yama,selinux we had to introduce
lsm=.
quoted
But there is something that I did not understand: setting
"lsm=selinux,lockdown,yama,bpf" worked, /sys/kernel/security/lsm
showed "capability,selinux,lockdown,yama,bpf", but this violated what
the documentation stated [3]:
"A list of the active security modules can be found by reading
/sys/kernel/security/lsm. This is a comma separated list, and will
always include the capability module. The list reflects the order in
which checks are made. The capability module will always be first,
followed by any “minor” modules (e.g. Yama) and then the one “major”
module (e.g. SELinux) if there is one configured."
Is "lsm=selinux,lockdown,yama,bpf" really problematic?
The documentation is out of date regarding the "major" module
having to be last. That was true before the lsm= option was introduced.
quoted
TL;DR: It would be very helpful if there were some clear guidelines
which were documented in the kernel documentation about how to
configure CONFIG_LSM on SELinux systems.
Thanks for the feedback. We are at a mid-point in the development of
module stacking. It's not too late to make things better based on your
experience.
Thanks for your quick reply! Anyway it seems that my issue was caused
by an incompatibility between selinux and bpf LSM. On my test system
(running Linux 5.10.11):
* Using "lsm=selinux,lockdown,yama,bpf" works (SELinux is functional,
the system boots fine)
* Using "lsm=lockdown,yama,selinux,bpf" works too
* Using "lsm=lockdown,yama,bpf,selinux" does not work
(/proc/$PID/attr/current raises "Invalid argument")
You can't (currently) use SELinux and BPF at the same time.
This is because the infrastructure does not support multiple
secid<->secctx translation hooks. You get the first one in the
list. BPF provides all hooks, so the SELinux hooks aren't
reached and the secid to secctx translation fails in the
"bpf,selinux" case. The "selinux,bpf" case appears to work,
but the BPF hook for security_secid_to_secctx() will never get
called. This may be acceptable for your use case. Patches to
allow for multiple callers of these hooks are under review.