Bugtraq mailing list archives
Re: Mail delivery privileges
From: Henrik Nordstrom <hno () hem passagen se>
Date: Sat, 19 May 2001 22:10:46 +0200
What is required is that delivery runs as the user the delivery is for when running custom programs via .forward or another mechanism. The rest of the mail transfer however does not need to run as root for this to be possible. For systems not requiring mail delivery to user programs then the mail delivery may well be set up to not require any special per-user privilegies, but then you will need special user-agent privilegies in order to access the mail spool, which practically limits this approach to POP/IMAP environments only as the varity of mail user-agents are much broader and most likely harder to secure than the mail delivery process... if any of the user-agents which has been given mail privilegies are insecure then your users will be able to mess around with each others email freely, and most likely mess around with other aspects your delivery agent as well. To do SMTP mail deliery securely the SMTP agent and mail delivery agent needs to be separated with a well defined and secure interface. Such a interface is not a terribly hard thing to define and can even be done in Sendmail if you like. The mail delivery agent is then responsible for assuming the identity of the user, and deliver the mail to him (spool file or via .forward), but does not know anything else than mail delivery to that user. -- Henrik Nordstrom Peter W wrote:
To protect users from each others' ~/.forward instructions, it is necessary, as Wietse said, for the delivery agent to start with superuser privileges. There are ways to make things a little bit safer, e.g. have the delivery agent drop privileges to nobody:bobpipe (where only bob is a member of bobpipe) instead of bob:users when running the ~/.forward command, but that only protects bob from his own mistakes in ~/.forward and still leaves the delivery agent starting out with superuser privs... -Peter
Current thread:
- MUAs that delete spoolfiles (was Solaris /usr/bin/mailx exploit (SPARC)), (continued)
- 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: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Wietse Venema (May 19)