SELinux policies and rpm distribution best practice

Latest response

Apologies in advance if this has been answered or there is an obvious reference I can use, but I have been digging through piles of SELinux documentation dating back (up to) several years and I am yet to find a Red Hat 'best practice' for packaging SELinux policy files for custom deployed applications via rpm.

The documentation I have found appears to be on one of two topics (but I can't find much else):

  1. SELinux introduction, -> explain how it works, why it isn't scary and why you shouldn't turn it off.
  2. How to write an SELinux policy -> run your app, run audit2allow, update policy, repeat

The document I am interested in (if it exists) is:

How to include a custom SELinux module in your rpm for your custom application, including:
- Where the module should be deployed (directory structure), in which format and how the SELinux system should be notified of its addition (rpm post scripts?)
- How file contexts for files should be defined / deployed (ie. in a file defining file contexts, calling semanage?)
- How other resources should be defined
- What clean up tasks should be carried out when removing the rpm to ensure unnecessary defined types/policies don't 'hang around' on the system

I think an example rpm that does the above 'the Red Hat way' would be a great start if anyone can suggest an example package to reference. I would also be interested in any rpm 'boiler plate' code specifically related to SELinux that people can provide (ie. installation/cleanup scripts for pre/post).

Also interested to know where the SELinux training course went (RH429/EX429/RHCSS) and will it be returning? Is there any chance of the lab material from this course being opened up for wider consumption if the course has been cancelled for good?

Thanks!

PS
Log in to join the conversation

Responses

james.radtke@siriusxm.com's picture Guru 6863 points
21 August 2014 12:30 PM

Great questions. Some of which I had not considered (I guess I hope my environment does not require custom policies ;-)

Thomas Cameron always does a great job presenting topics and SElinux is no exception. It is likely not the depth you are looking for, but I'll leave this here for others:
http://people.redhat.com/tcameron/Summit2014/cameron_w_340_selinux_for_mere_mortals/cameron_w_340_selinux_for_mere_mortals.pdf

One item I was pondering after reading your questions was the contexts:
/etc/selinux/targeted/contexts/files/
I wonder if that directory structure is essentially static and any custom policy/context that you create is stored elsewhere (similar to the approach where /etc/security/limits.d/* files are applied after /etc/security/limits.conf)

I hope you get some momentum on this discussion.

PS Guru 6494 points
21 August 2014 11:44 PM

Thanks for the link James, it's actually a slide deck I hadn't seen but I think it essentially covers the topics 1. and 2. above but in a more comprehensive way than I have found before (nice real world example).

This unfortunately still follows the attitude of "I am doing thing 'X' on my system.. and SELinux is stopping 'X' from working correctly, how do I configure SELinux to allow the access for 'X' on this system?"

Squirrelmail is a good example in this slide deck, but I feel it stops at the same place most other tutorials do, at the policy creation with audit2allow.

It would be great to have a follow up talk/document along the lines of "now I have a Squirrelmail policy module working, this is how I build an rpm to distribute it to my other systems".

I appreciate your response. I find it difficult to get people discussing SELinux and rpm packaging separately, let alone adding the two together!

Siem Korteweg's picture Guru 1450 points
22 August 2014 6:45 AM

This works for me (http://sourceforge.net/projects/sysconfcollect/):

The context of the web content is set and activated in the postinstall:

/usr/sbin/semanage fcontext --add --type httpd_sys_content_t "${SCC_WWW}(/.*)?"
/sbin/restorecon -R ${SCC_WWW}

The context is removed from the system in the preremove:

echo "fcontext -d ${SCC_WWW}(/.*)?" |
/usr/sbin/semanage -i - 2>/dev/null

PS Guru 6494 points
22 August 2014 7:29 AM

After some more searching I found the following resource on the FedoraProject page which is a draft of SELinux packaging guidelines. Unfortunately it was last updated in Mid 2012

http://fedoraproject.org/wiki/PackagingDrafts/SELinux#File_contexts

This essentially uses semanage and semodule to manipulate the system configuration in pre/post (similar/the same as what Siem has posted above).

It would be nice if there was some form of selinux.d file (my thoughts, and as James has suggested too) so the rpm can validate the status of the file it has deployed, among other benefits, then a triggered re-read could occur on this directory in rpm post (similar to ldconfig)

R. Hinton's picture Guru 6827 points
22 August 2014 2:25 PM

PixelDrift,

Just one immediate note from me; Make sure any atypical selinux contexts you care about are cited/added into /etc/selinux/targeted/contexts/files/file_contexts .

If you are using MLS SELinux (and not targeted as the path above shows) then the location for 'file_contexts" I believe is different. We have some unique MLS SELinux systems and a unique path leading to our own file_contexts" file which differs from the above and I believe from a typical MLS SELinux system.

The importance of that: if for some reason you must relabel your file system, (this is important), if your atypical (and important) file contexts -are- -not- -in- -that- -file- then when you relabel, those files will receive a different file context and could have ... "Negative Consequences" (Understatement™).

If someone has to go into the rescue mode and reset a password, bingo, your SELinux system will suffer a full relabeling. I know of one procedure around this but I do not publish this 'at all|publically'.

I'll check some resources I have regarding documentation... just wanted to share the above for any atypical files etc that you have a custom label.

PS Guru 6494 points
25 August 2014 12:49 AM

The changes definitely need to be able to survive a restorecon/relabel and the multiple policies add another dimension to the issue (I will continue using targeted in my examples.. but I appreciate the MLS complexity too!).

My concern with the method that is suggested currently (using semanage to add to file_contexts) is that the changes should also be able to survive and RPM package update of the selinux-policy-targeted package which owns the file_contexts file.

My understanding is, that if they are new directories, the fcontext information is placed in file_contexts.local so this may not be such an issue.. but is '.local' really the right place for RPM specific configuration?

The requirements I see are:
1. Installation and file contexts are set by the RPM install
2. Configuration of file contexts can survive a restorecon / relabel
3. File context settings generated/configured by RPM can be validated
4. File contexts and other configuration is removed cleanly on removal of RPM

No.3 is the big gap that currently exists for me, because if you are adding the file contexts using semanage, how do you verify that it hasn't changed? or the configuration hasn't been removed?

If the RPM can install into a 'file_contexts.d/' directory, no 3. is solved because the RPM can validate the status/content of the file. I can't see an elegant way of validating the package/rules if they are configured using semanage.

R. Hinton's picture Guru 6827 points
25 August 2014 5:48 PM

Good points Pixeldrift,

In the case I mentioned though, I was speaking about atypical files that for whatever reason are not in the file_contexts file (or other such file), yet are needed. This occurred in our case with a system we inherited. The previous owners or those who delivered the software had an apparent oversight. In that case, the file was not properly relabeled when we had to relabel the file system, and caused issues for a process. We fixed the issue by adding it after discovering this to the proper file_contexts file to avert this from occurring again.

I will check my notes later this week (busy with some things right now) on your bits above.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.