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.
Regards,
Jim
--
*** e-mail is not a secure channel ***
mailto:byrnejb.<token>@harte-lyne.ca
James B. Byrne Harte & Lyne Limited
vox: +1 905 561 1241 9 Brockley Drive
fax: +1 905 561 0757 Hamilton, Ontario
<token> = hal Canada L8E 3C3