Red Hat Bugzilla – Bug 222778
dovecot imap permission failure
Last modified: 2014-01-21 17:56:57 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.
What avc's are you seeing? What was the policy change that you did to make it work?
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.
Look for avc messages in /var/log/audit/audit.log and /var/log/messages
/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
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 /?
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?
Reassiging to Dovecot. Why is Dovecot trying to create these files under /? Or is there some directory that it tries to create them in?
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.
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.
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.
Could you post the log entries related to this?
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)
One more note, I did try disabling selinux protection of dovecot but it had no effect.
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?
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.
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.
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.
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.
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.
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.
dovecot is a server, thunderbird, elm mutt are all clients I believe.
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.
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.
/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?
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
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
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 };
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.
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.
[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
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.
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.
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?
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?
danwalsh.livejournal.com Start reading from the beginning of my blogs on SELinux for dummies.
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)
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.
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.
I found the previous report.
So we can close this bug, and repopen the other problem.