Summary: SELinux is preventing /usr/bin/perl "dac_override" access . Detailed Description: SELinux denied access requested by spamassassin. It is not expected that this access is required by spamassassin 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. Setup Spamassassin as per http://docs.fedoraproject.org/deployment-guide/f12/en-US/html/s3-email-mda-spam.html But fully specified the mailbox path: # more /etc/mail/spamassassin/spamassassin-default.rc # send mail through spamassassin :0fw | /usr/bin/spamassassin :0Hw * ^X-Spam-Status: YES /var/spool/mail/spam 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:spamc_t:s0 Target Context system_u:system_r:spamc_t:s0 Target Objects None [ capability ] Source spamassassin Source Path /usr/bin/perl Port <Unknown> Host (removed) Source RPM Packages perl-5.10.0-87.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-108.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux shyster 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC 2010 x86_64 x86_64 Alert Count 24 First Seen Fri 16 Apr 2010 20:46:55 BST Last Seen Fri 16 Apr 2010 20:46:57 BST Local ID cbd73211-4379-4086-8e92-b3774ebec8be Line Numbers Raw Audit Messages node=shyster type=AVC msg=audit(1271447217.219:2776): avc: denied { dac_override } for pid=23771 comm="spamassassin" capability=1 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:system_r:spamc_t:s0 tclass=capability node=shyster type=AVC msg=audit(1271447217.219:2776): avc: denied { dac_read_search } for pid=23771 comm="spamassassin" capability=2 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:system_r:spamc_t:s0 tclass=capability node=shyster type=SYSCALL msg=audit(1271447217.219:2776): arch=c000003e syscall=4 success=no exit=-13 a0=22d6608 a1=1e6e130 a2=1e6e130 a3=20 items=0 ppid=23770 pid=23771 auid=4294967295 uid=0 gid=12 euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295 comm="spamassassin" exe="/usr/bin/perl" subj=system_u:system_r:spamc_t:s0 key=(null) Hash String generated from catchall,spamassassin,spamc_t,spamc_t,capability,dac_override audit2allow suggests: #============= spamc_t ============== allow spamc_t self:capability { dac_read_search dac_override };
Just to give a complete picture it also generates this one at the same time: Summary: SELinux is preventing /usr/bin/perl "read" access on /etc/shadow. Detailed Description: SELinux denied access requested by spamassassin. It is not expected that this access is required by spamassassin 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:spamc_t:s0 Target Context system_u:object_r:shadow_t:s0 Target Objects /etc/shadow [ file ] Source spamassassin Source Path /usr/bin/perl Port <Unknown> Host (removed) Source RPM Packages perl-5.10.0-87.fc12 Target RPM Packages setup-2.8.9-1.fc12 Policy RPM selinux-policy-3.6.32-108.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC 2010 x86_64 x86_64 Alert Count 2 First Seen Fri 16 Apr 2010 20:46:55 BST Last Seen Fri 16 Apr 2010 20:46:56 BST Local ID aca84fc1-f00a-479d-a02a-de8bc95a46ef Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1271447216.221:2770): avc: denied { read } for pid=23771 comm="spamassassin" name="shadow" dev=md0 ino=85389 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1271447216.221:2770): arch=c000003e syscall=2 success=no exit=-13 a0=7fa464fb6a7b a1=80000 a2=1b6 a3=0 items=0 ppid=23770 pid=23771 auid=4294967295 uid=0 gid=12 euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295 comm="spamassassin" exe="/usr/bin/perl" subj=system_u:system_r:spamc_t:s0 key=(null)
Why is spamassassin trying to read the /etc/shadow file? I have never seen it need this access before?
I was kind of hoping you'd know the answer to that straight off, as I couldn't figure it out. Can't say I've made any changes to it that would cause this. Don't know if the issue is cause by "spam" not being a user account on my system (even though I'm directing it to that mailbox). Saying that this is procmail doing that redirection, so I'd have thought shouldn't really cause an event from the spamassassin context? Maybe I need to strace it out.
Yes, this is definitely something we do not want to allow. It could be caused by spamassassin using the pam stack? Reassinging to spamassassin to see if the maintainers have any idea why spamassassin would be trying to read the /etc/shadow file?
How about the dac_override ?
What is the permissions on /etc/shadow? It is probably the same problem. If you turn on full auditing by executing # auditctl -w /etc/shadow -p w And generate the AVC again The AVC should include the path of the file that requires dac_override
Created attachment 407897 [details] audit.log Not sure what format you want this in, so I've added the raw audit.log fragment. Looks like spamassassin is looking for prefs in the destination mailbox's homedir. Even though I'm not running in daemon mode (e.g spamc/spamd) maybe there is a way to make the /usr/bin/spamassassin perl script not check user prefs when run from sendmail. Or maybe that's undesirable.
If this is expected behaviour then I think we need to add it. Does spamassassin seem to be working ok, even with these errors?
It does seem to be working ok.
This now seems to have gone insane on F13, May 29 17:11:12 shyster setroubleshoot: SELinux is preventing spamassassin from binding to port 19269. For complete SELinux messages. run sealert -l fc4be6a3-cb03-4dff-91d3-7797ee395759 May 29 17:11:30 shyster setroubleshoot: SELinux is preventing spamassassin from binding to port 24680. For complete SELinux messages. run sealert -l fc4be6a3-cb03-4dff-91d3-7797ee395759 May 29 17:11:39 shyster setroubleshoot: SELinux is preventing spamassassin from binding to port 24760. For complete SELinux messages. run sealert -l fc4be6a3-cb03-4dff-91d3-7797ee395759 May 29 17:11:43 shyster setroubleshoot: SELinux is preventing spamassassin from binding to port 24800. For complete SELinux messages. run sealert -l fc4be6a3-cb03-4dff-91d3-7797ee395759 The machine goes pretty busy I think largely with setroubleshooter trying to log loads of these. I think it is actually trying to log tons of port binds in quick succession. Presumably spamassassin is trying to find a port it can bind to, no idea why it should need to. type=SYSCALL msg=audit(1275150141.011:28577): arch=c000003e syscall=49 success=no exit=-13 a0=3 a1=133d7b0 a2=10 a3=14312a7 items=0 ppid=2826 pid=2827 auid=4294967295 uid=0 gid=12 euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295 comm="spamassassin" exe="/usr/bin/perl" subj=system_u:system_r:spamc_t:s0 key=(null) type=AVC msg=audit(1275150141.012:28578): avc: denied { name_bind } for pid=2827 comm="spamassassin" src=29684 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket It does eventually give up and deliver the email. For some peace and quiet I've switched to the daemon version spamd and INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc in procmailrc. I think I can say /etc/mail/spamassassin/spamassassin-default.rc with SELinux on F13 seems broken (even though this is in the docs).
If you turn on the spamassassin_can_network boolean this would be allowed. # setsebool -P spamassassin_can_network 1
That'll explain it. Is spamassassin_can_network new? Why does spamassassin need network access anyway?
Not sure, maybe contacts some server to check on new spam filters?
sa-update does, also, there are some tests that check dns blacklists and whitelists.
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
Still seems pretty chatty on audit.log in Fedora 14 from what I can see. Upped the version. I guess the fix could be to change the docs to say use only use the daemon version of spamassassin "spamd" if using SELinux? Just a thought.
Colin what avc's are you seeing currently?
Pretty much as before: type=AVC msg=audit(1288824919.375:172): avc: denied { dac_override } for pid=12032 comm="spamassassin" capability=1 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:system_r:spamc_t:s0 tclass=capability type=AVC msg=audit(1288824919.375:172): avc: denied { dac_read_search } for pid=12032 comm="spamassassin" capability=2 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:system_r:spamc_t:s0 tclass=capability type=SYSCALL msg=audit(1288824919.375:172): arch=c000003e syscall=2 success=no exit=-13 a0=430eb10 a1=241 a2=1b6 a3=7f96401b03e0 items=0 ppid=12031 pid=12032 auid=4294967295 uid=0 gid=12 euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295 comm="spamassassin" exe="/usr/bin/perl" subj=system_u:system_r:spamc_t:s0 key=(null) and type=AVC msg=audit(1288824917.937:159): avc: denied { read } for pid=12032 comm="spamassassin" name="shadow" dev=md0 ino=86335 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=SYSCALL msg=audit(1288824917.937:159): arch=c000003e syscall=2 success=no exit=-13 a0=7f963c8b250a a1=80000 a2=1b6 a3=0 items=0 ppid=12031 pid=12032 auid=4294967295 uid=0 gid=12 euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295 comm="spamassassin" exe="/usr/bin/perl" subj=system_u:system_r:spamc_t:s0 key=(null) Let me know if you want the sealert "cooked" versions of these.
I would get rid of these messages by executing # grep spamassassin /var/log/audit/audit.log | audit2allow -D -M myspam # semodule -i myspam.pp This will put dontaudit rules in place to quiet the log file. I think we should open a separate bug on spamassassin to say it should not be attempting to read /etc/shadow.
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