Bug 804186

Summary: AVCs when sending mail to root, using postfix + ~/Maildir
Product: Red Hat Enterprise Linux 6 Reporter: Ferry Huberts <mailings>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Michal Trunecka <mtruneck>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.2CC: dwalsh, ebenes, mmalik, mtruneck
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 12:32:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ferry Huberts 2012-03-16 19:05:16 UTC
Description of problem:
I have configured a postfix mail server with dovecot and squirrelmail.
Postfix delivers to ~/Maildir

Sending mail to root gives AVCs.
Sending mail to regular users gives no AVCs


Version-Release number of selected component (if applicable):
selinux-policy-3.7.19-126.el6_2.10.noarch

How reproducible:
always

Steps to Reproduce:
1. setup postfix with Maildir
2. send mail to root
3.
  
Actual results:
type=AVC msg=audit(1331924053.431:36): avc:  denied  { write } for  pid=2006 comm="local" name="Maildir" dev=dm-0 ino=1575486 scontext=system_u:system_r:postfix_local_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=dir
type=AVC msg=audit(1331924053.501:37): avc:  denied  { write } for  pid=2006 comm="local" name="Maildir" dev=dm-0 ino=1575486 scontext=system_u:system_r:postfix_local_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=dir


Expected results:
mail delivery

Additional info:
I think /root/Maildir should be labeled as postfix_local_t

Comment 2 Ferry Huberts 2012-03-16 19:14:29 UTC
However, if I add the filecontext, like:

[root@gittest6 ~]# /usr/sbin/semanage fcontext -a -f -d -t "postfix_local_t" "/root/Maildir"
[root@gittest6 ~]# restorecon -Rv /root
restorecon reset /root/Maildir context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:postfix_local_t:s0
restorecon set context /root/Maildir->unconfined_u:object_r:postfix_local_t:s0 failed:'Permission denied'

==> I'm not expecting this error?!

[root@gittest6 ~]# setenforce 0
[root@gittest6 ~]# restorecon -Rv /root
restorecon reset /root/Maildir context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:postfix_local_t:s0
[root@gittest6 ~]# setenforce 1


[root@gittest6 ~]# mail -s test root


Now I also get AVCs:

type=AVC msg=audit(1331925028.482:144): avc:  denied  { write } for  pid=3037 comm="local" name="Maildir" dev=dm-0 ino=1575486 scontext=system_u:system_r:postfix_local_t:s0 tcontext=unconfined_u:object_r:postfix_local_t:s0 tclass=dir
type=AVC msg=audit(1331925028.491:145): avc:  denied  { write } for  pid=3037 comm="local" name="Maildir" dev=dm-0 ino=1575486 scontext=system_u:system_r:postfix_local_t:s0 tcontext=unconfined_u:object_r:postfix_local_t:s0 tclass=dir

Comment 3 Ferry Huberts 2012-03-16 19:56:39 UTC
doing:

# setenforce 0
# mail -s test  root
test
.
EOT


gives me:

type=AVC msg=audit(1331927666.760:260): avc:  denied  { create } for  pid=18660 comm="local" name="1331927666.P18660.gittest6.internal.hupie.com" scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:postfix_local_t:s0 tclass=file
type=AVC msg=audit(1331927666.783:261): avc:  denied  { link } for  pid=18660 comm="local" name="1331927666.P18660.gittest6.internal.hupie.com" dev=dm-0 ino=1575495 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:postfix_local_t:s0 tclass=file
type=AVC msg=audit(1331927666.783:262): avc:  denied  { unlink } for  pid=18660 comm="local" name="1331927666.P18660.gittest6.internal.hupie.com" dev=dm-0 ino=1575495 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:postfix_local_t:s0 tclass=file

Comment 4 Daniel Walsh 2012-03-17 09:27:04 UTC
postfix_local_t is a process label.  You are not allowed to put process labels on files and file labels on processes.

There is a boolean that would have allowed what you want.

allow_postfix_local_write_mail_spool

Fix your labels on your homedir.

restorecon -R -v /home
Turn on the boolean

# setsebool -P allow_postfix_local_write_mail_spool

Then you should be ready to go.

