[CentOS] SELinux on CentOS4

Craig White craigwhite at azapple.com
Tue Nov 15 21:39:57 UTC 2005

On Tue, 2005-11-15 at 16:26 -0500, James B. Byrne wrote:
> I regret the delay in replying to this topic but I am a digest 
> subscriber so I only see list traffic once every 24 hours.
> When I moved from RHES3 to CentOS4 back in April/May of this year I 
> was bitten by the SELinux gnat as well, and the temptation to swat 
> a distracting irritation by killing it in its bed nearly proved 
> irresistible.  However, taking to heart the advice given to me here 
> and reading about SELinux on RedHat's web site I choose not to. 
> Rather I discovered how to get immediate fixes to the SELinux 
> permissions for specific programs applied to the host's local 
> policy while seeking confirmation here and elsewhere as to whether 
> the policy changes proposed by "audit2allow" made sense or should 
> be adjusted.
> The process of reconfiguring the local policy for SELinux is in 
> itself almost trivial, assuming that one has first installed the 
> applicable selinux-policy-targeted-sources rpm package.  One need 
> only first establish that the problem is in fact caused by SELinux 
> by grep'ing the system log file (/var/log/messages) for entries 
> containing "avc" relating to the application in question. 
> If this proves the case then first "cd 
> /etc/selinux/targeted/src/policy" and  then "make reload". Then run 
> the program that is having problems with SELinux, then run 
> audit2allow (#audit2allow -l -i /var/log/messages)and gather the 
> resulting policy recommendations into a text file. The -l flag 
> limits the report to those log entries made by SELinux since the 
> last policy reload. You can then:
> add them to your local policy file 
> (/etc/selinux/targeted/src/policy/domains/misc/local.te);
> cd into /etc/selinux/targeted/src/policy; 
> and make reload as root.  
> You may have to repeat this process several times to exhaust all of 
> the circumstances that a packages trespasses against SELinux.  You 
> will probably find it most convenient if you keep these changes 
> segregated by application in your local policy file.  I also have 
> found it useful to post them as a set on SELinux related mailing 
> lists (and even this list) for comments by people more 
> knowledgeable than I with the intent of narrowing the permissions 
> granted the application to the minimum set required.  Audit2allow 
> often recommends wider scope than actually needed.
> The result is that with a few minutes work virtually any 
> application can be enabled within SELinux without forgoing any of 
> the other benefits that SELinux provides.  Even if the application 
> is initially granted too great an access the resulting situation is 
> usually still preferable to turning SELinux off entirely.  One can 
> always return to the local policy file and tighten it up when one 
> obtains the necessary information as to where this is advisable.
thanks for articulating what my actual solution became. If I were
articulate, that's what I would have said. ;-)

audit2allow doesn't really have much info yet, no man page though
Stephen Smalley pointed me to a man page in cvs that was minimal.

The technical information is good but it seems to zip over my head and a
selinux for dummies thing would seem to be helpful but I did post up my
alterations to local.te for the 2 issues that I was dealing with and
yea, it fixed them.


for the record - once again (and it follows your logic of segregating
policy by applications)...

# cat /etc/selinux/targeted/src/policy/domains/local.te
## http to mysql
allow httpd_t initrc_t:unix_stream_socket connectto;

## dbus
allow unconfined_t initrc_t:dbus send_msg;

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the CentOS mailing list