SELinux - Best Context to Use
 

I'm currently going through several of our RHEL5 servers with SELinux in Permissive mode. Trying to remediate denial errors prior to setting it in Enforcing mode.

We have Commvault backups running on these servers and the agent is installed in /opt/simpana. The current SELinux context for the /opt/simpana directory is usr_t. This is causing us to get an AVC denial:

I would rather not create a policy to allow execmod for init_t processes on usr_t files, but I'm not sure what the best option would be. I'm assuming the /opt/simpana directory should have a different context...but what context would be best? Would it be best to set it with an init_t context? Or maybe one of the sysctl_... contexts?

Any ideas?

Shouldn't that be 'chcon -t textrel_shlib_t' as per http://www.akkadia.org/drepper/selinux-mem.html ?

unSpawn,

I guess that's the question...is that the appropriate context for the Commvault backup agent files? I'm not sure what the textrel_shlib_t context is for. I've tried looking it up, but I don't really see any information about what that label "means." I've just seen several hits on using the 'chon' command to set a file's context to that.

Ultimately, I think my issue here is that there doesn't seem to be an obvious way to identify how to remediate issues like this. If I use audit2allow, it would just have me allow init_t processes to have execmod access to usr_t file types. That doesn't seem, to me, like the best solution.

I can try setting it to textrel_shlib_t...just not sure if that's the most appropriate context and I'm not sure what else that would allow 'ifind' access to do.

As you might be able to tell, I'm still quite new to SELinux, so I'm still trying to get the hang of it.

Thanks for the reply!!

I think I may have found a good "lead" for this.

I ran 'semanage fcontext -l | grep opt' which gave me a list of all the file contexts used in the /opt directory. There were a few entries, mostly having to do with various library files and such. It seemed to indicate that library files under /opt were generally using lib_t or shlib_t and bin_t.

One example in the fcontext list showed an entry:

/opt/(.*/)?lib/.+\.so regular file system_u:object_r:shlib_t:s0

Since my AVC denial was for a .so lib file, I figured I'd just add a new entry for /opt/simpana/.+\.so to use shlib_t and then run restorecon -rv /opt/simpana.

Although, for some reason, after the restorecon, rather than changing the above specified file (/opt/simpana/Base/libSnooper.so) to shlib_t, it actually changed it to just lib_t. Not sure why the first time through it changed it to usr_t and then after the rule I put in above it changed to lib_t instead of shlib_t.

Hopefully, it works, but I'm a little concerned that it didn't have the expected result.

After working with Red Hat support on this, it appears that the items that are being flagged for ifconfig are set in RHEL6 SELinux policy to 'donotaudit.' I can only assume that since they are not auditing them, it is nothing I need to worry about. Since I'm on RHEL5, I don't have those same policies.

So, my solution is to assume that this behavior is normal and I can create a custom policy to not audit or even to allow these events.

Awesome. Thanks for posting your solution.

dcarrington, I have a RHEL 6 host with SELinux in enforcing mode, and CommVault v9. For some time, the audit log has been clean, but after a recent update of the CommVault software a few weeks ago, there are errors like:

It seems CommVault is somehow inducing ifconfig access on a simpana log file. The log file in question has a context of "system_u:object_r:var_log_t:s0", while all the other log files in that same directory have contexts like "unconfined_u:object_r:var_log_t:s0". These AVC denials haven't prevented CommVault from capturing valid backups, but I'd like to avoid this kind of noise in the logs (the denials happen 150-200 times per day). I'm just not sure how best to achieve that. I could try to change the log file's context to unconfined, but someone must've made it confined for a reason.

You mentioned ifconfig -- how was it involved in your situation?

Eric,

I was having a couple issues with AVC denials involving ifconfig. I think I may have combined the two in my last entry. But, if you're seeing a bunch of AVC denials with ifconfig attempting to read some of the simpana logs and are not seeing any problems being caused by that, you could always set up a custom policy for 'dontaudit' those actions.

That way you can effectively clean up your audit logs without cluttering them up with denial messages that don't really affect your operations.

Let me know if that works for you!