Detected data corruption against SELinux when inserting policy modules

[0xC0ncord]

Sometimes, when using semodule -i *.pp to install a new SELinux module or update an existing one, LKRG detects this as an attack against the internal state of SELinux.

This error was recorded on a 5.10.19 system running in permissive mode while updating a policy module:

[  940.327546] [p_lkrg] <Exploit Detection> Detected data corruption against SELINUX! 'selinux_state->enforcing' has different value [216 vs 168] than expected!

I haven't found a reliable way to reproduce this behavior, but in the cases where it occurs, it occurs consistently on the same system even after a reboot.

[0xC0ncord]

Here is another case (with additional log verbosity) where a new module was being installed:

[ 1286.684815] SELinux:  Converting 945 SID table entries...
[ 1286.698688] SELinux:  policy capability network_peer_controls=1
[ 1286.698690] SELinux:  policy capability open_perms=1
[ 1286.698691] SELinux:  policy capability extended_socket_class=1
[ 1286.698691] SELinux:  policy capability always_check_network=0
[ 1286.698692] SELinux:  policy capability cgroup_seclabel=1
[ 1286.698693] SELinux:  policy capability nnp_nosuid_transition=1
[ 1286.698693] SELinux:  policy capability genfs_seclabel_symlinks=0
[ 1286.785698] [p_lkrg] Removing ED pid => 47088
[ 1286.791601] [p_lkrg] Hash from CPUs metadata => [0x8ab44ce6b79e2c1b]
[ 1286.791609] [p_lkrg] Hash from kernel exception table => [0x4e32f2f23073735a]
[ 1286.797523] [p_lkrg] Hash from _stext memory block => [0x2b87b3a42e6fcb00]
[ 1286.800405] [p_lkrg] Hash from _rodata memory block => [0x96717cf3fb49c22d]
[ 1286.800407] [p_lkrg] Hash from IOMMU table => [0xffffffff]
[ 1286.800408] [p_lkrg] Hash from 'module list' => [0xcd82525b9c2cd1fb]
[ 1286.800409] [p_lkrg] Hash from 'module kobj(s)' => [0x40e8e38bc0e48247]
[ 1286.800846] [p_lkrg] <Exploit Detection> Detected data corruption against SELINUX! 'selinux_state->enforcing' has different value [88 vs 216] than expected!

[Adam-pi3]

Do you have enabled GCC_PLUGIN_RANDSTRUCT ?

[0xC0ncord]

Do you have enabled GCC_PLUGIN_RANDSTRUCT ?

Yes.

[Adam-pi3]

Currently, our SELinux protection logic is incompatible with GCC_PLUGIN_RANDSTRUCT since kernel 5.6. Without GCC_PLUGIN_RANDSTRUCT or if GCC_PLUGIN_RANDSTRUCT is enabled but kernel < 5.6 it works fine. We are aware of that and we are working on a proper fix to support SELinux protection on kernels 5.6+ with GCC_PLUGIN_RANDSTRUCT.
@oshogbo is driving this changes.

[solardiz]

@Adam-pi3 Since getting this fixed properly is taking a long while, maybe you can meanwhile disable the known-buggy functionality in LKRG? That is, exclude "SELinux protection on kernels 5.6+ with GCC_PLUGIN_RANDSTRUCT."

[Adam-pi3]

In fact, yesterday I've been talking with @oshogbo and reviewing his changes and after some suggestions it work up to the kernel 5.11. We are working now to add support for 5.11+.

maybe you can meanwhile disable the known-buggy functionality in LKRG?

I think we can add it but we would need to revert such changes relatively soon. As soon as 5.11+ support will be done. We can also push the current changes but it won't work for 5.11+

[solardiz]

Great news that progress is being made on this. Not having seen those WIP changes, I don't know how close to being ready they actually are. It may well make sense to disable the broken functionality meanwhile.

[solardiz]

Checking our e-mail discussion from January, besides the issue with RANDSTRUCT there's also the issue with LKRG not supporting CONFIG_SECURITY_SELINUX_DISABLE=n:

You assume CONFIG_SECURITY_SELINUX_DISABLE is defined.  If it is not,
then fields shift by one, and LKRG ends up checking "checkreqprot"
instead of "enforcing".

Then, you define the "avc" and "ss" fields where the current revision of
the struct has different fields.  Since LKRG doesn't use those fields,
it's sort of fine, but it's better not to even define the unused fields.

Perhaps you can fix this other issue without waiting on @oshogbo?

[Adam-pi3]

Perhaps you can fix this other issue without waiting on @oshogbo?

In fact, the upcoming changes will address it as well. I think it's better to focus more on adding support for 5.11+ and speed-up that work. It will fix all the problems :)

[sempervictus]

Does the RANDSTRUCT problem exist when LKRG is built into the kernel with access to the struct layouts at compile time and the seed used?

[solardiz]

@0xC0ncord This issue should be fixed by #57, which is merged. Can you please test and confirm, and if so close the issue? Thanks!

[0xC0ncord]

@solardiz So far I haven't been able to reproduce the issue since building from master and using the same kernel, so it looks to be solved. Hopefully soon we can reinstate SELinux protections when RANDSTRUCT is in use in the future however. Going to close this since the original issue has been resolved.