[lug] Understanding SElinux "semodule" and "audit2allow"

[stimits at comcast.net]

My previous posts on the fedora 19 messing with fedora 16 has one update:
Use of the adviced "touch /.autorelabel" and running with "enforcing=0" allowed me to finally reboot with selinux on (but not enforcing) and to update the filesystem. And to login! :P Logins are highly underrated. So apparently there is a relabel risk for any linux filesystem which is mounted either during an install or possibly during a policy rpm update...I do not know at which point it actually relabelled the old fedora partitions. Once relabel finished under enforcing=0, I was able to boot normally.

Now I have a new question about notes on the selinux notifications...I believe it is setroubleshootd that has the popup tool to notify of alerts to selinux. One of the options is to create a local rule when selinux is interfering with something which is considered normal and valid. The recipe is like this:
  grep "something audited" /var/log/audit/audit.log | audit2allow -M mypol
  semodule -i mypol.pp

The result is creation of mypol.tt (human readable) and mypol.pp (binary), followed by some form of update which modifies the /etc/selinux/ subdirectory area. Since mypol.pp is the non-human-readable file going into /etc/selinux/, it's hard to tell how it differs from the prior version. Because of some alerts reappearing after running several of the above mypol recipes, I'm thinking that this does not insert into and thus update /etc/selnux/, perhaps it replaces the old mypol with a new mypol (thus losing prior rules). Does the mypol file in the system get completely overwritten with only the single most recent command? Or does the mypol then contain the sum of the rules entered this way? Should there be an alternate file name instead of "mypol" each time a new rule is updated for local policy? Is there a tool which would allow me to find out what is in the mypol file of /etc/selinux/ or any specific binary policy file?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20131024/7c00355e/attachment.html>