Any SELinux Experts?
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.
Responses
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:
http://www.symantec.com/business/support/index?page=content&id=TECH58689
is inaccurate. Why bother setting the contexts at all if they are recommending disabling SELinux in its entirety?
This article seemed pretty helpful:
http://hwarf.com/2008/02/21/netbackup65-centos5/
Warm regards,
Phil
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.
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.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
