Summary: SELinux is preventing /bin/mktemp "write" access on /.esmtp_queue. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by mktemp. It is not expected that this access is required by mktemp and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:logwatch_t:s0-s0:c0.c1023 Target Context system_u:object_r:default_t:s0 Target Objects /.esmtp_queue [ dir ] Source mktemp Source Path /bin/mktemp Port <Unknown> Host (removed) Source RPM Packages coreutils-7.6-7.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-49.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31.6-145.fc12.i686 #1 SMP Sat Nov 21 16:28:23 EST 2009 i686 i686 Alert Count 9 First Seen Thu 03 Dec 2009 03:13:04 AM PST Last Seen Sat 05 Dec 2009 03:44:05 AM PST Local ID 91d15040-a408-4e36-bd25-2ec5977db392 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1260013445.624:55): avc: denied { write } for pid=3854 comm="mktemp" name=".esmtp_queue" dev=sda7 ino=213330 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir node=(removed) type=AVC msg=audit(1260013445.624:55): avc: denied { add_name } for pid=3854 comm="mktemp" name="683ce2sV" scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir node=(removed) type=AVC msg=audit(1260013445.624:55): avc: denied { create } for pid=3854 comm="mktemp" name="683ce2sV" scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1260013445.624:55): arch=40000003 syscall=39 success=yes exit=0 a0=8e87058 a1=1c0 a2=8050864 a3=8 items=0 ppid=3846 pid=3854 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=7 comm="mktemp" exe="/bin/mktemp" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-49.fc12,catchall,mktemp,logwatch_t,default_t,dir,write audit2allow suggests: #============= logwatch_t ============== allow logwatch_t default_t:dir { write create add_name };
WHat is /.esmtp_queue? The problem is it is not labeled correctly. Is this usually stored some place else. 0# sesearch -A -s logwatch_t -c dir -p add_name Found 4 semantic av rules: allow logwatch_t tmp_t : dir { ioctl read write getattr lock add_name remove_name search open } ; allow logwatch_t logwatch_cache_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ; allow logwatch_t logwatch_tmp_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ; allow logwatch_t var_lock_t : dir { ioctl read write getattr lock add_name remove_name search open } ; tmp_t, logwarch_cache_t, logwatch_tmp_t and var_lock_t are the labels that logwatch_t can create files in.
This is from a default yum install of esmtp and esmtp-local-delivery (now ver. 1.0-6.fc12) Install was done in F11, now upgraded. The only custom config is /etc/esmtprc which has one line to make root mail deliver to user "kostya": mda "procmail -d kostya" It might be a bug in esmtp, I don't have a clue. /.esmtp_queue is a directory, currently empty.
esmtp should not be writing files/directories in /
*** Bug 545954 has been marked as a duplicate of this bug. ***
This bug has been triaged Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
FYI: I'm getting this alert in setroubleshoot every night. If it goes on for much longer, I'll just remove selinux altogether and stop reporting bugs.
Why not just add an allow rule then. # grep esmtp /var/log/audit/audit.log | audit2allow -M brokenesmtp # semodule -i brokensmtp.pp
Should say # grep logwatch /var/log/audit/audit.log | audit2allow -M brokenesmtp # semodule -i brokenesmtp.pp
Looking into this a little further it looks like logwatch is trying to send mail using esmtp. When logwatch executes the script it does not have a $HOME set. ( I guess cron does not set this for system cron jobs?) esmtp-wrapper has this line. qdir="$HOME/.esmtp_queue" ... queue_mail() { # ($@) local ret=0 mkdir -p "$qdir" || { echo "unable to create queue dir $qdir" 2>&1 return 1 } ... Not sure if there is a great way to fix this. A better solution then using the audit2allow method above would be to add a context of logwatch_cache_t. # semanage fcontext -t -a logwatch_cache_t "/.esmtp_queue(/.*)?" # restorecon -R -v /.esmtp_queue Which would label this directory allowing logwatch to manage files/direcroties under it.
This comment was flagged as spam, view the edit history to see the original text if required.
Using F15 now, problem is still around. By the way, I've added HOME=/ in /etc/crontab -- that fixes the path to /root/.esmtp_queue -- but selinux still complains about it
Benny, did you try # semanage fcontext -t -a logwatch_cache_t "/.esmtp_queue(/.*)?" # restorecon -R -v /.esmtp_queue
(In reply to comment #11) > Using F15 now, problem is still around. > By the way, I've added HOME=/ in /etc/crontab -- that fixes the path to > /root/.esmtp_queue -- but selinux still complains about it Konstantin, try to execute chcon -t logwatch_cache_t /root/.esmtp_queue
Looks like that fixed the original issue. Here are the remaining alerts: SELinux is preventing /usr/bin/esmtp from read access on the file /root/.esmtp_queue/KuvHgQem/mail. SELinux is preventing /usr/bin/esmtp from getattr access on the file /root/.esmtp_queue/KuvHgQem/mail. SELinux is preventing /bin/bash from execute access on the file /bin/bash. SELinux is preventing /bin/bash from getattr access on the file /bin/bash.
Ok, I need to see raw AVC msgs.
Created attachment 523314 [details] detailed 4 AVC denials Here you are
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to Konstantin Svist from comment #11) > Using F15 now, problem is still around. > By the way, I've added HOME=/ in /etc/crontab -- that fixes the path to > /root/.esmtp_queue -- but selinux still complains about it I have similar problem. But it is NOT a problem of SELinux: esmtp must NOT create .esmtp_queue directory in root directory. It is a problem of cronie: it does not set HOME environment variable when running sendmail. I filed bug 1202562 against cronie.