LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
LinkBack Search this Thread
Old 06-13-2012, 10:53 AM   #1
dcarrington
Member
 
Registered: Dec 2011
Distribution: RHEL, CentOS, Ubuntu
Posts: 49

Rep: Reputation: 2
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:

Quote:
type=AVC msg=audit(1339585215.690:614429): avc: denied { execmod } for pid=3528 comm="ifind" path="/opt/simpana/Base/libSnooper.so" dev=dm-0 ino=906412 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
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?
 
Old 06-13-2012, 11:09 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601
Shouldn't that be 'chcon -t textrel_shlib_t' as per http://www.akkadia.org/drepper/selinux-mem.html ?
 
Old 06-13-2012, 11:44 AM   #3
dcarrington
Member
 
Registered: Dec 2011
Distribution: RHEL, CentOS, Ubuntu
Posts: 49

Original Poster
Rep: Reputation: 2
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!!
 
Old 06-13-2012, 12:15 PM   #4
dcarrington
Member
 
Registered: Dec 2011
Distribution: RHEL, CentOS, Ubuntu
Posts: 49

Original Poster
Rep: Reputation: 2
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.
 
Old 07-10-2012, 12:44 PM   #5
dcarrington
Member
 
Registered: Dec 2011
Distribution: RHEL, CentOS, Ubuntu
Posts: 49

Original Poster
Rep: Reputation: 2
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.
 
1 members found this post helpful.
Old 07-10-2012, 01:38 PM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601Reputation: 2601
Awesome. Thanks for posting your solution.
 
Old 07-11-2012, 01:17 PM   #7
ericrrath
LQ Newbie
 
Registered: Jul 2012
Posts: 1

Rep: Reputation: Disabled
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:

Quote:
type=AVC msg=audit(1342030297.080:291710): avc: denied { read } for pid=14061 comm="ifconfig" path="/var/log/simpana/Log_Files/cvfwd.log" dev=sda7 ino=10690565 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_ubject_r:var_log_t:s0 tclass=file
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?
 
Old 07-11-2012, 04:25 PM   #8
dcarrington
Member
 
Registered: Dec 2011
Distribution: RHEL, CentOS, Ubuntu
Posts: 49

Original Poster
Rep: Reputation: 2
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!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] SElinux context for FTP smilemukul Linux - Newbie 3 09-23-2010 05:35 PM
SElinux context problem Bit-Devil Linux - Security 0 12-04-2009 06:58 PM
SELinux: How can I clear the context when I copy a file? walkinmud Linux - Enterprise 3 08-09-2005 11:23 PM
SELinux: How can I clear the context when I copy a file? walkinmud Linux - Security 1 08-09-2005 12:37 AM
invalid context in SELinux lothario Linux - Security 1 06-17-2005 04:03 PM


All times are GMT -5. The time now is 04:50 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration