Bug 62738 - permissions of /var/spool/mail are insecure
permissions of /var/spool/mail are insecure
Product: Red Hat Linux
Classification: Retired
Component: filesystem (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Aaron Brown
: Security
Depends On:
  Show dependency treegraph
Reported: 2002-04-04 20:44 EST by Need Real Name
Modified: 2014-03-16 22:26 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-09 01:11:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-04-04 20:44:54 EST
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@redhat.com 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:

Steps to Reproduce:
1. install red hat

Actual Results:

Expected Results:

Additional Information:
Comment 1 Need Real Name 2002-04-09 01:11:49 EDT
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@op.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.
Comment 2 Bill Nottingham 2002-06-12 01:32:56 EDT
- 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.
Comment 3 Peter Bieringer 2002-10-29 05:17:28 EST
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

Change permissions 
/var/spool/mail -> 1775
+ postinstall chgrp mail /var/spool/*
Package: filesystem

Fix imap sources by a new patch to check for 1775 instead of 1777

Comment 4 Peter Bieringer 2002-10-29 06:02:53 EST
Ooops, previous shown fix was wrong because of a by log message confused person, sorry - me ;-)

Fixed fix:

 Change permissions 
 /var/spool/mail -> 2775
 + postinstall chgrp mail /var/spool/*
 Package: filesystem

 Fix imap sources by a new patch to check for 2775 instead of 1777
Comment 5 Peter Bieringer 2002-10-29 14:47:00 EST
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.
Comment 6 Peter Bieringer 2002-10-29 15:09:15 EST
Ah, now I found the bug which causes my confusion:

it's useradd, which currently creates the initial mbox file with

0660 user:group


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

Note You need to log in before you can comment on or make changes to this bug.