From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.12) Gecko/20080208 Fedora/2.0.0.12-1.fc8 Firefox/2.0.0.12 Description of problem: Im' running selinux in permissive mode so it's not actually stopping access. I think this is being caused by my running fetchmail in daemon mode with the following lines in etc/fetchmailrc set syslog set logfile /var/log/mail/fetchmail.log Version-Release number of selected component (if applicable): selinux-policy-3.0.8-87.fc8 How reproducible: Always Steps to Reproduce: 1. set up fetchmail as described 2. wait for the selinux troubleshooter to report the problem 3. Actual Results: Expected Results: Additional info: Source Context: system_u:system_r:logwatch_t:s0Target Context: system_u:object_r:unlabeled_t:s0Target Objects: / [ filesystem ]Source: dfSource Path: /bin/dfPort: <Unknown>Host: florenceSource RPM Packages: coreutils-6.9-16.fc8Target RPM Packages: filesystem-2.4.11-1.fc8Policy RPM: selinux-policy-3.0.8-87.fc8Selinux Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing Mode: PermissivePlugin Name: catchallHost Name: florencePlatform: Linux florence 2.6.24.3-12.fc8 #1 SMP Tue Feb 26 14:58:29 EST 2008 i686 athlonAlert Count: 12First Seen: Tue 18 Mar 2008 09:26:38 GMTLast Seen: Sun 30 Mar 2008 07:39:27 BSTLocal ID: f930c649-148a-4428-894d-030722ca3482Line Numbers: Raw Audit Messages :host=florence type=AVC msg=audit(1206859167.798:32): avc: denied { getattr } for pid=3518 comm="df" name="/" dev=fusectl ino=1 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem host=florence type=SYSCALL msg=audit(1206859167.798:32): arch=40000003 syscall=268 success=yes exit=0 a0=96f5488 a1=54 a2=bfdc2ce4 a3=0 items=0 ppid=3517 pid=3518 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="df" exe="/bin/df" subj=system_u:system_r:logwatch_t:s0 key=(null)
This looks like you have a badly labeled file somewhere, probably in /var/log Try # restorecon -R -v /var This should fix the labeling and stop the AVC. Not sure how it got mislabeled, but for now I am reporting this as NOTABUG.
Thinking this was the issue I did a # touch /.autorelabel some days ago and have since rebooted. This should have done the same thing I think. This means that if the file was correctly labeled after the autorelable it has become unlabeled again since. I've done the restorecon suggested this morning and removed all messages from the selinux troubleshooter viewer. I will update the bug record after a couple of days.
Could you check if you have more then one policy in /etc/selinux/targeted/policy/ If you do, remove the policy with the lower number. I think there might be some tool problem where we are updating to a newer policy and then the older one is getting installed again, thus invalidating the file context.
I have checked - and there is only one file: policy.21 I have also just checked the selinux logs. It reports two problems on 1 April (this morning) so it looks as though the relabel gets undone at some point: at 06:53: SELinux is preventing fetchmail (fetchmail_t) "search" to ./log (var_log_t). then at 08:53: SELinux is preventing df (logwatch_t) "getattr" to / (unlabeled_t). The second being a repeat of the original problem, for which all the log details are in the original post of this report. The raw audit messages from the 06:53 incident are as follows: host=florence type=AVC msg=audit(1207029208.918:9): avc: denied { search } for pid=2246 comm="fetchmail" name="log" dev=sda1 ino=1653243 scontext=system_u:system_r:fetchmail_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir host=florence type=AVC msg=audit(1207029208.918:9): avc: denied { search } for pid=2246 comm="fetchmail" name="mail" dev=sda1 ino=1721128 scontext=system_u:system_r:fetchmail_t:s0 tcontext=system_u:object_r:sendmail_log_t:s0 tclass=dir host=florence type=AVC msg=audit(1207029208.918:9): avc: denied { append } for pid=2246 comm="fetchmail" name="fetchmail.log" dev=sda1 ino=1720901 scontext=system_u:system_r:fetchmail_t:s0 tcontext=system_u:object_r:sendmail_log_t:s0 tclass=file host=florence type=SYSCALL msg=audit(1207029208.918:9): arch=40000003 syscall=5 success=yes exit=3 a0=86a7af0 a1=441 a2=1b6 a3=0 items=0 ppid=1 pid=2246 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="fetchmail" exe="/usr/bin/fetchmail" subj=system_u:system_r:fetchmail_t:s0 key=(null)
Original bug report showed dev=fusectl. So this is an issue with SELinux and FUSE, not a mislabeled file. Do we have policy support for fusectl, whatever it is? The later denials seem to indicate that fetchmail.log is labeled sendmail_log_t. So either that is a labeling problem (is there a separate type for fetchmail.log?) and/or an allow rule problem (does fetchmail need to be allowed to search /var/log and to append to sendmail_log_t?). Easily fixed by a local policy module in the interim using /sbin/ausearch -m AVC | grep fetchmail | audit2allow -M myfetchmail followed by semodule -i myfetchmail.pp. Policy version mismatch is not indicated here, and is unlikely in Fedora 8 (as reported in the bug report) - that didn't happen until rawhide / Fedora 9.
Please update to the latest selinux-policy, which defines fusectl. A couple of the other avc's will also be removed. Not sure about the fetchmail.log labeling though.
You can allow this for now by executing # audit2allow -M mypol -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.0.8-98.fc8
Thanks for the last two postings. I've now done the following: # yum update selinux* This got me: selinux-policy.noarch 3.0.8-95.fc8 installed selinux-policy-devel.noarch 3.0.8-95.fc8 installed selinux-policy-targeted.noarch 3.0.8-95.fc8 installed On the basis that 3.0.8-98 hasn't made it to the servers yet I've issued the two commands in comment #7. Will report back in a couple of days.
OK - 10 days have passed and no reports in the SELinux troubleshooter so your recommendations above were helpful. Many thanks. Mike
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.