SCIENTIFIC-LINUX-USERS Archives

July 2007

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wayne Betts <[log in to unmask]>
Reply To:
Wayne Betts <[log in to unmask]>
Date:
Tue, 24 Jul 2007 19:46:16 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
Brett Viren wrote:
> Stephen John Smoogen <[log in to unmask]> writes:
>
>   
>> I end up tearing my hair out at times.. but its
>> usually figuring out why some software does something that no-one
>> would believe software would need to do.
>>     
>
> An ignorant question: can SELinux be configured to log any action that
> it blocks?  I would think this would make finding what software has
> gone beyond what expectations pretty obvious.
>
> -Brett.

Yes, by default on Redhat/SL selinux makes an audit entry in 
/var/log/messages when in either active or permissive mode for every 
blocked event (or every permitted event that would have been blocked but 
for being in permissive mode).

The two options that I'm aware of when selinux is getting in the way of 
something (assuming you don't want to disable it or put it in permissive 
mode) are
 
1. Change the security context of the file that is being blocked (verify 
it by inode number!).  Use the chcon command or in some cases restorecon 
(the -n option is your friend with restorecon to see what it would do).  
Change the context to whatever it says in the "scontext" field of the 
audit message. Oddly enough, I often get selinux denial messages when 
using the chcon command, even though the command succeeded.  (You can 
verify it worked with "ls -lZ" to see the selinux context of the file.)

2. Alter the local security policy to allow the attempted action.  To do 
this you can let the tools do some of the work:
2a.  Put the contents of the denial message (from /var/log/messages) 
into a separate file (/tmp/audit_denial for instance)
2b. Use audit2allow to parse the logged denial message and put the 
appropriate string into 
/etc/selinux/targeted/src/policy/domains/misc/local.te .
To do this the first time, I had to install the 
selinux-policy-targeted-sources RPM.
(for instance: 
 > cd /etc/selinux/targeted/src/policy
 > audit2allow -i /tmp/audit_denial -l domains/misc/local.te
 > make load
)

This is from memory, so I might have left something out.  But it took me 
several hours just to figure out these basics when I first started 
having selinux problems, so maybe even this will be enough to help 
someone else get started...

And to answer the original question of this thread...  I'm on the fence 
about the value of selinux.  Linux was already pretty darn "securable" 
-- selinux seems to add unintuitive complexity for all but the die hard 
admins that will likely cause much grief in exchange for few if any 
"saves", but over time the balance will shift in its favor as more 
people become comfortable with it.  If someone has an anecdote of how 
selinux saved the day at some point, please share it!

-Wayne Betts

ATOM RSS1 RSS2