Bug 222778 - dovecot imap permission failure
dovecot imap permission failure
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Janousek
: Reopened
Depends On: 178569
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-16 00:57 EST by David Highley
Modified: 2014-01-21 17:56 EST (History)
3 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-06 12:50:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Audit log (3.77 MB, text/plain)
2007-02-15 22:32 EST, David Highley
no flags Details

  None (edit)
Description David Highley 2007-01-16 00:57:32 EST
Description of problem:
dovecot logs a permission failure for imap connection.


Version-Release number of selected component (if applicable):
selinux-policy-targeted-2.4.6-23.fc6

How reproducible:
Every time

Steps to Reproduce:
1.Try to connect with thunderbird using imap connection port 143
2.Running on the mail server system.
3.
  
Actual results:


Expected results:


Additional info:
Changing to permissive mode it works. I have tried the most obvious policy
changes but fixed the issue.
Comment 1 Daniel Walsh 2007-01-16 09:26:45 EST
What avc's are you seeing?  What was the policy change that you did to make it work?
Comment 2 David Highley 2007-01-16 23:11:36 EST
I do not see any avc's reported in the /var/log/secure file. I tried disabling
selinux protection for dovecot daemon but that made no difference. I did not see
any other obvious change to make. If I change selinux to permissive it works.

Here is what I find in /var/log/maillog:
Jan 16 20:01:32 douglas dovecot: imap-login: Aborted login: rip=::ffff:10.2.2.7,
 lip=::ffff:10.2.2.7, secured
Jan 16 20:02:22 douglas dovecot: imap-login: Login: user=<dhighley>, method=plai
n, rip=::ffff:10.2.2.7, lip=::ffff:10.2.2.7, secured

For history purposes, I ran into this in core 5 as well.
Comment 3 Daniel Walsh 2007-01-17 10:37:08 EST
Look for avc messages in /var/log/audit/audit.log and /var/log/messages
Comment 4 David Highley 2007-01-17 22:38:55 EST
/var/log/audit/audit.log:

type=USER_ACCT msg=audit(1168811105.322:310): user pid=6246 uid=0 auid=429496729
5 subj=system_u:system_r:dovecot_auth_t:s0 msg='PAM: accounting acct=dhighley : 
exe="/usr/libexec/dovecot/dovecot-auth" (hostname=::ffff:10.2.2.7, addr=::ffff:1
0.2.2.7, terminal=dovecot res=success)'
type=AVC msg=audit(1168811105.370:311): avc:  denied  { create } for  pid=6249 c
omm="imap" name=".imap" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_
u:object_r:root_t:s0 tclass=dir
type=SYSCALL msg=audit(1168811105.370:311): arch=c000003e syscall=83 success=no 
exit=-13 a0=69e1f0 a1=1f8 a2=19 a3=69e1f0 items=0 ppid=3009 pid=6249 auid=429496
7295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=
1000 tty=(none) comm="imap" exe="/usr/libexec/dovecot/imap" subj=system_u:system
_r:dovecot_t:s0 key=(null)


/var/log/messages:

Jan 13 11:36:36 douglas kernel: audit(1168716996.619:44): avc:  denied  { link }
 for  pid=14806 comm="imap" name=".temp.douglas.14806.1a87a8e646cb9863" dev=dm-0
 ino=12487157 scontext=user_u:system_r:dovecot_t:s0 tcontext=user_u:object_r:roo
t_t:s0 tclass=file
Jan 13 11:36:36 douglas kernel: audit(1168716996.619:45): avc:  denied  { unlink
 } for  pid=14806 comm="imap" name=".temp.douglas.14806.1a87a8e646cb9863" dev=dm
-0 ino=12487157 scontext=user_u:system_r:dovecot_t:s0 tcontext=user_u:object_r:r
oot_t:s0 tclass=file
Jan 13 11:36:36 douglas kernel: audit(1168716996.639:46): avc:  denied  { create
 } for  pid=14806 comm="imap" name=".imap" scontext=user_u:system_r:dovecot_t:s0
 tcontext=user_u:object_r:root_t:s0 tclass=dir
