[ On Friday, May 18, 2001 at 11:18:51 (-0400), Wietse Venema wrote: ] > Subject: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) > > 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. There is no longer any need for "*.lock" files on any machine out there which has POSIX-compliant (or similar) advisory file locking functions. Dot-lock files are an artifact of the past and they should be eliminated since they do indeed require enhanced privileges to implement. There is no need to use an insecure world-writable spool directory, though of course if you don't want the spool directory to be group writable by group "mail" then you do have to pre-create all mailboxes. (I'm not sure if there's any less risk to having a non-writable spool directory, but if your "useradd" (or whatever) program takes care of creating mailboxes too then it can't hurt.) Advisory file locking is obviously sufficient to protect the spool files from corruption by simultaneous access by any number of co-operating programs, including both multiple mail reader programs and of course any local delivery agent(s). After all that's all you've got with "*.lock" files, since they too are only advisory locks. Putting them into the kernel simply makes it possible to eliminate the risk of a mode 01777 spool directory. (The risk is already quite low of course if you pre-create all mailbox spool files, and especially if you write careful lock validation code in the local delivery agent. Kernel locks simply make the code for safe local delivery less complex.) Note that this isn't necessarily as big a headache for users of third-party e-mail software (particularly MUAs) as one might think. Most I've encountered do something approximating "The Right Thing" when they are unable to create a "*.lock" file. The only real issue that remains is that of dealing with third-party software that thinks it's smarter than you and installs itself setgid-mail anyway. About the only thing an OS vendor can do in that case is to paint a big red warning sign and hold it up in front of the admin so that he/she can't miss it. (and of course paste the standard "no warranty" disclaimer in fine print on the bottom of it!) > 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. Oh, OK, you've got me on that one! ;-) I was trying very carefully to avoid that particular pit of snakes, but I suppose I should have known it was inevitable that someone would find me out eventually! Indeed that's the one reason why I haven't yet released a version of Smail-3 that runs without root privileges all of the time. (and now, as a famous USA radio announcer says, you know the rest of the story! :-) 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 to pay. I seem to recall this was the solution taken by the AT&T UPAS mailer delivered as the default mailer on native UNIX System V Release 4. That's certainly the way it works on Plan 9: Filtering 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'. 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). Setting it up generically for every user's primary mail account takes some thought, but it can be done. Of course a mail storage system such as Cyrus IMAP can facilitate this much more readily, though it doesn't have to since it now has built-in, user-controllable, presumably secure, filtering. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoodsat_private> <woodsat_private> Planix, Inc. <woodsat_private>; Secrets of the Weird <woodsat_private>
This archive was generated by hypermail 2b30 : Fri May 18 2001 - 17:41:55 PDT