[20720] in bugtraq
Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)
daemon@ATHENA.MIT.EDU (Wietse Venema)
Sat May 19 16:53:52 2001
In-Reply-To: <20010518151851.93FBABC074@spike.porcupine.org> "from Wietse Venema
at May 18, 2001 11:18:51 am"
To: bugtraq@securityfocus.com
Date: Fri, 18 May 2001 20:10:48 -0400 (EDT)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20010519001048.C0E75BC06F@spike.porcupine.org>
From: wietse@porcupine.org (Wietse Venema)
I wrote:
> 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 [...]
Several people pointed out that username.lock files can be eliminated
from the equation. That may be the case on their specific systems.
However, many systems in the real world do require username.lock
files as part of their local mail delivery interface. Simply
calling those systems "obsolete" does not make them go away.
Some suggested changes to the the mail-to-user interface. That
interface can certainly stand improvement. However, such comments
are outside the scope of the argument: whether or not unprivileged
local delivery as nobody:mail provides security without loss of
features.
In a world that requires username.lock files, one would have to
cheat and use privileged mail user agents. In a world that expects
that people can specify arbitrary shell commands in ~user/.forward
files, one would have to cheat and use privileged helper programs.
Wietse
