Bug 465991 - Dovecot and mailman interaction produces selinux denial
Dovecot and mailman interaction produces selinux denial
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Horák
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-07 12:47 EDT by Sergio Pascual
Modified: 2011-10-09 12:10 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 10:04:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
My system dovecot.conf (41.63 KB, text/plain)
2008-10-21 03:59 EDT, Sergio Pascual
no flags Details

  None (edit)
Description Sergio Pascual 2008-10-07 12:47:49 EDT
I have installed both dovecot-1.0.15-10.fc9.i386 and mailman-2.1.9-10.fc9.i386
User can read their email via imap and simultaneously, the server also hosts several mailing lists.

What it's strange is the I'm getting selinux denials produced by dovecot trying to access /var/lib/mailman

SELinux is preventing imap (dovecot_t) "getattr" to /var/lib/mailman (mailman_data_t). 

I don't know I dovecot is trying to read /var/lib/mailman, but I'm getting thousands of denials a day, in fact, every time a user checks for new mail.

Raw audit messages:
host=myhost type=AVC msg=audit(1223397850.588:21218): avc: denied { getattr } for pid=28228 comm="imap" path="/var/lib/mailman" dev=dm-10 ino=2 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:mailman_data_t:s0 tclass=dir 

host=myhost type=SYSCALL msg=audit(1223397850.588:21218): arch=40000003 syscall=195 success=no exit=-13 a0=8ded08e a1=bfabeab8 a2=275ff4 a3=8ded0a0 items=0 ppid=2381 pid=28228 auid=4294967295 uid=505 gid=505 euid=505 suid=505 fsuid=505 egid=505 sgid=505 fsgid=505 tty=(none) ses=4294967295 comm="imap" exe="/usr/libexec/dovecot/imap" subj=system_u:system_r:dovecot_t:s0 key=(null)
Comment 1 Dan Horák 2008-10-20 09:15:07 EDT
Did you update dovecot.conf with something that is mailman specific?
Comment 2 Sergio Pascual 2008-10-21 03:59:12 EDT
Created attachment 320990 [details]
My system dovecot.conf

AFICS there's nothing related with mailman in my dovecot.conf
Comment 3 Neil Squires 2009-03-09 02:50:42 EDT
I am getting a number of selinux problems related to dovecot, sendmail, spamassassin and a number of incorrectly labelled directories. Some of the errors are:


Summary:

SELinux is preventing access to files with the default label, default_t.

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux permission checks on files labeled default_t are being denied. These
files/directories have the default label on them. This can indicate a labeling
problem, especially if the files being referred to are not top level
directories. Any files/directories under standard system directories, /usr,
/var. /dev, /tmp, ..., should not be labeled with the default label. The default
label is for files/directories which do not have a label on a parent directory.
So if you create a new directory in / you might legitimately get this label.

Allowing Access:

If you want a confined domain to use these files you will probably need to
relabel the file/directory with chcon. In some cases it is just easier to
relabel the system, to relabel execute: "touch /.autorelabel; reboot"

Additional Information:

Source Context                system_u:system_r:dovecot_t:s0
Target Context                system_u:object_r:default_t:s0
Target Objects                ./dovecot.index.tmp [ file ]
Source                        imap
Source Path                   /usr/libexec/dovecot/imap
Port                          <Unknown>
Host                          sensi.n-ksquires.id.au
Source RPM Packages           dovecot-1.1.10-1.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-46.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   default
Host Name                     sensi.n-ksquires.id.au
Platform                      Linux sensi.n-ksquires.id.au
                              2.6.27.19-170.2.35.fc10.x86_64 #1 SMP Mon Feb 23
                              13:00:23 EST 2009 x86_64 x86_64
Alert Count                   10
First Seen                    Fri 06 Mar 2009 11:19:41 PM EST
Last Seen                     Mon 09 Mar 2009 01:55:01 PM EST
Local ID                      efcaf38e-676a-49ae-976e-0434fbe27c91
Line Numbers                  

Raw Audit Messages            

node=sensi.n-ksquires.id.au type=AVC msg=audit(1236570901.355:714): avc:  denied  { create } for  pid=15590 comm="imap" name="dovecot.index.tmp" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file

