Re: Memory protection checking
On Wed, Jun 2, 2021 at 6:08 PM Abhijit Tikekar <abhijittikekar(a)gmail.com> wrote:
All,
Just stumbled upon the following setting for selinux
Memory protection checking: actual (secure)
I could not find any documentation around this. Can anyone point me in the right
direction? Is this something controlled separately or related to certain booleans being
active?
This corresponds to the "checkreqprot" flag, which can be set via the
"checkreqprot" kernel boot parameter or by writing to
/sys/fs/selinux/checkreqprot and the default value can defined via the
SECURITY_SELINUX_CHECKREQPROT_VALUE kernel build config option.
The flag is probably best described in the kernel config's help text
(see security/selinux/Kconfig in kernel sources):
"""
This option sets the default value for the 'checkreqprot' flag
that determines whether SELinux checks the protection requested
by the application or the protection that will be applied by the
kernel (including any implied execute for read-implies-exec) for
mmap and mprotect calls. If this option is set to 0 (zero),
SELinux will default to checking the protection that will be applied
by the kernel. If this option is set to 1 (one), SELinux will
default to checking the protection requested by the application.
The checkreqprot flag may be changed from the default via the
'checkreqprot=' boot parameter. It may also be changed at runtime
via /sys/fs/selinux/checkreqprot if authorized by policy.
WARNING: this option is deprecated and will be removed in a future
kernel release.
If you are unsure how to answer this question, answer 0.
"""
...and in the deprecation note for /sys/fs/selinux/checkreqprot added
recently (see Documentation/ABI/obsolete/sysfs-selinux-checkreqprot):
"""
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 no sooner than June 2021, 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.
"""
Setting this option to "1" is now deprecated and the kernel will soon
implement only the "0" behavior and reject "1". It is just a relic
from the past and everything should be using 0 by now (Fedora does for
a long time and has it as the default boot-time value since about a
year ago [1].
[1]
https://gitlab.com/cki-project/kernel-ark/-/commit/d45e8699ebc093cab3f140...
--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.