Nasty Security Hole?
Greg Woods
woods at gpu.utcs.toronto.edu
Mon Nov 14 10:20:03 AEST 1988
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
More information about the Comp.unix.wizards
mailing list