I got strange SELinux message appear in dmesg just now out of nowhere that look bad. I’m not sure what it is and what caused it. Please help.
SELinux: Converting 631 SID table entries…
SELinux: policy capability network_peer_controls=1
SELinux: policy capability open_perms=1
SELinux: policy capability extended_socket_class=1
SELinux: policy capability always_check_network=0
SELinux: policy capability cgroup_seclabel=1
SELinux: policy capability nnp_nosuid_transition=1
SELinux: policy capability genfs_seclabel_symlinks=1
SELinux: policy capability ioctl_skip_cloexec=0
It is probably a new kernel version which now write information messages about how SELinux is set up. Previously it could have set up SELInux in exact the same way but didn’t write the information messages.
If you run journalctl -k you get the dmesg messages with color coding the severity of the messages.
These messages are normal and just contain information about your SELinux condition. These are no warnings or so. You should also have had them with earlier kernel versions.
In some circumstances such information could be interesting to indicate/explain unintended behavior and such, which is why the kernel adds it to its logs. You can ignore that.
Actually, it is even good, as it indicates that SELinux is there and does something as intended.
2 Likes
These messages appeared a few days after 6.8.11 arrived here on June 2, so kernel 6.8.11 may have added a capability that is now being used by selinux-policy-40.22-1.fc40.noarch:
journalctl --no-hostname -k -g 'SELinux:.*policy capability network_peer_controls=1'
Jun 10 12:32:57 kernel: SELinux: policy capability network_peer_controls=1
Jun 14 09:32:06 kernel: SELinux: policy capability network_peer_controls=1
Jun 14 09:32:32 kernel: SELinux: policy capability network_peer_controls=1
Actually, this output details some content of the policy files, so the policy file may have an impact of when the mentioned properties are “0” and when “1”, but it does not impact if the kernel creates this output at all. You can see in your logs that the policy is logged as loaded after these entries 
I am indeed not 100% sure about that, but an educated guess would be that this was indeed introduced by a kernel, since SELinux and its agency are integrated into the kernel. So the kernel decides what SELinux makes and how it behaves (such as adding attributes/properties of the provided policy to the logs). But it must have been introduced with a kernel longer ago than the ones currently “in service”. I cannot find logs on my sys that do not yet contain it (you made me curious )
Interesting. I cannot verify that. My oldest logs are indeed of 6.8.11, as I introduced it already early in its testing phase, so all my logged boots are at least 6.8.11, or later. My guess would have been we had these log entries already much earlier.
Thanks for the clarification.
I only checked the entire journalctl record for policy capability network_peer_controls=1.
I never had any of these warnings - and I’ve been running the same kernel for a while now. I reinstalled everything cleanly, and got this barrage of messages suddenly. But before this I also had a bunch of crap, like “unknown” next to some devices when I ran lsusb, including a network interface, and now it says what it should say there. But it’s good to know this is normal behavior.
I have no doubt about that.
If I understand your points correctly, you have the output since you reinstalled. So I assume you maybe have a different kernel release since the reinstallation.
I can exclude in an case that these messages are a problem on themselves. They are intended. It would be just necessary to make a thorough investigation to find out which exact package actually introduced these messages, and given that they are intended, it is not worth the effort.
Another possibility, other than the kernel release, is that you maybe introduced a different build of the same kernel release when you reinstalled Fedora (or when the issue started to occur). Different builds sometimes have different patches (although this is usually limited to immediately necessary patches). E.g., if a kernel causes an issue in one or all Fedora releases, the affected builds might be replaced by builds that get patched with discussed upstream patches (so patches that are expected to be added to the next kernel anyway) in order to mitigate issues immediately (so that affected users don’t need to wait for the next kernel release).
So this would be another explanation, in case you had the same kernel release before and after the occurrence started. I guess the easiest way to find out if that might have been the case is to check your /boot/ dir: ls -la /boot/ | grep linuz. Then check the builds you have through the filenames (this should by default the last three kernel builds you have introduced, assuming that the issue was not introduced before these three):
e.g., “6.9.4-200” → 6.9.4 is the kernel, 200 the build. → 6.9.4-500 would be a different build and thus potentially cause a different behavior in some circumstances, even if it is generally the same kernel release. (However, I think it is unlikely that it was introduced through such a way)
Another explanation remains of course that the very package that introduced it was another one. It might be noted that the actual “kernel” and its agency is related to more than one package.
In any case, feel free to be curious, but don’t worry about that
These are not warnings, they are information messages, as are most messages reported by the kernel.
Run journalctl -k -p warning to see the warning and error messages.
1 Like
See this change request: https://github.com/SELinuxProject/selinux-kernel/issues/32
1 Like