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:
- Re: Solaris /usr/bin/mailx exploit (SPARC), (continued)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Johann Klasek (May 15)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 16)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Andrew Hilborne (May 15)
- MUAs that delete spoolfiles (was Solaris /usr/bin/mailx exploit (SPARC)) Rich Lafferty (May 16)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 15)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Dan Astoorian (May 15)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Tobias J. Kreidl (May 16)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 17)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Casper Dik (May 17)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 18)
- Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Wietse Venema (May 18)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Greg A. Woods (May 18)
- Re: Mail delivery privileges Peter W (May 19)
- Re: Mail delivery privileges Henrik Nordstrom (May 19)
- Re: Mail delivery privileges David Wagner (May 21)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Cy Schubert - ITSD Open Systems Group (May 19)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 17)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Olaf Kirch (May 18)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Dan Stromberg (May 19)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Johann Klasek (May 15)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Wietse Venema (May 19)