Nasty Security Hole?

[Greg Woods]

In article <850 at sceard.UUCP> mrm at sceard.UUCP (0040-M.R.Murphy) writes:
>In article <14466 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>|In article <175 at ernie.NECAM.COM> peter at ernie.NECAM.COM (Peter DiPrete) writes:
>|>... the mail directory has liberal permissions.  I even tried various
>|>combinations of set{gu}id and sticky bits on the directory.
>|
>|The sticky bit on the directory is intended to fix that.  Alas, it is
>|broken in the NFS implementations you mentioned.
>
>Note the ownerships, stickies, and permissions.
>drwxrwxr-x   2 root     mail         256 Nov 10 10:21 /usr/mail
>-rwxr-sr-x   1 bin      mail       25066 Oct 26  1985 /bin/lmail
>-rwxr-sr-x   1 bin      mail       15000 Feb 17  1988 /bin/mail
>-rwxr-sr-x   2 bin      mail       42292 Feb 17  1988 /bin/rmail
>-rwxr-sr-x   2 bin      mail       42292 Feb 17  1988 /bin/smail
>-rwxr-sr-x   1 bin      mail       99306 Oct 27  1985 /usr/bin/mailx
>Happens to be smail2.5, but the principles are the same with other
>mailers.

I doubt you need set-group-id on mailx, since it only manipulates the
user's own mailbox.  Making it set-gid will allow anyone to read or
write all system mailboxes.  I've also found that no implementation of
mailx or BSD Mail (that I've used) bothers to reset real uid and gid
when spawning a sub-process, at least not when sending mail.

If, for some reason, you find it necessary to have mailx delete empty
mailboxes, and you aren't running a version of mailx which has a set-gid
programme, usually called rmmail, for doing so, you should probably
write one, and teach your users to use it, instead of making mailx set-gid.

In general, use the K.I.S.S. principle with set-Xid programmes.
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!ontmoh!woods, lsuc!gate!woods
VOICE: (416)443-1734 [h], (416)595-5425 [w]  LOCATION: Toronto, Ontario, Canada