[ On Thursday, May 17, 2001 at 12:24:41 (+0200), Casper Dik wrote: ] > Subject: Re: Solaris /usr/bin/mailx exploit (SPARC) > > Dependign on which loss of features you're willing to accept, it's > usually not practical to run mail delivery as a non-privileged user; > currently, we need to do deliver as superuser because of the > actual delivery runs as the destination user. The actual delivery need only run as "nobody:mail". Period. End of story. The only trick is that if you're running the queue cleaner (or all of sendmail, in your case) as root then you have to make sure that you don't get fooled into not discarding your privileges when running a setgid binary -- you'll have to first have sendmail do setgid(nobody);setuid(nobody) before it exec's the LDA. In any case there's no need to lose any features whatsoever. Secure local mail delivery is entirely practical and very achievable. In reality there's not even any need to run sendmail as root -- the SMTP daemon should always be started as root, of course, but it can easily permanently discard all privileges once it's got a socket open and bound for listening to port-25. > If you don't run delivery as the targeted user, you can have unrestricted s/can/must/? > .forward files (those are a risk in themselves but tools like procmail > cannot easily be run under an unprivilegd accoutn on behalf of a user. If ~/.forward files are supported on any given system then they do have to be at readable by at least the group 'mail', but they don't have to be completely unrestricted. (on *BSD they would have to be, but not SysV-based system I think, at least not if _POSIX_CHOWN_RESTRICTED isn't in effect.) Either way of course it implies that the user's home directory must also be at least searchable by everyone too. You can put .forward files into some other place, of course -- they don't have to be in $HOME.... Doing so even eliminates many problems when $HOME is on an NFS server (from the mailer's point of view)! I don't think that allowing group mail to read .forward files is too much to ask for, and it certainly doesn't mean you have to drop support for user-controllable e-mail forwarding. It is after all the difference between living with the risk of a total system compromise, and not. (Yes, this thread started with a group-mail compromise, but the reason that happened was because group-mail configuration wasn't done correctly in the first place.) Of course there's still the issue of coding access to these files safely so that the user can't trick the delivery agent into reading someone else's mailbox (the only other files that should be private but still readable by the group 'mail'), but that's much easier to do with just setgid-mail privs than it is to do with root privileges. I'll bet you could even easily dig out the old SysV code which supports putting "Forward to" in the user's mailbox! That scheme requires no access to home directories and no new directories, and it can't be fooled by symlinks (provided you secure /var/mail itself, of course). Maybe it's even there still in the Solaris mail system -- it wouldn't surprise me if it were. > AS things stand today, there doesn't seem to be any reason to continue > the use of set-gid mail in Solaris, except that some code changes will be > necessary (or mailboxes will be created mode 660, group pwd->pw_gid That is true. If you're going to risk running local delivery as the superuser then you don't have to use any setgid-mail stuff. Pick your poison. Regardless there should no longer be any reason for enhanced privileges of any kind on any mail reader program. (There never was in the first place, in so far as Solaris is concerned.) Please don't make excuses for a broken system. Please fix it! Please do your best to avoid potential new problems too, and don't just paper over them -- learn from history! -- 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 - 00:26:04 PDT