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.
Craig
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;