Summary: SELinux is preventing /usr/sbin/sendmail.sendmail "read" access on /var/log/messages. Detailed Description: [sendmail has a permissive type (system_mail_t). This access was not denied.] SELinux denied access requested by sendmail. It is not expected that this access is required by sendmail 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://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:system_mail_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_log_t:s0 Target Objects /var/log/messages [ file ] Source sendmail Source Path /usr/sbin/sendmail.sendmail Port <Unknown> Host (removed) Source RPM Packages sendmail-8.14.3-8.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-89.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.32.8-58.fc12.i686.PAE #1 SMP Wed Feb 17 19:00:46 UTC 2010 i686 i686 Alert Count 3 First Seen Mon 22 Feb 2010 03:29:23 AM EST Last Seen Mon 22 Feb 2010 03:29:23 AM EST Local ID 7035f300-ea2e-4ed6-8c44-c193b4f211c4 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1266827363.33:140440): avc: denied { read } for pid=10954 comm="sendmail" path="/var/log/messages" dev=dm-0 ino=286763 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file node=(removed) type=AVC msg=audit(1266827363.33:140440): avc: denied { read } for pid=10954 comm="sendmail" path="/var/log/secure" dev=dm-0 ino=284416 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file node=(removed) type=AVC msg=audit(1266827363.33:140440): avc: denied { read } for pid=10954 comm="sendmail" path="/var/log/maillog" dev=dm-0 ino=284417 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1266827363.33:140440): arch=40000003 syscall=11 success=yes exit=0 a0=98858b0 a1=9885938 a2=9884ec0 a3=9885938 items=0 ppid=10900 pid=10954 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=455 sgid=455 fsgid=455 tty=(none) ses=602 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null) Hash String generated from catchall,sendmail,system_mail_t,var_log_t,file,read audit2allow suggests: #============= system_mail_t ============== allow system_mail_t var_log_t:file read;
Are you mailing your log files?
(In reply to comment #1) > Are you mailing your log files? No. I am just riding the www sites.
Some tool that has all of you log files open is executing mail and leaking open file descriptors to it, I believe. Do you have some third party installed and running as initrc_t? ps -eZ | grep initrc_t
(In reply to comment #3) > Some tool that has all of you log files open is executing mail and leaking open > file descriptors to it, I believe. > > Do you have some third party installed and running as initrc_t? > > ps -eZ | grep initrc_t No. ps -eZ | grep initrc_t return nothing.
Well this happened a long time ago, So I would just delete the alert and reopen this bug if it happens again.
>Some tool that has all of you log files open is executing mail logwatch/epylog, as shipped with Fedoras, including v13.
lamelnyk Did you get this AVC? Does epylog mail all of the log files?
Miroslav can you add the following to logwatch.fc /var/lib/epylog(/.*)? gen_context(system_u:object_r:logwatch_cache_t,s0) /usr/sbin/epylog -- gen_context(system_u:object_r:logwatch_exec_t,s0) rpm
>Did you get this AVC I do. Last one was yesterday. Earlier I've tracked it to logwatch, but don't remember how. So, now I turn on the execve audit; next time we'll be sure.
>Does epylog mail all of the log files? Does not. Got it again, ausit says "epylog runs 'sh -c sendmail...', and that sendmail triggers 'avc denied'": 19:17:08.345:1354...syscall=execve...ppid=2678 pid=2680...comm=epylog exe=/usr/bin/python subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023... 19:17:09.479:1355...syscall=execve...ppid=2680...pid=2732...comm=sh exe=/bin/bash subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 19:17:09.482:1356...syscall=execve...ppid=2680 pid=2732...comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 19:17:09.482:1356: avc: denied { read } for pid=2732 comm=sendmail path=/var/log/maillog ...
This looks like epylog was not running with the correct context. Did you change the context on epylog to be logwatch_exec_t? chcon -t logwatch_exec_t /usr/sbin/epylog
Summary: SELinux is preventing /usr/sbin/sendmail.sendmail "read" access on /var/log/maillog. Detailed Description: [sendmail has a permissive type (system_mail_t). This access was not denied.] SELinux denied access requested by sendmail. It is not expected that this access is required by sendmail 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://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:system_mail_t:SystemLow- SystemHigh Target Context system_u:object_r:var_log_t:SystemLow Target Objects /var/log/maillog [ file ] Source sendmail Source Path /usr/sbin/sendmail.sendmail Port <Unknown> Host (removed) Source RPM Packages sendmail-8.14.4-4.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-23.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux localhost.localdomain 2.6.33.5-124.fc13.i686.PAE #1 SMP Fri Jun 11 09:42:24 UTC 2010 i686 i686 Alert Count 3 First Seen Wed 16 Jun 2010 08:30:58 AM EDT Last Seen Wed 16 Jun 2010 08:30:58 AM EDT Local ID 13e003dd-1923-4866-8a69-2cbefec2cde8 Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1276691458.631:28801): avc: denied { read } for pid=7329 comm="sendmail" path="/var/log/maillog" dev=sda7 ino=2662681 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file node=localhost.localdomain type=AVC msg=audit(1276691458.631:28801): avc: denied { read } for pid=7329 comm="sendmail" path="/var/log/messages" dev=sda7 ino=2662634 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file node=localhost.localdomain type=AVC msg=audit(1276691458.631:28801): avc: denied { read } for pid=7329 comm="sendmail" path="/var/log/secure" dev=sda7 ino=2662636 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file node=localhost.localdomain type=SYSCALL msg=audit(1276691458.631:28801): arch=40000003 syscall=11 success=yes exit=0 a0=9b2af68 a1=9b2aff0 a2=9b2a4b8 a3=9b2aff0 items=0 ppid=7189 pid=7329 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=483 sgid=483 fsgid=483 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null) I keep getting tons of these and also kernel crashes related to sendmail. I do not have time to search and destroy the bug at the moment, but will in the next few days.
>chcon -t logwatch_exec_t /usr/sbin/epylog $ ls -laZ /usr/sbin/epylog -rwxr-xr-x. root root system_u:object_r:logwatch_exec_t:s0 /usr/sbin/epylog Done it yesterday, however today's run is still got AVC: message
Sorry for the last message. It should be logwatch-triggered, as epylog just got "access to /var/run/epylog.pid denied"
Miroslav I think we need to add ype logwatch_var_run_t; files_pid_file(logwatch_var_run_t) allow logwatch_t logwatch_var_run_t:file manage_file_perms; files_pid_filetrans(logwatch_t, logwatch_var_run_t, file) /var/run/epylog\.pid gen_context(system_u:object_r:logwatch_var_run_t,s0)
Fixed in selinux-policy-3.7.19-31.fc13.
About the only thing I can add at this point is this: I generally get these when I make new login accounts, the first time or first several times I log in. After a while, they go away.
(In reply to comment #16) > Fixed in selinux-policy-3.7.19-31.fc13. Still going in selinux-policy-3.7.19-33.fc13 Fresh install incl Updates repo with logwatch Best fix? Summary: SELinux is preventing /usr/sbin/sendmail.sendmail "read" access on /var/log/messages. Additional Information: Source Context system_u:system_r:system_mail_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_log_t:s0 Target Objects /var/log/messages [ file ] Source sendmail Source Path /usr/sbin/sendmail.sendmail Port <Unknown> Host GW710X Source RPM Packages sendmail-8.14.4-4.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-33.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name GW710X Platform Linux GW710X 2.6.33.6-147.fc13.i686.PAE #1 SMP Tue Jul 6 22:24:44 UTC 2010 i686 i686
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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