Hi.
I'm trying to figure out where the SELinux policy modules shipped with the system live, and how they work. The modules listed by 'semodule -l' are the same as those available in /etc/selinux/targeted/modules/active/modules, but those are not part of any package, and are presumably added and removed to this location as they are added and removed to the kernel.
I later found these modules to live in /usr/share/selinux. If I create a policy module of my own, is this the place to put it to make sure that it is loaded when the system boots? Or do I also need to list it somewhere, such in a configuration file? The reason why I ask is because there are a few .pp files in this directory that are not visible in the list of loaded modules, and they are also not available in the /etc/selinux/.../modules directory above.
I today tried to figure out what these precompiled policy packages contain, but that isn't exactly obvious. I found .if files in /usr/share/selinux/devel/include/... that correspond to the .pp files in /usr/share/selinux, but nothing else. The .if files only contain definitions, but don't these need to be used somewhere, such as in .te files? And what about the .fc files that the policy generation tool in system-config-selinux creates? Are such files not needed?
Lots of questions, but the documentation on this subject isn't exactly stellar. :)
Regards Ingemar
On Mon, May 5, 2008 at 12:42 PM, Ingemar Nilsson init@kth.se wrote:
Lots of questions, but the documentation on this subject isn't exactly stellar. :)
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.
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
-
Ingemar Nilsson -
Jim Perrin