I have a procmail recipe which writes a copy of every mail I receive (just because I'm paranoid it doesn't mean they aren't out to get me!) to a backup area on my /dev/sda9 partition, mounted as /mnt/backup/ by fstab. (It is an ext3 partition).
Back in March 2008 when I was on F8 Stephen Smalley kindly helped me to prevent the hundreds of avcs by suggesting the following:
semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" restorecon -v -R /mnt/backup
This worked perfectly. It also held true throughout my time with F9. I have now upgraded to F11 (I skipped F10) and it still kind of works. I get an avc when logrotate tries to access these files.
The strange thing is this didn't happen under F8 or F9.
Is there an elegant solution to this problem or should I write a policy module?
This is what audit2allow proposes:
module rawmail 1.0;
require { type mail_spool_t; type logrotate_t; class file getattr; }
#============= logrotate_t ============== allow logrotate_t mail_spool_t:file getattr;
The full avc is below.
Many thanks for all your help....
Mark
Summary SELinux is preventing logrotate (logrotate_t) "getattr" mail_spool_t. Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]
SELinux denied access requested by logrotate. It is not expected that this access is required by logrotate 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 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional Information
Source Context: system_u:system_r:logrotate_t:s0-s0:c0.c1023 Target Context: system_u:object_r:mail_spool_t:s0 Target Objects: /mnt/backup/mail/rawmail [ file ] Source: logrotate Source Path: /usr/sbin/logrotate Port: <Unknown> Host: troodos.org.uk Source RPM Packages: logrotate-3.7.8-2.fc11 Target RPM Packages:
Policy RPM: selinux-policy-3.6.12-72.fc11 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: catchall Host Name: mydomain Platform: Linux mydomain 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686 i686 Alert Count: 3 First Seen: Thu Aug 13 03:45:40 2009 Last Seen: Sat Aug 15 03:26:41 2009 Local ID: 3a8c20b3-ff25-43ea-8214-bd926c28215b Line Numbers:
Raw Audit Messages :
node=mydomain type=AVC msg=audit(1250303201.472:2436): avc: denied { getattr } for pid=15100 comm="logrotate" path="/mnt/backup/mail/rawmail" dev=sda9 ino=2490369 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mail_spool_t:s0 tclass=file node=troodos.org.uk type=SYSCALL msg=audit(1250303201.472:2436): arch=40000003 syscall=196 success=yes exit=0 a0=8a7d598 a1=bfe1faa4 a2=77cff4 a3=1 items=0 ppid=15098 pid=15100 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=513 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
I have a procmail recipe which writes a copy of every mail I receive (just because I'm paranoid it doesn't mean they aren't out to get me!) to a backup area on my /dev/sda9 partition, mounted as /mnt/backup/ by fstab. (It is an ext3 partition).
Back in March 2008 when I was on F8 Stephen Smalley kindly helped me to prevent the hundreds of avcs by suggesting the following:
semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" restorecon -v -R /mnt/backup
This worked perfectly. It also held true throughout my time with F9. I have now upgraded to F11 (I skipped F10) and it still kind of works. I get an avc when logrotate tries to access these files.
The strange thing is this didn't happen under F8 or F9.
Is there an elegant solution to this problem or should I write a policy module?
This is what audit2allow proposes:
module rawmail 1.0;
require { type mail_spool_t; type logrotate_t; class file getattr; }
#============= logrotate_t ============== allow logrotate_t mail_spool_t:file getattr;
The full avc is below.
Many thanks for all your help....
Mark
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Thanks
Mark
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
I have a procmail recipe which writes a copy of every mail I receive (just because I'm paranoid it doesn't mean they aren't out to get me!) to a backup area on my /dev/sda9 partition, mounted as /mnt/backup/ by fstab. (It is an ext3 partition).
Back in March 2008 when I was on F8 Stephen Smalley kindly helped me to prevent the hundreds of avcs by suggesting the following:
semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" restorecon -v -R /mnt/backup
This worked perfectly. It also held true throughout my time with F9. I have now upgraded to F11 (I skipped F10) and it still kind of works. I get an avc when logrotate tries to access these files.
The strange thing is this didn't happen under F8 or F9.
Is there an elegant solution to this problem or should I write a policy module?
This is what audit2allow proposes:
module rawmail 1.0;
require { type mail_spool_t; type logrotate_t; class file getattr; }
#============= logrotate_t ============== allow logrotate_t mail_spool_t:file getattr;
The full avc is below.
Many thanks for all your help....
Mark
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
hth
Thanks
Mark
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
I have a procmail recipe which writes a copy of every mail I receive (just because I'm paranoid it doesn't mean they aren't out to get me!) to a backup area on my /dev/sda9 partition, mounted as /mnt/backup/ by fstab. (It is an ext3 partition).
Back in March 2008 when I was on F8 Stephen Smalley kindly helped me to prevent the hundreds of avcs by suggesting the following:
semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" restorecon -v -R /mnt/backup
This worked perfectly. It also held true throughout my time with F9. I have now upgraded to F11 (I skipped F10) and it still kind of works. I get an avc when logrotate tries to access these files.
The strange thing is this didn't happen under F8 or F9.
Is there an elegant solution to this problem or should I write a policy module?
This is what audit2allow proposes:
module rawmail 1.0;
require { type mail_spool_t; type logrotate_t; class file getattr; }
#============= logrotate_t ============== allow logrotate_t mail_spool_t:file getattr;
The full avc is below.
Many thanks for all your help....
Mark
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
Is this related? (apologies for line-wrap):
Aug 18 09:07:44 troodos dbus: avc: received setenforce notice (enforcing=0) Aug 18 09:07:44 troodos dbus: Can't send to audit system: USER_AVC avc: received setenforce notice (enforcing=0)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?)
I haven't tried semodule -DB yet, but your message caused me to look at /var/log/messages and this was the first thing I saw...
On Tue, Aug 18, 2009 at 10:42:40AM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
I have a procmail recipe which writes a copy of every mail I receive (just because I'm paranoid it doesn't mean they aren't out to get me!) to a backup area on my /dev/sda9 partition, mounted as /mnt/backup/ by fstab. (It is an ext3 partition).
Back in March 2008 when I was on F8 Stephen Smalley kindly helped me to prevent the hundreds of avcs by suggesting the following:
semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?" restorecon -v -R /mnt/backup
This worked perfectly. It also held true throughout my time with F9. I have now upgraded to F11 (I skipped F10) and it still kind of works. I get an avc when logrotate tries to access these files.
The strange thing is this didn't happen under F8 or F9.
Is there an elegant solution to this problem or should I write a policy module?
This is what audit2allow proposes:
module rawmail 1.0;
require { type mail_spool_t; type logrotate_t; class file getattr; }
#============= logrotate_t ============== allow logrotate_t mail_spool_t:file getattr;
The full avc is below.
Many thanks for all your help....
Mark
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
Is this related? (apologies for line-wrap):
No, not related. (it is a (known) bug in dbus though)
Aug 18 09:07:44 troodos dbus: avc: received setenforce notice (enforcing=0) Aug 18 09:07:44 troodos dbus: Can't send to audit system: USER_AVC avc: received setenforce notice (enforcing=0)#012: exe="?" (sauid=81, hostname=?, addr=?, terminal=?)
I haven't tried semodule -DB yet, but your message caused me to look at /var/log/messages and this was the first thing I saw...
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
[snip]
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
OK - since semodule -DB getting flooded with AVCs...
Here are some that are related to this problem...
cat /var/log/audit/audit.log | grep -i procmail .... type=AVC msg=audit(1250591203.244:43494): avc: denied { rlimitinh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { siginh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { noatsecure } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11 success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) type=AVC msg=audit(1250591203.418:43495): avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196 success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
This still with setenforce 0
Any ideas?
Thanks for your help!...
Mark
On Tue, Aug 18, 2009 at 11:39:07AM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
[snip]
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
OK - since semodule -DB getting flooded with AVCs...
Here are some that are related to this problem...
cat /var/log/audit/audit.log | grep -i procmail .... type=AVC msg=audit(1250591203.244:43494): avc: denied { rlimitinh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { siginh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { noatsecure } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11 success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) type=AVC msg=audit(1250591203.418:43495): avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196 success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
This still with setenforce 0
Any ideas?
Thanks for your help!...
Mark
The only AVC denial that is ( a little bit ) interesting is:
avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir
Pipe this into audit2why to see if it has any suggestions. Although i doubt it is related to your issue.
A quick way to rule out SELinux as the cause of your issue is to reproduce the issue in permissive mode.
If access is (still) denied when you try to reproduce it in permissive mode, than it is not an SELinux issue.
If it works in permissive mode, but not in enforcing mode, then it is a SELinux issue.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, 2009-08-18 at 12:46 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 11:39:07AM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
[snip]
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
OK - since semodule -DB getting flooded with AVCs...
Here are some that are related to this problem...
cat /var/log/audit/audit.log | grep -i procmail .... type=AVC msg=audit(1250591203.244:43494): avc: denied { rlimitinh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { siginh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { noatsecure } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11 success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) type=AVC msg=audit(1250591203.418:43495): avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196 success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
This still with setenforce 0
Any ideas?
Thanks for your help!...
Mark
The only AVC denial that is ( a little bit ) interesting is:
avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir
Pipe this into audit2why to see if it has any suggestions. Although i doubt it is related to your issue.
A quick way to rule out SELinux as the cause of your issue is to reproduce the issue in permissive mode.
If access is (still) denied when you try to reproduce it in permissive mode, than it is not an SELinux issue.
If it works in permissive mode, but not in enforcing mode, then it is a SELinux issue.
Well all that audit2why suggests for that avc is:
Was caused by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
On your other point, you will notice (further up in this mail) that this problem is only in Enforcing mode. Switching to Permissive does indeed stop the procmail errors.
Still watching the avcs.... I'll keep you posted..
Thanks
Mark
On Tue, Aug 18, 2009 at 12:23:25PM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 12:46 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 11:39:07AM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
[snip]
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
Also, I get these dovecot messages (although I haven't investigated fully if they are selinux related... **Unmatched Entries** dovecot: IMAP(wife): fchown() failed with file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted: 1 Time(s) dovecot: IMAP(son): fchown() failed with file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not permitted: 3 Time(s)
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
OK - since semodule -DB getting flooded with AVCs...
Here are some that are related to this problem...
cat /var/log/audit/audit.log | grep -i procmail .... type=AVC msg=audit(1250591203.244:43494): avc: denied { rlimitinh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { siginh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { noatsecure } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11 success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) type=AVC msg=audit(1250591203.418:43495): avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196 success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
This still with setenforce 0
Any ideas?
Thanks for your help!...
Mark
The only AVC denial that is ( a little bit ) interesting is:
avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir
Pipe this into audit2why to see if it has any suggestions. Although i doubt it is related to your issue.
A quick way to rule out SELinux as the cause of your issue is to reproduce the issue in permissive mode.
If access is (still) denied when you try to reproduce it in permissive mode, than it is not an SELinux issue.
If it works in permissive mode, but not in enforcing mode, then it is a SELinux issue.
Well all that audit2why suggests for that avc is:
Was caused by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
On your other point, you will notice (further up in this mail) that this problem is only in Enforcing mode. Switching to Permissive does indeed stop the procmail errors.
Still watching the avcs.... I'll keep you posted..
Thanks
Mark
Whoops obviously you need to allow procmail_t to search mountpoints to make it work.
echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" auditallow -M myprocmail; semodule -i myprocmail.pp
this is a bug in policy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, 2009-08-18 at 13:48 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 12:23:25PM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 12:46 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 11:39:07AM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
[snip]
Just to add to my own mail...
I employed the above policy module, everything seemed OK so (as this seemed to be the last of the problems since upgrading) I switched to enforcing mode.
Since doing so I have received no AVCs but I am finding these in my maillog:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" procmail: Error while writing to "/mnt/backup/mail/rawmail"
Temporarily switching back with setenforce 0 stops them so it is selinux related...
[snip]
But still no AVCs
Any ideas?
Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
OK - since semodule -DB getting flooded with AVCs...
Here are some that are related to this problem...
cat /var/log/audit/audit.log | grep -i procmail .... type=AVC msg=audit(1250591203.244:43494): avc: denied { rlimitinh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { siginh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { noatsecure } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11 success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) type=AVC msg=audit(1250591203.418:43495): avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196 success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
This still with setenforce 0
Any ideas?
Thanks for your help!...
Mark
The only AVC denial that is ( a little bit ) interesting is:
avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir
Pipe this into audit2why to see if it has any suggestions. Although i doubt it is related to your issue.
A quick way to rule out SELinux as the cause of your issue is to reproduce the issue in permissive mode.
If access is (still) denied when you try to reproduce it in permissive mode, than it is not an SELinux issue.
If it works in permissive mode, but not in enforcing mode, then it is a SELinux issue.
Well all that audit2why suggests for that avc is:
Was caused by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
On your other point, you will notice (further up in this mail) that this problem is only in Enforcing mode. Switching to Permissive does indeed stop the procmail errors.
Still watching the avcs.... I'll keep you posted..
Thanks
Mark
Whoops obviously you need to allow procmail_t to search mountpoints to make it work.
echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" auditallow -M myprocmail; semodule -i myprocmail.pp
this is a bug in policy
Thank you Dominick, that's fixed it!
I had already created a policy module from that AVC just to see what it would look like - but I hadn't implemented it. Now I have and it works fine!
BTW, I though your way of creating the module was very clever - I liked that.. but for the sake of the archives there are a couple of typos:
echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" auditallow -M ^^^ ^^^ myprocmail; semodule -i myprocmail.pp
Should be: echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" | audit2allow -M myprocmail; semodule -i myprocmail.pp
Thanks again
Your help is much appreciated!
Mark
On 08/18/2009 09:41 AM, Arthur Dent wrote:
On Tue, 2009-08-18 at 13:48 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 12:23:25PM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 12:46 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 11:39:07AM +0100, Arthur Dent wrote:
On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote: > On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
[snip]
> > Just to add to my own mail... > > I employed the above policy module, everything seemed OK so (as this > seemed to be the last of the problems since upgrading) I switched to > enforcing mode. > > Since doing so I have received no AVCs but I am finding these in my > maillog: > > procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" > procmail: Error while writing to "/mnt/backup/mail/rawmail" > > Temporarily switching back with setenforce 0 stops them so it is selinux > related...
[snip]
> But still no AVCs > > Any ideas? Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. To reload policy with the silenced denials: semodule -B.
Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved)
OK - since semodule -DB getting flooded with AVCs...
Here are some that are related to this problem...
cat /var/log/audit/audit.log | grep -i procmail .... type=AVC msg=audit(1250591203.244:43494): avc: denied { rlimitinh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { siginh } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=AVC msg=audit(1250591203.244:43494): avc: denied { noatsecure } for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=process type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11 success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) type=AVC msg=audit(1250591203.418:43495): avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196 success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0 ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
This still with setenforce 0
Any ideas?
Thanks for your help!...
Mark
The only AVC denial that is ( a little bit ) interesting is:
avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir
Pipe this into audit2why to see if it has any suggestions. Although i doubt it is related to your issue.
A quick way to rule out SELinux as the cause of your issue is to reproduce the issue in permissive mode.
If access is (still) denied when you try to reproduce it in permissive mode, than it is not an SELinux issue.
If it works in permissive mode, but not in enforcing mode, then it is a SELinux issue.
Well all that audit2why suggests for that avc is:
Was caused by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
On your other point, you will notice (further up in this mail) that this problem is only in Enforcing mode. Switching to Permissive does indeed stop the procmail errors.
Still watching the avcs.... I'll keep you posted..
Thanks
Mark
Whoops obviously you need to allow procmail_t to search mountpoints to make it work.
echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" auditallow -M myprocmail; semodule -i myprocmail.pp
this is a bug in policy
Thank you Dominick, that's fixed it!
I had already created a policy module from that AVC just to see what it would look like - but I hadn't implemented it. Now I have and it works fine!
BTW, I though your way of creating the module was very clever - I liked that.. but for the sake of the archives there are a couple of typos:
echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" auditallow -M ^^^ ^^^ myprocmail; semodule -i myprocmail.pp
Should be: echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" | audit2allow -M myprocmail; semodule -i myprocmail.pp
Thanks again
Your help is much appreciated!
Mark
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
I will change rawhide to allow all domains to search mnt_t, since this is a logical place for people to mount directories that a confined application might need access to.
Similarly I will allow all domains to search default_t, which is the default name for a directory created in /
selinux@lists.fedoraproject.org