Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
There is less than 24 hours left to vote in the 2015 LinuxQuestions.org Members Choice Awards. Click here to go to the polls. Vote now and make sure your voice is heard!
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
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.
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.
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.
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_ubject_r:var_log_t:s0", while all the other log files in that same directory have contexts like "unconfined_ubject_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?
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.