Jim Perrin wrote:
With CentOS 5, you don't really need the selinux module source anymore. It's usually enough to clear the logs and in permissive mode, run the offending application. Then 'grep yourapp /var/log/audit/audit.log | audit2allow -M localmodname'. Check the module for sanity and make sure it's not allowing god-knows-what, then semodule -i localmodname. It'll be there on reboot from now on. no need (although it's a good idea) to keep the module file hanging around.
I know that you can generate policy modules from audit logs with audit2allow, but I'd like to know how it all works. This is for a variety of reasons:
* Is the denial because of a bug in the policy with the default configuration, or because I made some configuration change that requires additional permissions? In the first case, a bug report would probably be appropriate. * Maybe the error actually occurs because of some mislabeled file? Correcting a label is surely better than adding some unnecessary permission. * I might want to develop policy modules for our own software, using new file contexts and new types. In this case, simply adding avc rules with audit2allow would be inappropriate, since the system does not know about my planned policy module. * I'd like to use the source for existing policy modules as inspiration for my own work.
In addition, the policy generation tool (accessed through system-config-selinux) asks a few questions and then produces a .te, a .fc, a .if and (IIRC) a .pp file for my custom software. I know that the .te file is compiled into the .pp file, but what about e.g. the .fc file? Is it stored somewhere where restorecon will look for it, or is it simply used for the initial relabeling? Can I put it somewhere, like a /etc/selinux/.../file_contexts.d/ directory (no, it doesn't exist), or do I have to add the corresponding rules to the monolithic /etc/selinux/.../file_contexts file?
Regards Ingemar