e9c38f9fc2
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 2a35d196c1 ("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@tycho.nsa.gov>
Signed-off-by: Paul Moore <paul@paul-moore.com>
24 lines
1.2 KiB
Plaintext
24 lines
1.2 KiB
Plaintext
What: /sys/fs/selinux/checkreqprot
|
|
Date: April 2005 (predates git)
|
|
KernelVersion: 2.6.12-rc2 (predates git)
|
|
Contact: selinux@vger.kernel.org
|
|
Description:
|
|
|
|
The selinuxfs "checkreqprot" node allows SELinux to be configured
|
|
to check the protection requested by userspace for mmap/mprotect
|
|
calls instead of the actual protection applied by the kernel.
|
|
This was a compatibility mechanism for legacy userspace and
|
|
for 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 of checkreqprot
|
|
at boot was changed starting in Linux v4.4 to 0 (i.e. check the
|
|
actual protection), and Android and Linux distributions have been
|
|
explicitly writing a "0" to /sys/fs/selinux/checkreqprot during
|
|
initialization for some time. Support for setting checkreqprot to 1
|
|
will be removed in a future kernel release, at which point the kernel
|
|
will always cease using checkreqprot internally and will always
|
|
check the actual protections being applied upon mmap/mprotect calls.
|
|
The checkreqprot selinuxfs node will remain for backward compatibility
|
|
but will discard writes of the "0" value and will reject writes of the
|
|
"1" value when this mechanism is removed.
|