In-Reply-To: f4e013870805211022r36194b29gb74ca4421dc2ee77@mail.gmail.com

On: Wed, 21 May 2008 10:22:19 -0700, MHR mhullrich@gmail.com wrote:

...

On Wed, May 21, 2008 at 8:37 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:

This indeed turned out to be an SELinux policy problem which I have since resolved.

Whoa, whoa, whoa, nice shooting, Tex! (Ghostbusters)

Not so fast - please post the solution, too, for posterity (and those of us who don't use SELinux but might, someday, in the not too distant far future...).

Thanks.

mhr

Dealings with SELinux issues typically do not lend themselves to short answers. SELinux is like an onion, each each exception blocks access until resolved. Thus each policy change has to be made individually and then the process retested so that the next impediment evidences itself.

On CentOS-5 your friends are:

# grep avc /var/log/messages # grep <process> /var/log/audit/audit.log

and some of the more useful utilities are:

# audit2allow # audit2why # chcon # restorecon # sealert # semanage

When I suspect (and that is often the hardest part of the whole exercise, realizing that SELinux is the problem) that SELinux is involved in a problem I start by checking the system log file /var/log/messages with grep avc. If I see things like this:

# grep avc /var/log/messages

May 16 04:02:33 inet01 kernel: audit(1210924952.785:22973): avc: denied { read } for pid=22282 comm="prelink" name="setserial" dev=dm-0 ino=3309644 scontext=user_u:system_r:prelink_t:s0 tcontext=system_u:object_r:rsync_data_t:s0 tclass=file

Then I infer that I have a problem with either the SELinux file contexts or the system policy file. If the SELinux problem is announced at the desktop then you may also find it useful to check for this:

# grep setroubleshoot /var/log/messages

In which case you may see something like this:

Dec 17 14:13:24 inet01 setroubleshoot: SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d (etc_t). For complete SELinux messages. run sealert -l 15618e2e-044c-4c4c-b3fc-ec1eba554d02

In this case you can follow the suggestion given in the log message and run sealert:

# sealert -l 15618e2e-044c-4c4c-b3fc-ec1eba554d02 Summary SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d (etc_t).

Detailed Description SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d (etc_t). The SELinux type %TARGET_TYPE, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write ... yada-yada-yada... ... Allowing Access You can attempt to fix file context by executing restorecon -v virtual.d

The following command will allow this access: restorecon virtual.d

And then you can try that, although I have rarely had a problem with SELinux solved so simply:

# cd /path/to/virtual.d # restorecon virtual.d

Anyway, if that does not work, or one never received an setroubleshoot report to begin with, then I end up turning to audit2allow. I do something like this (where rsync is the process that I am having difficulty with, it could be httpd, vsftp or anything else):

# grep rsync /var/log/audit/audit.log | audit2allow

Which may yield a report something like this:

#============= prelink_t ============== allow prelink_t rsync_data_t:file read;

Now, if this does not look too alarming in terms of the access that rsync seems to be seeking (being able to read files to be transferred seems a logical enough expectation and the benefit/limitations of prelink seem to require access in this instance) then we can add this permission to our policy via a local module. You make one of these in this fashion:

# # grep rsync /var/log/audit/audit.log | audit2allow -M localrsyncmod

******************** IMPORTANT *********************** To make this policy package active, execute:

semodule -i localrsyncmod.pp #

Again, you simply follow the instructions given in the report.

# semodule -i localrsyncmod.pp

Now you do yet another test and check the log files. If the problem is fixed, then great, you are finished. Usually, however, SELinux issues continually reveal one permission problem after another, sometimes with different processes, until, at last, they have all been accommodated. Consequently you end up re-running your tests, checking the audit files, and modifying the local policy one item at a time.

Note that simply overriding what SELinux is prohibiting is not what I am advocating here. Sometimes the problem is that the software needs its file system access expectations trimmed back and that requires filing a bug report with the maintainers. However, in a production environment you normally just have to get things working and what I usually do is weigh what the program is requesting against what I want it to do for me. Often the problem is that the default policy is simply too restrictive. On rare occasions I do actually file a bug report but almost always override the local policy anyway just to get on with the job.

I hope this helps.