Description of Problem: Item 1: /var/spool/mail should have the sticky bit set. Without the sticky bit set, anyone who compromises any of the mail utilities (imapd, pop[23]d, 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. Item 2: I will also argue that contrary to what alan says in bug #10678, the spool directory should also be writable by "other" and the imapd and ipop[23]d 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 How Reproducible: invariable Steps to Reproduce: 1. install red hat 2. 3. Actual Results: Expected Results: Additional Information:
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 peter.hunter 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 total 208 -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[11003]: Mailbox vulnerable - directory /var/spool/mail must have 1777 protection All this can be fixed by 1) Change permissions /var/spool/mail -> 1775 + postinstall chgrp mail /var/spool/* Package: filesystem 2) Fix imap sources by a new patch to check for 1775 instead of 1777 src/osdep/unix/env_unix.c Comments?
Ooops, previous shown fix was wrong because of a by log message confused person, sorry - me ;-) Fixed fix: 1) Change permissions /var/spool/mail -> 2775 + postinstall chgrp mail /var/spool/* Package: filesystem 2) Fix imap sources by a new patch to check for 2775 instead of 1777 src/osdep/unix/env_unix.c
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 0660 user:group https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75418 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...