Comment 5 Daniel Walsh 2007-01-18 13:47:40 EST
According to those AVC messages you are trying to create .imap and .temp.douglas
in directories labeled root_t.   Is this a new directory under /?
Comment 6 David Highley 2007-01-18 22:11:44 EST
I checked and those directories do not exist. So I postulate that this is
another program that violates sound practices of where it should create
temporary file structures. Should this bug be moved to a dovecot bug?
Comment 7 Daniel Walsh 2007-01-19 08:47:33 EST
Reassiging to Dovecot.

Why is Dovecot trying to create these files under /?  Or is there some directory
that it tries to create them in?
Comment 8 Tomas Janousek 2007-01-19 10:31:55 EST
What configuration do you use?

Look at the section "Detecting what to use" in
/usr/share/doc/dovecot-1.0/mail-storages.txt -- it may explain the problem.

I couldn't reproduce the problem though. I was trying very hard to make selinux
actually log something, but it did not. I wonder how lucky one must be for it to
log these errors. Dan told me to turn off "allow_daemons_dump_core" and it still
didn't make it.
Comment 9 David Highley 2007-01-19 11:35:51 EST
I guess switching from Solaris to Linux and from UW IMAP to dovecot was not as
transparent as it appeared to be. Since it worked until Selinux came about I
just assumed, fell into the unconsious incompetant realm, that dovecot was
pretty simple once ssl certificates were constructed. Reading the above document
gave me hints, but the real enlightening information is in /etc/dovecot which I
had never looked at.:-( I find dovecot now to be vastly configurable and I need
to address its configuration. Looks like this issue is where the dynamic
generated indexes are created, which can be in memory. Thirty years of
spelunking without a latern makes me cautious but I still occassionaly fall into
the unconsious incompetant abyss. I'm closing this call and thanks for the support.
Comment 10 David Highley 2007-01-20 09:41:22 EST
After changing the dovecot /etc/dovecot.conf file to use in memory indexes it
only ran to the next file issue. It was able to create the file ~/Mail/Trash but
then it gets a permission error trying to access that file.
-rw------- 1 dhighley staff       0 Jan 19 21:52 Trash

I've Googled the net and gone to the dovecot wiki site but I find no
documentation on how to configure so it will work with selinux.
Comment 11 Tomas Janousek 2007-01-20 10:14:52 EST
Could you post the log entries related to this?
Comment 12 David Highley 2007-01-20 22:04:37 EST
From /var/log/maillog:
Jan 19 21:31:12 douglas dovecot: imap-login: Login: user=<dhighley>, method=plai
n, rip=::ffff:10.2.2.7, lip=::ffff:10.2.2.7, TLS
Jan 19 21:31:28 douglas dovecot: imap-login: Login: user=<dhighley>, method=plai
n, rip=::ffff:10.2.2.7, lip=::ffff:10.2.2.7, TLS
Jan 19 21:31:28 douglas dovecot: IMAP(dhighley): open() failed with mbox file /h
ome/dhighley/Mail/Trash: Permission denied

From /var/log/audit/audit.log:
type=USER_ACCT msg=audit(1169271647.218:9491): user pid=21071 uid=0 auid=1000 su
bj=user_u:system_r:dovecot_auth_t:s0 msg='PAM: accounting acct=dhighley : exe="/
usr/libexec/dovecot/dovecot-auth" (hostname=::ffff:10.2.2.7, addr=::ffff:10.2.2.
7, terminal=dovecot res=success)'
type=AVC msg=audit(1169271647.231:9492): avc:  denied  { lock } for  pid=21072 c
omm="imap" name="Trash" dev=dm-0 ino=12487136 scontext=user_u:system_r:dovecot_t
:s0 tcontext=user_u:object_r:root_t:s0 tclass=file
type=SYSCALL msg=audit(1169271647.231:9492): arch=c000003e syscall=72 success=ye
s exit=0 a0=8 a1=7 a2=7ffff5432890 a3=0 items=0 ppid=19159 pid=21072 auid=1000 u
id=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 t
ty=(none) comm="imap" exe="/usr/libexec/dovecot/imap" subj=user_u:system_r:dovec
ot_t:s0 key=(null)
Comment 13 David Highley 2007-01-20 22:06:13 EST
One more note, I did try disabling selinux protection of dovecot but it had no
effect.
Comment 14 Tomas Janousek 2007-01-21 04:08:50 EST
This seems like your selinux is somewhat broken. I can't reproduce it in any way
(but I believe my selinux is broken as well). It is a very nonstandard behavior
we would have noticed if it was caused by a bug, so I believe there has to be
something wrong with your system.

