Security team at my company decided that they want us to start running SELinux as an extra level of security on our Linux servers. They don’t care how we implement it, just that it’s set to enforcing. To implement this change we figure it would be easiest to run audit2allow on all systems to build the rules and then just hit each server one at a time after verifying everything is working correctly. After using audit2allow on a few systems I’m noticing some strange behavior that I wanted to post about. I can’t figure out if this is by design or if I’m using it wrong.

1. I tried to kick off a virus scan after installing SELinux and it was blocked. After I ran 'audit2allow -a -M allowlist' then re-ran the virus scanner it had a second deny. I then re-run audit2allow 'audit2allow -a -M allowlist' which I figured would see the additional deny (all denies) in the logs and then over-ride the allowlist module with all the rules. When I re-ran the virus scan it was denied again and then after checking audit2allow it seemed to show that it needed the first rule again. After re-running this a few times to confirm I gave up and instead ran 'audit2allow -a -M allowlist_1', ran virus scanner again followed by 'audit2allow -a -M allowlist_2'. I'm not sure why it wouldn't see all denies and add them all to one module.

2. Is there a way to compile a list of rules using audit2allow and then just copy that module to different servers to install? Sort of like a golden list… If so I'm trying to decide between combining every allow rule from all RHEL7 servers or making a few groups since some of our servers are similar. So far since we have a core set of software on all servers (syslog, antivirus, rhsm, etc) I’m seeing all the same denies so it seems silly not to just certify that this one list is OK to install globally / on our main template.


Thanks!

You have overwritten your previous "allowlist" module with a new one. Because the names of the modules were the same.

To get a broader view of the permissions a particular process needs, you should test the functionality in permissive mode or preferably with the process type declared permissive type (semanage permissive -a/-d mytype_t)

-- make sure to remove any permissive type declarations that you added while testing!:
1. to list existing permissive types: semanage permissive -l
2. to remove a permissive type (mytype_t): semanage permissive -d mytype_t

Example: To read a file successfully various permissions are required in particular order

1. needs to be able to get to the file (traverse parent directories)
2. needs to be able to get attributes of the file (test whether the file exists (test -f myfile )
3. open the file
4. read the file
5. maybe lock the file, use ioctls etc

If any of these steps are blocked then the process might not be able to proceed and it might stop trying
for example if step 2 is blocked by SELinux then the process might think the file does not exist and act accordingly)

So to get the fuller picture you have to make sure that when in a testing phase the process is allowed to do what it wants, but SELinux would log what it would normally would have blocked in enforcing mode

audit2allow with the -r option can be used to tell audit2allow to print out the rules translated from the SELinux events and their requiements.

This output can then be pasted into a new file with a .te suffix

You should manually add a module declaration on top of the file.

echo "module mymodule 1.0.0;" > mymodule.te
ausearch -m avc,user_avc -ts recent | audit2allow -r >> mymodule.te

then you can manually build and install the mymodule.te source policy module (after reviewing the contents of mymodule.te):

checkmodule -M -m mymodule.te -o mymodule.mod
semodule_package -o mymodule.pp -m mymodule.mod
semodule -i mymodule.pp
semodule -l | grep mymodule

Remember that modules with the same module name that are installed using the same priority will be overwritten! and that if theyre not installed with the same priority, that the module on the highest priority takes precedence.
.
although not strictly needed. it is good to keep a copy of the source policy file (mymodule.te) for reference and for your co-workers so that they can see what is in there) . Can also be handy if later on you want to append some new rules to the module.

alternatively you can use semodule to export the loaded version in a readable cil language:

semodule --cil -E mymodule && cat mymodule.cil

3 members found this post helpful.

I would copy policies.
Perhaps even keep then in a repo.

Also when you start moving files in an SElinux environment don't forget to set the right context in files.

1 members found this post helpful.