Logrotate on mounted partition

[Arthur Dent]

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)

[Arthur Dent]

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

[Dominick Grift]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Arthur Dent]

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...

[Dominick Grift]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Arthur Dent]

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

[Dominick Grift]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Arthur Dent]

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

[Dominick Grift]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Arthur Dent]

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

[Daniel J Walsh]

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(a)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 /