Bugzilla Bug 16749

Package: mailbase-0.00-r5

searching for problems in gnu-pop3d (not from Gentoo - mailbox stays
locked after fetch), I found following local DOS, introduced in
mailbase-0.00-r5.ebuild (marked as fix of #8029). There were clean
discussion for this bug, but fix is bad (typo?):

fperms 1777 /var/spool/mail

There is simple code, which can lock all active mail accounts:

cd /var/spool/mail
for i in * ; do touch $i.lock ; done

Basically 1777 is illegal permissions for /var/spool/mail.

There are two legal setups for this directory, which can be found in
other UNIX systems:

755 root any_group
Only root and setuid root binaries can access mail locks (not
recommended because setuid root)

775 root mail
Only root and setgid mail binaries can access mail locks

Second one is more secure, because apps don't need root permissions.

Most applications can succeed with both upper mentioned schemes (and
also 1777) and have autodetection of proper mode (except 1777) and use
helpers for lock access (for example mutt_dotlock).

Sticky flag is not OK - 1777 it can cause also other problems, not only DOS attacks.
For example, there is a GNU pop3d locking algorithm:
create lock (as root/mail)
setuid user
remove lock (as user/mail) - EPERM

Created an attachment (id=8903) [details]
mailbase.diff

This patch fixes permission to wise value.

raker: Do you see any problems with changing the mode on /var/spool/mail? 

Please look at discussion of bug 8029. Comment #1 from azarah@gentoo.org
recommends 775, not 1777. I think, that changing permissions to 1777 was a
mistake.

fixed in -r6 

This just went stable, and I'm seeing this from pine:

        [Folder vulnerable - directory /var/spool/mail must have 1777       protection]

Is there a bug in pine, does it just need recompilation, or what?  It seems to work, regardless.

Danek : you should post a new bug for the PINE warning. As far as this bug is
concerned everything is now ok. I have no clue why PINE complains about the new
perms... but net-mail people might have an idea.

I filed bug 74847 for this problem.

Perhaps up and changing the perms on /var/spool/mail without verifying that the
clients didn't break wasn't such a great idea...  Yes, someone can DoS mail
readers by creating .lock files in the mail spool, but that someone is very
easy to hunt down and kneecap as their UID is all over the files.

As for the gnu-pop3d problem, that's arguably a bug in their code.  They should
drop perms before creating the lock file.

I'm not advocating a 1777 mailspool, just pointing out that you can't
arbitrarily change the perms and expect all the sundry mail clients to be okay
with it.

I just upgraded to -r6 yesterday and this messed mutt up.  Before finding this
bug I changed the permissions back to 777 and things just worked.

The problem was that mutt believed the inbox was readonly and I couldn't toggle
it to write.  Since I owned the file in /var/spool/mail and could modify it,
I'm not sure exactly what the problem was.

I believe this breaks Postfix. 

Postfix delivers mail with the privileges of the recipient email. This, for email to be delivered to a new user, the new user must be in the "mail" group. If all users are in the "mail" group, then the DOS attack can still be performed. 

Postfix does NOT use a setgid mail binary to deliver email. It drops privileges to that of the recipient user.