Bugtraq mailing list archives
Re: Mail delivery privileges
From: Peter W <peterw () usa net>
Date: Fri, 18 May 2001 21:04:37 -0400
On Fri, May 18, 2001 at 04:35:08PM -0400, Greg A. Woods wrote:
[ On Friday, May 18, 2001 at 11:18:51 (-0400), Wietse Venema wrote: ]
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.
Personally I'm loathe to allow ordinary users to specify delivery to programs in the first place, and forcing them at minimum to arrange for their mail filters to run unprivileged seems like a very small price
That's certainly the way it works on Plan 9:
If the file /mail/box/username/pipeto exists and is read- able and executable by everyone, it will be run for each incoming message for the user. The message will be piped to it rather than appended to his/her mail box. The file is run as user `none'.
So users with "pipeto" scripts are vulnerable to other users' "pipeto" scripts, since they all run as the same user. "Mutual Assured Corruption" you might say. I think that sounds like a *large* price to pay!
Note that there are solutions to the filtering issue which do not require the final destination of filtered messages to be an inbox that's writable by the unprivileged user (eg. just pass them back to the mail system for re-delivery to a new mailbox).
Your earlier post assumed that users didn't want to use ~/.forward to specify custom actions. Now you're assuming all the user wants to do is "filter" the mail, i.e., decide which mailbox to put it in. But users want to do more with their mail than simply "filter" it. 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:
- Re: Solaris /usr/bin/mailx exploit (SPARC), (continued)
- 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) Andrew Hilborne (May 15)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Wietse Venema (May 19)