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; -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.