[Dovecot] Security issue #5: mail_extra_groups setting is often used insecurely
mail_extra_groups=mail setting is often used insecurely to give Dovecot access to create dotlocks to /var/mail directory. If you don't use mboxes in /var/mail, make sure this setting is cleared.
If you do use /var/mail mboxes and Dovecot gives permission errors without it, do one of the following (in the preferred order):
a) Upgrade to v1.0.11 and use the new mail_privileged_group setting instead of mail_extra_groups. b) Make /var/mail sticky and world-writable (chmod 01777 /var/mail) and clear mail_extra_groups setting. c) Make /var/mail sticky (chmod +t /var/mail) and keep mail_extra_groups setting. This fixes the main problem but some may be left.
The mail_privileged_group setting is also available as a patch: http://dovecot.org/patches/1.0/dovecot-1.0.10.mail_priv_groups.diff
mail_extra_groups setting has existed since Dovecot v0.99.10.6. It's never been enabled by default in the distributed dovecot-example.conf, but some distributions enable it by default (at least Debian).
A longer explanation:
The main problem is that if users have filesystem access to the mail server, they can create symlinks. Dovecot doesn't try to prevent following symlinks (and I don't think it should) and normally it isn't a problem. But when mail_extra_groups=mail is set:
1a) Maildir: Any files readable by mail group can be read by the user by symlinking the file to their ~/Maildir/cur/.
1b) Any mbox files readable by mail group can be read by the user by symlinking the mbox file to their ~/mail/ directory.
These are pretty obvious problems and I didn't think they were all that important. Why would anyone have secret files that are mail group-readable? But apparently those do exist in some systems (maybe accidentally).
2a) mbox: Any files/directories under mail group-writable directories can be created/deleted/renamed by symlinking the directory under ~/mail/. For example ln -s /var/mail ~/mail/var, DELETE var/root will happily delete root's mailbox. This I hadn't thought about before.
2b) Maildir: Pretty much the same thing can be done with maildir but with a little less control.
mail_privileged_group setting works by keeping the group in process's saved GID while it's not in use and temporarily switching it to effective GID while dotlocks are created. Currently this is done only when:
It's only done for INBOX mbox which doesn't exist under the same location as other mailboxes (so typically under /var/mail).
It's used only after initial dotlock creation try failed with EACCES error.
Oh, forgot to mention: Thanks to John Rowe for bugging me about this until I did more than just add some warning comments to dovecot-example.conf. :)
And one more thing: v1.0.rc2 will be released in a day or two with this change but I'd rather fix a few more bugs before that. If you need it already, use the nightly snapshot: http://dovecot.org/nightly/dovecot-latest.tar.gz
On Tue, Mar 4, 2008 at 9:50 AM, Timo Sirainen tss@iki.fi wrote:
And one more thing: v1.0.rc2 will be released in a day or two with this change but I'd rather fix a few more bugs before that. If you need it already, use the nightly snapshot: http://dovecot.org/nightly/dovecot-latest.tar.gz
You meant 1.1.rc2
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
"Oh My God! They killed init! You Bastards!" --from a /. post
Timo Sirainen a écrit :
mail_extra_groups=mail setting is often used insecurely to give Dovecot access to create dotlocks to /var/mail directory. If you don't use mboxes in /var/mail, make sure this setting is cleared. [...] 2a) mbox: Any files/directories under mail group-writable directories can be created/deleted/renamed by symlinking the directory under ~/mail/. For example ln -s /var/mail ~/mail/var, DELETE var/root will happily delete root's mailbox. This I hadn't thought about before.
Not if /var/mail is set sticky, which is the case on all good modern Unix systems:
drwxrwsr-t 2 root mail 4096 2005-12-21 10:19 /var/mail/
mail_privileged_group setting works by keeping the group in process's saved GID while it's not in use and temporarily switching it to effective GID while dotlocks are created. Currently this is done only when:
It's only done for INBOX mbox which doesn't exist under the same location as other mailboxes (so typically under /var/mail).
It's used only after initial dotlock creation try failed with EACCES error.
Too bad... I found mail_extra_groups to be a very handy (and secure) way to handle Dovecot automatic index creation outside user's directory.
I have in dovecot.conf:
mail_extra_groups = mail
mail_location = mbox:~/mail:INBOX=~/mail/INBOX:INDEX=/var/cache/dovecot/indexes/%16Hu/%u
As you can see, all indexes are maintained in /var/cache/dovecot (to be excluded from filesystem quotas), and /var/cache/dovecot/indexes/X directories are pre-created with these perms:
drwxrwsr-t 56 root mail 4096 2008-02-29 03:33 X
This way I don't bother creating index directories for every user, they are created automatically as needed on the first access. I have also a script to expunge old indexes not accessed since a while.
Without mail_extra_groups, I would need to set /var/cache/dovecot/indexes/X directories world-writeable, which is quite less elegant...
-- Ce message a ete verifie par MailScanner pour des virus ou des polluriels et rien de suspect n'a ete trouve.
On Mar 4, 2008, at 10:50 AM, Benoit Branciard wrote:
Timo Sirainen a écrit :
mail_extra_groups=mail setting is often used insecurely to give
Dovecot access to create dotlocks to /var/mail directory. If you don't use mboxes in /var/mail, make sure this setting is cleared. [...] 2a) mbox: Any files/directories under mail group-writable directories can be created/deleted/renamed by symlinking the directory under ~/mail/. For example ln -s /var/mail ~/mail/var, DELETE var/root will happily delete root's mailbox. This I hadn't thought about before.Not if /var/mail is set sticky, which is the case on all good modern
Unix systems:
Right. That's why it was included in the workarounds. :)
Anyway I also thought that /var/mail would be sticky in at least some
systems. I couldn't find a single one. CentOS 5, Debian, FreeBSD 6.2,
Solaris 10 none have it sticky by default.
mail_privileged_group setting works by keeping the group in process's saved GID while it's not in use and temporarily switching it to effective GID while dotlocks are created. Currently this is done only when:
- It's only done for INBOX mbox which doesn't exist under the same location as other mailboxes (so typically under /var/mail).
- It's used only after initial dotlock creation try failed with
EACCES error.Too bad... I found mail_extra_groups to be a very handy (and secure)
way to handle Dovecot automatic index creation outside user's
directory.
I didn't remove the setting, just renamed it to mail_access_groups.
Timo Sirainen a écrit :
2a) mbox: Any files/directories under mail group-writable directories can be created/deleted/renamed by symlinking the directory under ~/mail/. For example ln -s /var/mail ~/mail/var, DELETE var/root will happily delete root's mailbox. This I hadn't thought about before.
Not if /var/mail is set sticky, which is the case on all good modern Unix systems:
Right. That's why it was included in the workarounds. :)
Anyway I also thought that /var/mail would be sticky in at least some systems. I couldn't find a single one. CentOS 5, Debian, FreeBSD 6.2, Solaris 10 none have it sticky by default.
All our Debian Sarge and Etch systems (with Sendmail and procmail packages) have /var/mail sticky by default, we didn't modify it ourselves.
-- Ce message a ete verifie par MailScanner pour des virus ou des polluriels et rien de suspect n'a ete trouve.
On Tue, 2008-03-04 at 13:42 +0100, Benoit Branciard wrote:
Timo Sirainen a écrit :
2a) mbox: Any files/directories under mail group-writable directories can be created/deleted/renamed by symlinking the directory under ~/mail/. For example ln -s /var/mail ~/mail/var, DELETE var/root will happily delete root's mailbox. This I hadn't thought about before.
Not if /var/mail is set sticky, which is the case on all good modern Unix systems:
Right. That's why it was included in the workarounds. :)
Anyway I also thought that /var/mail would be sticky in at least some systems. I couldn't find a single one. CentOS 5, Debian, FreeBSD 6.2, Solaris 10 none have it sticky by default.
All our Debian Sarge and Etch systems (with Sendmail and procmail packages) have /var/mail sticky by default, we didn't modify it ourselves.
My test Debian image came from debian-40r1-amd64-businesscard.iso and it had no MTA installed. After installing Exim /var/mail still wasn't sticky. After installing sendmail-bin it got sticky.
At 3:35 PM +0100 3/4/08, Edgar Fuß wrote:
Anyway I also thought that /var/mail would be sticky in at least some systems. I couldn't find a single one. CentOS 5, Debian, FreeBSD 6.2, Solaris 10 none have it sticky by default. It seems to be sticky on NetBSD.
Whether a directory used for system mboxes (sometimes /var/mail, sometimes /var/spool/mail, sometimes /usr/spool/mail *EWWW* ) needs to be 1777 or 0775 or Something Else is a function of what sort of LDA(s) and MUA(s) and mailstore server(s) need to access it and what some admin has done in the past to make it work.
The core problem is that anything changing mailboxes there probably needs to be able to create and delete both mailbox files and lockfiles there, so either you need to have a bunch of well-vetted setgid software or you need to use a 1777 or 3777 mail spool.
The best alternative would be a working mandatory lock system in the OS and good gatekeeping on the creation and deletion of mboxes, but that's not a combination that multi-platform software can count on...
-- Bill Cole bill@scconsult.com
Hi,
It seems to me that many versions of Debian (where /var/mail is root:mail 2775) are vulnerable.
Timo Sirainen wrote :
a) Upgrade to v1.0.11 and use the new mail_privileged_group setting instead of mail_extra_groups.
We tried this but now the mail.log has a number of lines : « dovecot: IMAP(someuser): open(/var/mail/.temp.XXXX) failed: Permission denied »
This with mail_location: mbox:~/Mail:INBOX=/var/mail/%u and no specific settings for mbox_*_locks.
mail_privileged_group setting works by keeping the group in process's saved GID while it's not in use and temporarily switching it to effective GID while dotlocks are created. Currently this is done only when:
It's only done for INBOX mbox which doesn't exist under the same location as other mailboxes (so typically under /var/mail).
It's used only after initial dotlock creation try failed with EACCES error.
This might be the explanation, but is there any way to avoid the logs to get flooded ?
Cheers,
Jeremie
On Tue, 2008-03-04 at 17:31 +0100, Jérémie Bouttier wrote:
a) Upgrade to v1.0.11 and use the new mail_privileged_group setting instead of mail_extra_groups.
We tried this but now the mail.log has a number of lines : « dovecot: IMAP(someuser): open(/var/mail/.temp.XXXX) failed: Permission denied »
Oh, this is actually harmless. You can get rid of it (and improve the performance) by setting dotlock_use_excl=yes.
But maybe I should release v1.0.12 anyway with that error message silenced..
On Wed, 2008-03-05 at 00:29 +0200, Timo Sirainen wrote:
a) Upgrade to v1.0.11 and use the new mail_privileged_group setting instead of mail_extra_groups.
We tried this but now the mail.log has a number of lines : « dovecot: IMAP(someuser): open(/var/mail/.temp.XXXX) failed: Permission denied »
Oh, this is actually harmless. You can get rid of it (and improve the performance) by setting dotlock_use_excl=yes.
But maybe I should release v1.0.12 anyway with that error message silenced..
You mean seeing that error message only is actually not an error, because the next locking method just works?
In that case, great -- I'll go change dotlock_use_excl, revert the scary option (b) of chmod world-writable, and see how it works out. Not using NFS anyway.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i
On Tue, 2008-03-04 at 23:41 +0100, Karsten Bräckelmann wrote:
On Wed, 2008-03-05 at 00:29 +0200, Timo Sirainen wrote:
a) Upgrade to v1.0.11 and use the new mail_privileged_group setting instead of mail_extra_groups.
We tried this but now the mail.log has a number of lines : « dovecot: IMAP(someuser): open(/var/mail/.temp.XXXX) failed: Permission denied »
Oh, this is actually harmless. You can get rid of it (and improve the performance) by setting dotlock_use_excl=yes.
But maybe I should release v1.0.12 anyway with that error message silenced..
You mean seeing that error message only is actually not an error, because the next locking method just works?
Right. Also fixed it now: http://hg.dovecot.org/dovecot-1.0/rev/a9ac53bc191b
In that case, great -- I'll go change dotlock_use_excl, revert the scary option (b) of chmod world-writable, and see how it works out. Not using NFS anyway.
dotlock_use_excl=yes works also in all modern NFS systems. I doubt anyone is still using NFSv2. This setting is now default in v1.1.
On Tue, 2008-03-04 at 23:41 +0100, Karsten Bräckelmann wrote:
On Wed, 2008-03-05 at 00:29 +0200, Timo Sirainen wrote:
Oh, this is actually harmless. You can get rid of it (and improve the performance) by setting dotlock_use_excl=yes.
But maybe I should release v1.0.12 anyway with that error message silenced..
You mean seeing that error message only is actually not an error, because the next locking method just works?
In that case, great -- I'll go change dotlock_use_excl, revert the scary option (b) of chmod world-writable, and see how it works out. Not using NFS anyway.
Seems it did the trick, judging by some quick tests. :)
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i
On Tue, 2008-03-04 at 08:35 +0200, Timo Sirainen wrote:
mail_extra_groups=mail setting is often used insecurely to give Dovecot access to create dotlocks to /var/mail directory. If you don't use mboxes in /var/mail, make sure this setting is cleared.
If you do use /var/mail mboxes and Dovecot gives permission errors without it, do one of the following (in the preferred order):
Yup, still using /var/mail mboxes. A fact I didn't get around to change yet.
a) Upgrade to v1.0.11 and use the new mail_privileged_group setting instead of mail_extra_groups.
Just did so on my personal, local IMAP server, and now I get these:
# tail -n 1 /var/log/mail/errors Mar 4 19:13:32 delta dovecot: IMAP(guenther): open(/var/spool/mail/.temp.delta.32268.d6ed77a67d018ba9) failed: Permission denied
# ls -ld /var/mail /var/spool/mail lrwxrwxrwx 1 root root 10 Mar 27 2007 /var/mail -> spool/mail/ drwxrwsr-t 2 root mail 1024 Mar 4 19:17 /var/spool/mail/
b) Make /var/mail sticky and world-writable (chmod 01777 /var/mail) and clear mail_extra_groups setting.
Yeah, 'chmod o+w /var/spool/mail' worked around the permission errors for now. But this shouldn't be necessary, right?
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i
participants (7)
-
Benoit Branciard
-
Bill Cole
-
Edgar Fuß
-
Jérémie Bouttier
-
Karsten Bräckelmann
-
Odhiambo Washington
-
Timo Sirainen