Dovecot news - Mar 2008 - 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:

1. It's only done for INBOX mbox which doesn't exist under the same
location as other mailboxes (so typically under /var/mail).

2. It's used only after initial dotlock creation try failed with EACCES
error.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080304/08951e10/attachment-0002.bin>

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. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080304/61a90278/attachment-0002.bin>

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:
> 
> 1. It's only done for INBOX mbox which doesn't exist under the same
> location as other mailboxes (so typically under /var/mail).
> 
> 2. 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.

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:
> 
> 1. It's only done for INBOX mbox which doesn't exist under the same
> location as other mailboxes (so typically under /var/mail).
> 
> 2. 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 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. at
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<l;i++){ i%8?
c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){
putchar(t[s]);h=m;s=0; }}}