[ On Tuesday, May 15, 2001 at 14:47:02 (-0700), Tobias J. Kreidl wrote: ] > Subject: Re: Solaris /usr/bin/mailx exploit (SPARC) > > Andrew Hilborne <andrew.hilborneat_private> wrote on > Tue, 15 May 2001 14:15:45 +0100: > > > > Just how do you force 0600 on mailboxes which don't exist (many MUAs > > remove empty mailboxes?) > > > > Since you cannot easily do this, at the very least a malicious user > > should be able to steal other users' mail. I think. > > 1) The permissions 1777 on /var/mail should allow empty mailboxes to > remain under most circumstances. One should be careful what > IMAP and POP services are running on your machine and how > they handle this. > > 2) When a new user account is first established, it is imperative that > a mailbox be created at that time with the proper ownerships and file > permissions. > > 3) A cron job can help monitor any discrepancies between existing and > desired file attributes of mailboxes in /var/mail and rectify them on > the fly. That's all true, in so far as it goes, but it does leave the system open to far more risk than is necessary in that the local delivery agent must still run as root. Having implemented what I hope to be a secure and portable fopen_as_user() function I can assure you that even the apparently simple job of doing local delivery from a privileged position isn't really all that simple at all. If the calling process isn't expecting to exit within such a function then you have to fork() and with careful error checking and few comments the resulting code is well over 200 lines long! Indeed if you're going to go to all the trouble of pre-creating mailboxes and ensuring that empty ones are left behind by all mail reading agents then it's trivial to implement setgid-mail delivery on even systems which don't allow ordinary users to use chown(2). I.e. it's trivial, even on such systems, to avoid having to use root privileges in any part of the local mail system! In my estimation the risk resulting from a successfull group-ID "mail" compromise is still almost infinitely less than the risk of a root compromise, regardless of what the system involved is used for! -- 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 : Thu May 17 2001 - 00:01:47 PDT