node=sensi.n-ksquires.id.au type=SYSCALL msg=audit(1236570901.355:714): arch=c000003e syscall=2 success=yes exit=13 a0=149b1e0 a1=242 a2=180 a3=6157676f4c2f7061 items=0 ppid=3342 pid=15590 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=4294967295 comm="imap" exe="/usr/libexec/dovecot/imap" subj=system_u:system_r:dovecot_t:s0 key=(null)


Summary:

SELinux is preventing access to files with the default label, default_t.

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux permission checks on files labeled default_t are being denied. These
files/directories have the default label on them. This can indicate a labeling
problem, especially if the files being referred to are not top level
directories. Any files/directories under standard system directories, /usr,
/var. /dev, /tmp, ..., should not be labeled with the default label. The default
label is for files/directories which do not have a label on a parent directory.
So if you create a new directory in / you might legitimately get this label.

Allowing Access:

If you want a confined domain to use these files you will probably need to
relabel the file/directory with chcon. In some cases it is just easier to
relabel the system, to relabel execute: "touch /.autorelabel; reboot"

Additional Information:

Source Context                system_u:system_r:dovecot_t:s0
Target Context                system_u:object_r:default_t:s0
Target Objects                ./dovecot.index.tmp [ dir ]
Source                        imap
Source Path                   /usr/libexec/dovecot/imap
Port                          <Unknown>
Host                          sensi.n-ksquires.id.au
Source RPM Packages           dovecot-1.1.10-1.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-46.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   default
Host Name                     sensi.n-ksquires.id.au
Platform                      Linux sensi.n-ksquires.id.au
                              2.6.27.19-170.2.35.fc10.x86_64 #1 SMP Mon Feb 23
                              13:00:23 EST 2009 x86_64 x86_64
Alert Count                   10
First Seen                    Fri 06 Mar 2009 11:19:41 PM EST
Last Seen                     Mon 09 Mar 2009 01:55:01 PM EST
Local ID                      c1e59042-0abd-4d4b-9a19-b6b736c28a66
Line Numbers                  

Raw Audit Messages            

node=sensi.n-ksquires.id.au type=AVC msg=audit(1236570901.364:715): avc:  denied  { remove_name } for  pid=15590 comm="imap" name="dovecot.index.tmp" dev=dm-0 ino=45375585 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir

node=sensi.n-ksquires.id.au type=AVC msg=audit(1236570901.364:715): avc:  denied  { rename } for  pid=15590 comm="imap" name="dovecot.index.tmp" dev=dm-0 ino=45375585 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file

node=sensi.n-ksquires.id.au type=AVC msg=audit(1236570901.364:715): avc:  denied  { unlink } for  pid=15590 comm="imap" name="dovecot.index" dev=dm-0 ino=45378383 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file

node=sensi.n-ksquires.id.au type=SYSCALL msg=audit(1236570901.364:715): arch=c000003e syscall=82 success=yes exit=0 a0=149b1e0 a1=14b0310 a2=3ad3d6da60 a3=0 items=0 ppid=3342 pid=15590 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=4294967295 comm="imap" exe="/usr/libexec/dovecot/imap" subj=system_u:system_r:dovecot_t:s0 key=(null)

In addition my squirrelmail will not function unless I put selinux into permissive mode.

I am investigating and have relabelled my system twice since the last update and added the following modules to resolve some of the problems:

module spamdfix 1.0;

require {
	type spamass_milter_data_t;
	type dovecot_t;
	type default_t;
	type spamd_t;
	type xdm_t;
	class dir { write search read getattr }	class file { read rename };
}

#============= dovecot_t ==============
allow dovecot_t default_t:dir { read write };
allow dovecot_t default_t:file read;

#============= spamd_t ==============
allow spamd_t spamass_milter_data_t:file rename;

#============= xdm_t ==============
allow xdm_t default_t:dir { read write search getattr };


module reboot 2.0;

require {
	type dovecot_t;
	type default_t;
	class file { write getattr };
}

#============= dovecot_t ==============
allow dovecot_t default_t:file { write getattr };


module reboot3 1.0;

require {
	type dovecot_t;
	type default_t;
	class file lock;
	class dir add_name;
}

#============= dovecot_t ==============
allow dovecot_t default_t:dir add_name;
allow dovecot_t default_t:file lock;

I am still investigating the squirrelmail issue and suspect a boolean setting for the httpd.
Comment 4 Bug Zapper 2009-06-09 22:54:23 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2009-07-14 10:04:46 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.