Any SELinux Experts?

Latest response

The enterprise I work for is starting to push RedHat, in earnest, into the enterprise. Currently, the standard build we are deploying has SELinux enabled in targeted enforcement mode. Recently, a newly deployed RHEL system was requested to be added to our enterprise backup solution, NetBackup. Unfortunately, this system is encountering issues that "smell" like they might be SELinux-related.


Has anyone here ever tried to get SEL-enabled RHEL systems working as NetBackup clients? I've Googled around and perused a few NetBackup forums. Of the few posts I encounter about NBU in SEL-enabled environments, the universal number one suggestion seems to be "disable SEL" (seen this reply for other popular software people attempt to run on SEL-enable RHEL systems, too). This isn't exactly a "solution" that our enterprise's security folks are likely to want to allow. 


I know that I can run SELinux in permissive mode and then use the audit log processing tools to generate SEL policy modules. However, I'm not familiar enough with SEL to feel comfortable that such generated policy modules won't, essentially, neuter SEL (much like bad /etc/sudoers configurations can really render system security meaningless). Was hoping someone had solved this or similar problems or could tell me if I was being over-worried about the ramifications of generated policy modules.


I'm also working with the vendor to get their assistance. Unfortunately, initial indications seem to be that NetBackup under SEL just isn't that common a support request for them. The more I try to deploy commercial applications on our RHEL build, the more I notice that applications' SEL-support is an afterthought at best.


Any way, thanks in advance for any tips.


From what I can gather, it looks like the principal issue with running NetBackup with SELinux enabled is that the installer does not set the right contexts for shared libraries during the installation.

(This seems to be fairly common for non-Linux specific shrinkwrap software, and something we see fairly often in our environment.)

The way around this is to temporarily disable enforcement while performing the install, set the contexts appropriately, and then reenable enforcement.

My understanding, however, is that this is only required for the server deployment, and not for NetBackup clients.

BTW: if you are creating a client image (to be used for VM deployment), it should be relatively trivial to do this once. If not, you could generate your own RPM and take care of the SELinux work in the pre/post config.

Symantec's article here:
is inaccurate. Why bother setting the contexts at all if they are recommending disabling SELinux in its entirety?

This article seemed pretty helpful:

Warm regards,

I control the servers. Since vendor-support is, to put it mildly, "weak," we'll most likely go with simply disabling SEL on the master and media servers. It's easy enough to get security exceptions if you provide enough paperwork.


The immediate issue is client-related as the current NBU server architecture is Solaris-based (those will go away as we head down the NBU 7.x path). The SEL policies, in place, seem to prohibit the NBU processes from using network sockets. Haven't gotten past this, yet, to see where/how it effects access to files. Probably need to give the NBU service wide-open access to everything?


I haven't run through the exercise, yet, but... When you use audit2allow, does it generate ASCII-based policy definitions or just binary policy modules? Basically, if I end up using audit2allow, I want to have the ability to disect the resultant policies. There's enough good references out there that I might have a chance to assess impact of the generated policies.

As I would always say about SELinux, is it is all about labeling.  If you have a back up program that places files on disk, and does not maintain the extended attributes, this could cause SELinux problems.


I usually recomment people run restorecon on any directory that is restored from a backup


restorecon -R -v PATH


Should recursively put the default labels back on the system.


If you see a complaint about relocation of a library, this is probably caused by a badly built library.


SELinux Memory Protection Tests


Explains some of these checks.


Labeling a file with textrel_shlib_t tells SELinux to ignore the issue.


I'd forgotten the whole damned "extended attributes" part of the equation: thanks for the reminder. So long as the contents of /etc/selinux are restored (i.e., all of the policies and such that were active on the system before the restore), the `restorecon` should take care of putting everything back?

To setup the default labeling on the system.  So as long as that file exists and the kernel has the policy loaded restorecon can put the labels down. 


On a disabled SELinux you can still put labels down using the setfiles command.


setfiles  /etc/selinux/targeted/files/file_context /


For example will write extended attributes on a file system based on the file context files.