Date: Fri, 18 May 2001 11:18:51 -0400 (EDT)
From: (Wietse Venema) <[email protected]>
To: [email protected]Subject: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)
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
