Description of Problem:
/var/spool/mail should have the sticky bit set. Without the sticky bit set,
anyone who compromises any of the mail utilities (imapd, popd, procmail,
etc.) or otherwise gains the permissions of the mail group can delete any and
all files in the mail spool. With the sticky bit set, this is not possible.
I will also argue that contrary to what email@example.com says in bug #10678,
the spool directory should also be writable by "other" and the imapd and
ipopd daemons should NOT be SGID mail. They were not written to run with
privileges, the UW team specifically SAYS they're not designed to run with
privileges, and by not configuring the spool to be 1777 you are potentially
opening up any system that uses these daemons (i.e. virtually any mail server
that runs on Red Hat) up to potential vulnerabilities that could at least gain
the attacker the ability to wipe out the mail queue.
I will post this to bugtraq in one week if you neither fix the problem nor at
least make some attempt to explain the rationale behind not using those permissions.
Version-Release number of selected component (if applicable):
All versions of red hat that I looked at
Steps to Reproduce:
1. install red hat
Note with regard to item 2: the imapd and ipop3d daemons are not SGID on any
system that I looked at, I was referring to the spool directory being 755 on
every system I looked at.
Since all mail delivery programs currently start with root privileges anyway, if
the spool directory is 1777, then all mail programs can suid() to the user of
whom they are running on behalf as soon as that is determined and any
authentication required is performed, and need not operate with *any*
priviledges from that point on. User agents need not do this, as they will of
course already be running with the priviledges of the user and can create files
as necessary. Files in the spool should have 0600 permissions, unless the
user/management/whatever agrees otherwise.
WRT a comment made by firstname.lastname@example.org in bug #10678, yes, it's true that
someone can create a hard link to someone else's mail spool; however the hard
link retains the priviledges of the original file (both user and permissions)
and can not be accessed in any way besides that which the original file could
be. Personally, I think the link() system call should fail if the file being
linked is not owned by the user calling it, or if the user isn't root. I can't
think of a good reason to allow this... but that's a side issue.
Though no one commented on this, it's also true that you could have a user fill
up the filesystem by creating files in the spool, but he can already do that by
appending junk to his own spool (assuming it already exists, which generally
will be the case). This problem is better solved by quota and/or policy (i.e.
warn the guy once, and fire his ass or delete his account if he does it again).
Neither of these problems are as severe as someone either accidentally or
deliberately gaining mail group privileges and deleting the spool or parts of it.
- world writable directories allow for easy DoS attacks, both against the system
and against other users
- the current setup does not prohibit a 'sane' IMAP daemon, etc.
from writing to the spool, assuming the mail file exists.
Hmm, ran into the same problem on a postfix/imap box on RHL 7.3 (tested on 7.2 as well) using imap-2001a-10 src rpm
/var/spool/mail has 0775
Postfix delivers e-mails into mbox created with permission 0660
$ ll /var/spool/mail
-rw-rw---- 1 peter users 2617 Oct 24 15:06 peter
Unlike the standard RHL setup, the primary group of each user is "users"
So this is not nice, because others belonging to group "users" can read now other's mailboxes.
Also following logline appears
Oct 29 10:51:57 gate ipop3d: Mailbox vulnerable - directory /var/spool/mail must have 1777 protection
All this can be fixed by
/var/spool/mail -> 1775
+ postinstall chgrp mail /var/spool/*
Fix imap sources by a new patch to check for 1775 instead of 1777
Ooops, previous shown fix was wrong because of a by log message confused person, sorry - me ;-)
/var/spool/mail -> 2775
+ postinstall chgrp mail /var/spool/*
Fix imap sources by a new patch to check for 2775 instead of 1777
imapd needs no longer to be fixed, looks like imapd-2001a-10 sources have a
problem with the "boguswarning" patch, because on imapd-2001a-15 sources,
message is gone.
Ah, now I found the bug which causes my confusion:
it's useradd, which currently creates the initial mbox file with
chmod g+s /var/spool/mail doesn't help here
Also postfix creates a new mbox with 0600
Forgive about adding comments to bugs before extensive testing and bughunting.
BTW to the maintainer: you can delete all of my postings...