Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)

[woods () weird com (Greg A. Woods)]

[ On Friday, May 18, 2001 at 11:18:51 (-0400), Wietse Venema wrote: ]
> Subject: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)
>
> 2 - Lock file management. If mail is delivered as nobody:mail, then
> /var/mail/username.lock files are owned by user nobody.  This means
> you can't use mode 1777 /var/mail permissions (a user would not be
> able to remove a stale username.lock file left behind by the mail
> system and vice versa).  Instead, /var/mail must be mode 770 group
> mail, and mail user agents need SET-GID mail privileges in order
> to remove stale username.lock files.  The privileges are needed
> either by the MUA itself or by an MUA helper program.  The alternative,
> unrestricted /var/mail directory write permission, is not secure.

There is no longer any need for "*.lock" files on any machine out there
which has POSIX-compliant (or similar) advisory file locking functions.
Dot-lock files are an artifact of the past and they should be eliminated
since they do indeed require enhanced privileges to implement.  There is
no need to use an insecure world-writable spool directory, though of
course if you don't want the spool directory to be group writable by
group "mail" then you do have to pre-create all mailboxes.  (I'm not
sure if there's any less risk to having a non-writable spool directory,
but if your "useradd" (or whatever) program takes care of creating
mailboxes too then it can't hurt.)

Advisory file locking is obviously sufficient to protect the spool files
from corruption by simultaneous access by any number of co-operating
programs, including both multiple mail reader programs and of course any
local delivery agent(s).  After all that's all you've got with "*.lock"
files, since they too are only advisory locks.  Putting them into the
kernel simply makes it possible to eliminate the risk of a mode 01777
spool directory.  (The risk is already quite low of course if you
pre-create all mailbox spool files, and especially if you write careful
lock validation code in the local delivery agent.  Kernel locks simply
make the code for safe local delivery less complex.)

Note that this isn't necessarily as big a headache for users of
third-party e-mail software (particularly MUAs) as one might think.
Most I've encountered do something approximating "The Right Thing" when
they are unable to create a "*.lock" file.  The only real issue that
remains is that of dealing with third-party software that thinks it's
smarter than you and installs itself setgid-mail anyway.  About the only
thing an OS vendor can do in that case is to paint a big red warning
sign and hold it up in front of the admin so that he/she can't miss it.
(and of course paste the standard "no warranty" disclaimer in fine print
on the bottom of it!)

> 3 - User-specified shell commands. Traditionally, a user can specify
> any shell command in ~user/.forward, and that command will execute
> with the privileges of that user. This requires SUPER-USER privileges
> in the mail delivery software itself or in mail helper software.

Oh, OK, you've got me on that one!  ;-)

I was trying very carefully to avoid that particular pit of snakes, but
I suppose I should have known it was inevitable that someone would find
me out eventually!

Indeed that's the one reason why I haven't yet released a version of
Smail-3 that runs without root privileges all of the time.  (and now, as
a famous USA radio announcer says, you know the rest of the story! :-)

Personally I'm loathe to allow ordinary users to specify delivery to
programs in the first place, and forcing them at minimum to arrange for
their mail filters to run unprivileged seems like a very small price to
pay.  I seem to recall this was the solution taken by the AT&T UPAS
mailer delivered as the default mailer on native UNIX System V Release 4.
That's certainly the way it works on Plan 9:

   Filtering
       If  the file /mail/box/username/pipeto exists and is read-
       able and executable by everyone, it will be run  for  each
       incoming  message for the user.  The message will be piped
       to it rather than appended to his/her mail box.  The  file
       is run as user `none'.

Note that there are solutions to the filtering issue which do not
require the final destination of filtered messages to be an inbox that's
writable by the unprivileged user (eg. just pass them back to the mail
system for re-delivery to a new mailbox).  Setting it up generically for
every user's primary mail account takes some thought, but it can be
done.  Of course a mail storage system such as Cyrus IMAP can facilitate
this much more readily, though it doesn't have to since it now has
built-in, user-controllable, presumably secure, filtering.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>     <woods () robohack ca>
Planix, Inc. <woods () planix com>;   Secrets of the Weird <woods () weird com>