Daniel, any tips on this?
Comment 15 David Highley 2007-01-21 10:06:32 EST
This is a new install of Fedora core 6. But I had the same issue with Fedora
core 5 which was also a new install. From my perspective it has never worked.
Comment 16 Daniel Walsh 2007-01-22 10:36:39 EST
So with your configuration you want the dovecot server to store files in root's
Homedir.  Is this a standard behavior?  IE Is it expected that Dovecot writes to
home directories?  Or should it just write to /root?  Or is this a customization
that you added?

You can use audit2allow -M mydovecot < /var/log/audit/audit.log  to create 
local policy to allow dovecot to run on your system. 
Comment 17 David Highley 2007-01-22 22:08:12 EST
No, I do not want files to be stored in the root directory. After configuring
dovecot to use momory cached indexs I do not believe it is trying to write in
the root directory. I see that it has trouble with /home/dhighley/Mail/Trash
from the log files above which is in the user's mail directory. Which it
created, because I removed it before retesting and after creation it was some
how not able to access the file as I understand it from looking at the log files.
Comment 18 David Highley 2007-02-08 20:04:30 EST
Where are we on this issue? I made a configuration change so that dovecot does
not create index files at "/". But it still needs to be able to write to the
users Mail folder directory. So far I have been able to get SeLinux and iptables
to work with all my systems except for E-mail.
Comment 19 Daniel Walsh 2007-02-12 10:09:01 EST
The question I have, is having dovecot store messages in users home directories
a normal behavior for dovecot.  We can add a boolean to policy to allow it.  But
the goal of most of selinux policy is to prevent Network Facing daemons from
read/writing users homedirectories.
Comment 20 David Highley 2007-02-14 01:54:57 EST
I'm not able to think of any E-mail application that does not write files in the
users home directory tree. Elm, mutt, dovecot, thunderbird, all want to be able
to save E-mails to files in the users home directory structure.
Comment 21 Daniel Walsh 2007-02-14 15:15:59 EST
dovecot is a server, thunderbird, elm mutt are all clients I believe.
Comment 22 David Highley 2007-02-14 22:42:48 EST
What about if they are all running on the same system. Another E-mail related
policy change is running squirrel mail on an outside server requires changing
the policy rule to allow HTTPD scripts and modules to connect to the network.

So here is the bigger picture. You have a web server on the perimeter with
squirrel mail for roaming E-mail access which connects to an inside E-mail
server via dovecot. The user when inside can use either squirrel mail via the
web server or thunderbird from any system including the inside E-mail server
since it is just another server system. All the inside E-mail connections are
IMAP E-mail server connections.

E-mail is the hardest service to provide and the most difficult to debug when
something is misconfigured.
Comment 23 Daniel Walsh 2007-02-15 09:26:18 EST
What change did you need to make to http to allow squirrelmail to work?

You understand mail servers a lot better then I do.  My only goal is to limit
the vulnerability of a system daemon being able to get access to users home
dirs.  If it is required and usual for dovecot to store mail directly in users
home directories rather then in /var/spool/mail, then I can add policy and a
boolean to allow it.
Comment 24 Timo Sirainen 2007-02-15 11:51:49 EST
/var/spool/mail usually contains only the user's INBOX, and even that only when
using mbox format. With IMAP there are other mailboxes as well and they're
typically stored in ~/mail. If maildir is used, usually everything is stored in
~/Maildir.

Maybe the policy could allow access to ~/mail, ~/Mail and ~/Maildir?
Comment 25 Daniel Walsh 2007-02-15 12:14:55 EST
Ok, I reread the policy and it looks like dovecot should be allowed to use these
directories.

What avc messages are you seeing now?

What policy do you have installed?

rpm -q selinux-policy

Comment 26 David Highley 2007-02-15 22:32:34 EST
Created attachment 148169 [details]
Audit log

I have attached the audit log from the E-mail server. You will find that there
are many denied entries associated with E-mail; spamd, pyzor, procmail, and
dovecot. I'm now using todays policy update:
selinux-policy-2.4.6-37.fc6
Comment 27 Daniel Walsh 2007-02-16 09:22:37 EST
Running this log file under audit2allow reveals:


#============= dovecot_t ==============
allow dovecot_t etc_runtime_t : file write;
> This is strange it looks like dovecot is using files under /etc to store
state.  Draft, Sent?
allow dovecot_t root_t : file lock;
> We discussed above that using / for these files is a bad idea.

#============= procmail_t ==============
allow procmail_t etc_runtime_t : file append;
> Why is spamlog stored under /etc?
allow procmail_t root_t : dir { write remove_name add_name };
allow procmail_t root_t : file { write getattr link lock create unlink append };
> Using / is bad

#============= pyzor_t ==============
allow pyzor_t autofs_t : dir search;
> Should be dontaudited
allow pyzor_t etc_runtime_t : file { read getattr };
> Is the servers file something created by init scripts?
allow pyzor_t root_t : file { read getattr };
> See comment about / above.
allow pyzor_t tmp_t : dir { write remove_name search add_name };
allow pyzor_t tmp_t : file { write read create unlink getattr };
> I have added this to policy

#============= spamd_t ==============
allow spamd_t etc_runtime_t : file { write append };
> spamd is writing to a bunch of files under /etc razor-agent.log, auto-whitelist?

allow spamd_t pyzor_t : process signal;
> Added to policy.
allow spamd_t root_t : file { ioctl unlink link append };

Comment 28 David Highley 2007-02-16 10:40:57 EST
How do I respond to this, I did not write the applications nor define the
defaults. I checked all the locations I know for spamassassin and dovecot
configuration files and found nothing coded to /etc. The packaging for
spamassasin  locates the run configuration files which are read from
/etc/mail/spamassassin. This should be for read only. I constantly see
applications trying to create or access stuff in /home which on any reasonable
configuration is an automount location for home directories. I continualy run a
find script to remove duplicate configuration files because the rpm packagers do
not check to see if the current file is the same as the new one they want to
create so they end up creating file.newrpm. So do you think we need to replicate
this bug report to all these applications? Does the policies allow applications
to read configuration files? Sorry for the rant.
Comment 29 Daniel Walsh 2007-02-16 11:22:30 EST
I am looking for where these etc_runtime_t files are.

Could you execute the following:

# find /etc -context "*etc_runtime_t*"

You might also have some labeling problem on your system, 

restorecon -R -v /home 
Might clean up some  of these.

Comment 30 David Highley 2007-02-16 17:46:22 EST
[root@douglas ~]# find /etc -context "*etc_runtime_t*"
/etc/issue
/etc/mtab
/etc/motd
/etc/blkid
/etc/blkid/blkid.tab
/etc/blkid/blkid.tab.old
/etc/X11/xorg.conf.backup-nvidia-glx
/etc/X11/xorg.conf
/etc/smartd.conf
/etc/issue.net
/etc/asound.state
/etc/modprobe.conf.backup-nvidia-glx
/etc/sysconfig/iptables-config
/etc/sysconfig/firstboot
/etc/sysconfig/hwconf
/etc/reader.conf
Comment 31 Daniel Walsh 2007-02-22 13:02:00 EST
The following files are mistakenly labeled as etc_runtime_t.  This is what is
causing the problems.  
bayes_seen
bayes_toks
Draft
auto-whitelist
spamlog
servers
razor-agent.log

Dovecot and spamd are both trying to write to these files or a subset of them. 
If these files are in a home dir they are mislabled.
Comment 32 David Highley 2007-02-22 22:42:03 EST
OK, since I do not know how a label gets on a new file that is an issue. I also
do not know how to change the label. I have looked at the man pages starting
with selinux but did not find this information.
Comment 33 David Highley 2007-02-22 23:07:32 EST
Further spelunking at, http://fedora.redhat.com/docs/selinux-faq-fc5/, shows
that in Fedora core 5 you could use the chown -t option. That does not appear to
be the way to do it in Fedora core 6 as I find now -t option. Given I discover
how to label a file, what should the label be and will it stick across a file
system relabel using the default policies?
Comment 34 David Highley 2007-02-22 23:23:36 EST
More reading seems to have found the answer. Using restore -v -R on the home
directories ~/.spamassassin ~/.razor and ~/Mail as well as fixing the file
spamlog changed the file labels. Still do not know how they got the wrong
labels. Is there a better place to learm more about selinux than the faq
location above?
Comment 35 Daniel Walsh 2007-02-23 10:20:51 EST
danwalsh.livejournal.com  Start reading from the beginning of my blogs on
SELinux for dummies.
Comment 36 David Highley 2007-02-28 09:54:29 EST
While the E-mail server is working we still have the following audit log
entries, do we need to submit bug reports against pyzor and procmail?