Comment 5 Ferry Huberts 2012-03-17 10:53:07 UTC
Nope.

That boolean is on.

Note that I'm talking about delivery to /root/Maildir. That directory is labeled unconfined_u:object_r:admin_home_t:s0

Comment 6 Daniel Walsh 2012-03-17 11:13:25 UTC
Well for now, you can label this as mail_spool_t.

semanage fcontext -a -t mail_spool_t '/root/Maildir(/.*)?'
restorecon -R -v /root/Maildir

Comment 7 Daniel Walsh 2012-03-17 11:16:06 UTC
It would see mail_home_t might be a good label for this, but this seems to be more for read only mail content.

grep mail_home_t /etc/selinux/targeted/contexts/files/file_contexts
/root/.mailrc	--	system_u:object_r:mail_home_t:s0
/root/dead.letter	--	system_u:object_r:mail_home_t:s0
/root/\.forward	--	system_u:object_r:mail_home_t:s0
/root/\.procmailrc	--	system_u:object_r:procmail_home_t:s0
/root/\.fetchmailrc	--	system_u:object_r:fetchmail_home_t:s0

Maybe we need a new label for mail_home_rw_t

Comment 8 Ferry Huberts 2012-03-17 11:27:12 UTC
(In reply to comment #6)
> Well for now, you can label this as mail_spool_t.
>
> semanage fcontext -a -t mail_spool_t '/root/Maildir(/.*)?'
> restorecon -R -v /root/Maildir

that works :-)


(In reply to comment #7)
> Maybe we need a new label for mail_home_rw_t

That might be a nice idea; label '/(root|home)/Maildir(/.*)? as mail_home_rw_t


Thanks Dan!

Comment 9 Ferry Huberts 2012-03-17 11:28:30 UTC
Do you want to reopen this bug then?

I guess I'll not be the only one with a setup like this, seeing that postfix is the default MTA (at least for the minimal install)

Comment 10 Daniel Walsh 2012-03-19 15:14:04 UTC
I just added mail_home_rw_t and allowed mail delivery agents to write there.

Comment 12 Miroslav Grepl 2012-03-19 15:57:41 UTC
Added to RHEL6.3

Comment 13 Ferry Huberts 2012-03-19 16:56:47 UTC
Awesome, thanks!
(is this fix for 6.2 a realistic wish?)


Did you also add the fcontexts on /home/.../Maildir and /root/Maildir?
Currently these fcontexts are not defined
(6.2, selinux-policy-3.7.19-126.el6_2.10.noarch)

(In reply to comment #8)
> That might be a nice idea; label '/(root|home)/Maildir(/.*)? as mail_home_rw_t

obviously that should be
  label '/(root|home/[^/]+)/Maildir(/.*)?' as 'mail_home_rw_t'

Comment 19 errata-xmlrpc 2012-06-20 12:32:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0780.html

Comment 20 Ferry Huberts 2014-10-14 18:19:39 UTC
I don't see the mail_home_rw_t fcontext in my RHEL 6.5 boxes.
(semanage fcontext -l | grep -i mail_home_rw)


selinux-policy-targeted.noarch  3.7.19-231.el6_5.3

Comment 21 Ferry Huberts 2014-10-14 18:32:40 UTC
ah, so the fcontext now is

/root/Maildir(/.*)?  all files  system_u:object_r:mail_spool_t:s0 

that should work as well.
testing...

If I create the /root/Maildir directory in advance with the right context it works. if I let postfix create the directory it doesn't apply the right context and it fails.

So it seems kind-of fixed.
This now seems to be a postfix bug?

Comment 22 Miroslav Grepl 2014-11-03 11:03:34 UTC
(In reply to Ferry Huberts from comment #21)
> ah, so the fcontext now is
> 
> /root/Maildir(/.*)?  all files  system_u:object_r:mail_spool_t:s0 
> 
> that should work as well.
> testing...
> 
> If I create the /root/Maildir directory in advance with the right context it
> works. if I let postfix create the directory it doesn't apply the right
> context and it fails.
> 
> So it seems kind-of fixed.
> This now seems to be a postfix bug?

You will need to open a new bug.

Comment 23 Ferry Huberts 2014-11-03 11:24:34 UTC
see bug #1159801