2020-01-08 09:24:47 -07:00
|
|
|
What: /sys/fs/selinux/checkreqprot
|
|
|
|
|
Date: April 2005 (predates git)
|
|
|
|
|
KernelVersion: 2.6.12-rc2 (predates git)
|
|
|
|
|
Contact: selinux@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
|
selinux: remove the 'checkreqprot' functionality
We originally promised that the SELinux 'checkreqprot' functionality
would be removed no sooner than June 2021, and now that it is March
2023 it seems like it is a good time to do the final removal. The
deprecation notice in the kernel provides plenty of detail on why
'checkreqprot' is not desirable, with the key point repeated below:
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.
Along with the official deprecation notice, we have been discussing
this on-list and directly with several of the larger SELinux-based
distros and everyone is happy to see this feature finally removed.
In an attempt to catch all of the smaller, and DIY, Linux systems
we have been writing a deprecation notice URL into the kernel log,
along with a growing ssleep() penalty, when admins enabled
checkreqprot at runtime or via the kernel command line. We have
yet to have anyone come to us and raise an objection to the
deprecation or planned removal.
It is worth noting that while this patch removes the checkreqprot
functionality, it leaves the user visible interfaces (kernel command
line and selinuxfs file) intact, just inert. This should help
prevent breakages with existing userspace tools that correctly, but
unnecessarily, disable checkreqprot at boot or runtime. Admins
that attempt to enable checkreqprot will be met with a removal
message in the kernel log.
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
2023-03-16 08:43:08 -07:00
|
|
|
REMOVAL UPDATE: The SELinux checkreqprot functionality was removed in
|
|
|
|
|
March 2023, the original deprecation notice is shown below.
|
|
|
|
|
|
2020-01-08 09:24:47 -07:00
|
|
|
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
|
2020-09-27 19:37:01 -07:00
|
|
|
will be removed no sooner than June 2021, at which point the kernel
|
2020-01-08 09:24:47 -07:00
|
|
|
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.
|