type=AVC msg=audit(1172276152.919:25664): avc:  denied  { search } for  pid=2098
0 comm="pyzor" name="/" dev=autofs ino=10947 scontext=user_u:system_r:pyzor_t:s0
 tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=SYSCALL msg=audit(1172276152.919:25664): arch=c000003e syscall=2 success=no
 exit=-13 a0=6c6280 a1=0 a2=1b6 a3=0 items=0 ppid=5095 pid=20980 auid=1000 uid=1
000 gid=0 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(non
e) comm="pyzor" exe="/usr/bin/python" subj=user_u:system_r:pyzor_t:s0 key=(null)
type=AVC msg=audit(1172276152.919:25665): avc:  denied  { search } for  pid=2098
0 comm="pyzor" name="/" dev=autofs ino=10947 scontext=user_u:system_r:pyzor_t:s0
 tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=SYSCALL msg=audit(1172276152.919:25665): arch=c000003e syscall=4 success=no
 exit=-13 a0=6c6240 a1=7fff8860d5b0 a2=7fff8860d5b0 a3=6c6240 items=0 ppid=5095
pid=20980 auid=1000 uid=1000 gid=0 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid
=1000 fsgid=1000 tty=(none) comm="pyzor" exe="/usr/bin/python" subj=user_u:syste
m_r:pyzor_t:s0 key=(null)
type=AVC msg=audit(1172276152.919:25666): avc:  denied  { search } for  pid=2098
0 comm="pyzor" name="/" dev=autofs ino=10947 scontext=user_u:system_r:pyzor_t:s0
 tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=SYSCALL msg=audit(1172276152.919:25666): arch=c000003e syscall=83 success=n
o exit=-13 a0=6c6240 a1=1ff a2=37a8f2f4d8 a3=6c6240 items=0 ppid=5095 pid=20980
auid=1000 uid=1000 gid=0 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgi
d=1000 tty=(none) comm="pyzor" exe="/usr/bin/python" subj=user_u:system_r:pyzor_
t:s0 key=(null)
type=AVC msg=audit(1172276154.276:25667): avc:  denied  { write } for  pid=20976
 comm="procmail" name="dhighley" dev=dm-0 ino=12485695 scontext=system_u:system_
r:procmail_t:s0 tcontext=root:object_r:root_t:s0 tclass=dir
type=SYSCALL msg=audit(1172276154.276:25667): arch=c000003e syscall=2 success=no
 exit=-13 a0=61b5e0 a1=c1 a2=124 a3=61b5e0 items=0 ppid=20973 pid=20976 auid=429
4967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=12 fsgid
=1000 tty=(none) comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:
procmail_t:s0 key=(null)
Comment 37 Daniel Walsh 2007-03-01 09:34:06 EST
The pyzor denial I will fix in the next update to fc6.  procmail trying to write
to root_t, looks like a labeling problem or a configuration problem.  It is
trying to write to a directortory dhighley, labeled root_t, which is the default
directory of the / directory.

Comment 38 David Highley 2007-03-03 01:00:03 EST
I just did a touch /.autorelabel and reboot. The home directories were miss
labeled. The policies are not working when the home directories are auto mounted
and the real file location is /export/home. I know I reported this as an issue
before but I could not find it using the advanced query. So I had to re-label,
restorecon -rv /home/user, to fix the labeling again.
Comment 39 David Highley 2007-03-03 01:06:35 EST
I found the previous report.
Comment 40 Daniel Walsh 2007-03-06 12:50:28 EST
So we can close this bug, and repopen the other problem.

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