non-superuser chown(2)s considered harmful

[Rahul Dhesi]

In <1990Dec14.150710.4273 at mp.cs.niu.edu> rickert at mp.cs.niu.edu (Neil
Rickert) writes:

> cd /usr/spool/mail
> touch dhesi
> chmod 777 dhesi

> Now I own your mail box.

I believe this problem was fixed going from 4.2BSD to 4.3BSD;  if
I remember correctly, the mail delivery program forces the mailbox
to be owned by the user and not readable or writable by anybody else.
If it doesn't, or if I'm remembering incorrectly, the security problem
is in the mail delivery program, *not* with the fact that the mail
directory itself is world-writable.  We are assuming, of course, that
the sticky bit is set on the mail directory.

When there is a security problem caused by the combination of two
things (e.g., 1. mail directory world-writable, 2. mail delivery
program doesn't force mailbox security) one can't blame a lack of
security on just one of those things

The main problem with keeping mail directories world-not-writable and
keeping mail user agents set-gid is that it becomes harder for Joe user
to install his own user agent without the cooperation of the system
administrator.  You should not need any sysadmin support to read your
own mail.

I will grant you that a denial-of-service situation is still possible
by simply going to the mail directory and creating a file $USER.lock,
thus fooling all other mail programs into thinking that the mailbox is
locked.  The solution is for the mail delivery program to either not
use this locking scheme (use flock instead), or to force an unlock if
the lock file is too old.

Actually, if everybody used flock, then you wouldn't need to make mail
user agents set-gid, because they would never have to create any new
files in the mail directory.  Unfortunately, even our our super modern
Suns, the default mail program uses a $USER.lock file, and I wouldn't
be surprised if this is true on may other UNIX derivatives.
--
Rahul Dhesi <dhesi%cirrusl at oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi