On 1/8/20 11:26 AM, Ondrej Mosnacek wrote:
On Wed, Jan 8, 2020 at 5:08 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 1/8/20 12:57 AM, Paul Moore wrote:
On Tue, Jan 7, 2020 at 3:22 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
Deprecate setting the SELinux checkreqprot tunable to 1 via kernel
parameter or /sys/fs/selinux/checkreqprot. Setting it to 0 is left
intact for compatibility since Android and some Linux distributions
do so for security and treat an inability to set it as a fatal error.
Eventually setting it to 0 will become a no-op and the kernel will
stop using checkreqprot's value internally altogether.
checkreqprot was originally introduced as a compatibility mechanism
for legacy userspace and the READ_IMPLIES_EXEC personality flag.
However, if set to 1, it weakens security by allowing mappings to be
made executable without authorization by policy. The default value
for the SECURITY_SELINUX_CHECKREQPROT_VALUE config option was changed
from 1 to 0 in commit 2a35d196c160e3 ("selinux: change
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE default") and both Android
and Linux distributions began explicitly setting
/sys/fs/selinux/checkreqprot to 0 some time ago.
Signed-off-by: Stephen Smalley <sds@xxxxxxxxxxxxx>
---
RFC-only, not yet tested.
Documentation/admin-guide/kernel-parameters.txt | 1 +
security/selinux/Kconfig | 3 +++
security/selinux/hooks.c | 4 ++++
security/selinux/selinuxfs.c | 6 ++++++
4 files changed, 14 insertions(+)
No objection so long as the testing goes okay, although I don't think
we will see any surprises.
Booting with this patch did produce one surprise; it logged a warning
claiming that checkreqprot was set to 1 via kernel parameter on Fedora.
This was incorrect; it is actually defaulted to 1 via kernel config on
Fedora (Fedora kernel config still has
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 at least in F31), so I
moved the check to checkreqprot_setup() so that it will only log if
explicitly set via kernel parameter. Fedora is switching checkreqprot
to 0 from systemd-tmpfiles via an entry in
/usr/lib/tmpfiles.d/selinux-policy.conf, so at least it isn't left as 1
after startup.
Interesting... should I send a PR to change the kernel config on
Fedora? Does anyone know why the
/usr/lib/tmpfiles.d/selinux-policy.conf approach was used instead of
just setting the kernel config option to 0? I assume the config option
just didn't exist yet back then?
Yes, I would recommend doing so since the config option is being
deprecated too. The config option predates git so I don't think that
was the issue; it was probably just a case of the SELinux userspace
maintainers being able to package a tmpfiles.d config file easily and no
kernel developer pushing the corresponding change.
I could see this potentially creating problems for architectures that
still default to VM_EXEC being included in their VM_DATA_DEFAULT_FLAGS.
For those, we might need to disable the FILE__EXECUTE check on
mmap/mprotect just as we do for PROCESS__EXECMEM.
