While the new modular policy stuff has been around for some time (and documented nicely from a pragmatic point of view by rising blog superstar, Dan Walsh), I’ve only recently had to delve into SELinux userland code again.
The modular policy stuff makes things much easier for admins and application developers, although as an SELinux developer who doesn’t spend a lot of time in the guts of userland, it’s been a nice new learning curve. With some help from Dan, I’m now able to easily do all of the things I used to do, and am seeing increasingly how much of a major advance the modular policy scheme is.
One thing in particular that I used to do, when adding new classes and perms, would be to rebuild the toolchain, then build a new policy, compile it to binary form, then use checkpolicy to verify some of its properties. With the monolithic scheme, you’d end up with a policy.conf file, the raw policy entries in text form, and compile it to a binary policy.20 (where 20 is the policy format version) file. This binary file could then just be written to /selinux/load to cause it to be loaded into the kernel.
With modular policy, the old-style monolithic policy.20 file is still regenerated during RPM installation, using the new modular base.pp file.
To do this manually and load the base policy (note: this kind of thing is for SELinux developers, not general users/admins or app devs), run:
# semodule -b /usr/share/selinux/targeted/base.pp
This will regenerate the monolithic equivalent:
You can also just create that file with the -n switch to semodule instead of -b.
Now, I can play with checkpolicy on this:
# checkpolicy -b -M /etc/selinux/targeted/policy/policy.20 checkpolicy: loading policy configuration from /etc/selinux/targeted/policy/policy.20 libsepol.policydb_index_others: security: 3 users, 7 roles, 1216 types, 146 bools libsepol.policydb_index_others: security: 1 sens, 256 cats libsepol.policydb_index_others: security: 57 classes, 40353 rules, 17050 cond rules checkpolicy: policy configuration loaded
This parses the binary monolithic policy and simply reports some statistics. I’m particularly interested in this case to make sure that two new security classes are present (one of which I’ve been working on), verifying that the toolchain from libselinux onwards is functioning correctly, and that the kernel won’t get upset when the policy is loaded and the new classes are referenced.
For more fun, add the -d switch to the above, and you’ll be dropped into an interactive policy debugger.
More on the new work soon…