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.
