Bugtraq mailing list archives

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


From: wietse () porcupine org (Wietse Venema)
Date: Fri, 18 May 2001 11:18:51 -0400 (EDT)

Greg A. Woods:
The actual delivery need only run as "nobody:mail".  Period.  End of story.
[...]
In any case there's no need to lose any features whatsoever.  Secure
local mail delivery is entirely practical and very achievable.

Local mail delivery crosses the mail-to-user boundary in several
places. Assuming traditional UNIX user/group/other permissions and
uid/gid-based privileges, and the traditional /var/mail, aliases
and .forward interface with user-specified shell commands:

1 - Appending mail to mailbox. This can be done securely by
nobody:mail provided that the mailbox has group write permission.
But that is only the easy part.

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.

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.

I agree with Mr. Woods on the challenge of implementing functionality
securely without loss of features.  However, nobody:mail delivery
privileges alone are not sufficient to implement a widely-used
mail-to-user interface on systems with traditional user/group/other
permissions and uid/gid-based privileges. One needs to apply
additional privileges or accept the loss of functionality.

All the more reason to use a different mail-to-user interface.

        Wietse


Current thread: