In the last few days I've upgraded a couple test systems to RHEL 7.3, and with that came a new version of policycoreutils (named 2.5-9.el7, up from 2.2.5-20). I found where some time ago the 'semodule' command was modified to remove the version information from the output, which has an unintended side effect of breaking my puppet modules that maintain local selinux modules and verify the version running is equal to the one in the manifest. The comment in the checkin (e599a4) states that CIL does not have a concept of versions, so it's being removed.
My question is, what is a good way to determine that the module that is installed and running matches the one in a specific .te file? I could of course tell puppet to trigger a rebuild of the .pp file if the .te has been modified, but it seems without rebuilding and/or reinstalling every puppet run there's no good way to verify that the version in memory is the one I've intended.
----- Original Message -----
From: "Steve Huston" huston@astro.princeton.edu To: selinux@lists.fedoraproject.org Sent: Thursday, November 17, 2016 1:41:51 PM Subject: Policy module versioning
In the last few days I've upgraded a couple test systems to RHEL 7.3, and with that came a new version of policycoreutils (named 2.5-9.el7, up from 2.2.5-20). I found where some time ago the 'semodule' command was modified to remove the version information from the output, which has an unintended side effect of breaking my puppet modules that maintain local selinux modules and verify the version running is equal to the one in the manifest. The comment in the checkin (e599a4) states that CIL does not have a concept of versions, so it's being removed.
My question is, what is a good way to determine that the module that is installed and running matches the one in a specific .te file? I could of course tell puppet to trigger a rebuild of the .pp file if the .te has been modified, but it seems without rebuilding and/or reinstalling every puppet run there's no good way to verify that the version in memory is the one I've intended.
This would depend on the priority of the module
semodule -lfull
More info available here: http://blog-bachradsusi.rhcloud.com/2015/06/05/selinux-modules-priority/
-- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
On 11/17/2016 01:41 PM, Steve Huston wrote:
In the last few days I've upgraded a couple test systems to RHEL 7.3, and with that came a new version of policycoreutils (named 2.5-9.el7, up from 2.2.5-20). I found where some time ago the 'semodule' command was modified to remove the version information from the output, which has an unintended side effect of breaking my puppet modules that maintain local selinux modules and verify the version running is equal to the one in the manifest. The comment in the checkin (e599a4) states that CIL does not have a concept of versions, so it's being removed.
My question is, what is a good way to determine that the module that is installed and running matches the one in a specific .te file? I could of course tell puppet to trigger a rebuild of the .pp file if the .te has been modified, but it seems without rebuilding and/or reinstalling every puppet run there's no good way to verify that the version in memory is the one I've intended.
One way is to install new versions of the module with different and higher priorities. The highest priority module with a given name will be loaded.
To install with a priority use -X, so "semodule -X 401 -i my_module.pp" will install my_module with priority 401. If you later change the module, you can install it at a higher priority (like 402). The command "semodule -lfull" will list all of the modules with their priority being given first, so the module above will appear as "400 my_module pp". You can then check if the priority is the same as your latest version. You can remove the old module at the lower priority with "semodule -X 400 -r my_module" (after the module at priority 401 is install.)
Another way would be to calculate the sha1sum of the compressed pp or cil file in the policy store and compare it to a known value. So something like "sha1sum /var/lib/selinux/targeted/active/modules/400/my_module/hll" will give you the sha1sum of the compressed pp file (policy package is a high level language from CIL's point of view).
I hope this helps.
On 11/17/2016 07:41 PM, Steve Huston wrote:
In the last few days I've upgraded a couple test systems to RHEL 7.3, and with that came a new version of policycoreutils (named 2.5-9.el7, up from 2.2.5-20). I found where some time ago the 'semodule' command was modified to remove the version information from the output, which has an unintended side effect of breaking my puppet modules that maintain local selinux modules and verify the version running is equal to the one in the manifest. The comment in the checkin (e599a4) states that CIL does not have a concept of versions, so it's being removed.
While CIL doesn't have versions, majority of modules are still installed from .pp and the original .pp files is stored in SELinux module store so it's possible to show versions for these modules. There's planned update to revert the behavior of 'semodule -l' to show versions or '(null)' in case of CIL module, see https://bugzilla.redhat.com/show_bug.cgi?id=1392573
My question is, what is a good way to determine that the module that is installed and running matches the one in a specific .te file? I could of course tell puppet to trigger a rebuild of the .pp file if the .te has been modified, but it seems without rebuilding and/or reinstalling every puppet run there's no good way to verify that the version in memory is the one I've intended.
I wrote a simple how to compare SELinux modules, see https://plautrba.fedorapeople.org/blok/How-to-compare-two-SELinux-modules.ht...
It needs to extract a module from the store first, but it's basically the same concept as using directly <store-root>/targeted/active/modules/400/my_module/hll file.
Note that in RHEL-7.3, store-root is set to /etc/selinux
Petr
selinux@lists.fedoraproject.org
-
James Carter -
Petr Lautrbach -
Simon Sekidde -
Steve Huston