mann%Shasta%su-score@sri-unix.UUCP (06/08/83)
From: Tim Mann <mann%Shasta@su-score> Making Berkeley 4.1 /bin/mail setuid to root creates a gaping security hole, because /bin/mail allows you to mail to files. This is true in spite of the fact that Berkeley's MAKE script makes it setuid to root. The only safe (?) way I know of to set things up is to create a special "mail" group, make /bin/mail setgid to this group, and arrange for the mail spool directory and mail files to be group-writeable. --Tim
pag@hao.UUCP (06/09/83)
Tim Mann complained about security gaps in having /bin/mail setuid
root. He proposed the following:
The only safe (?) way I know of to set things up is to create
a special "mail" group, make /bin/mail setgid to this group,
and arrange for the mail spool directory and mail files to be
group-writeable.
It seem this opens a new can of worms. If /bin/mail is setgid instead
of setuid, then all mail reading programs must be changed to not delete
empty mailboxes. This is because new mailboxes would then be created owned
by the sender (that old bugaboo), and you wouldn't be able to delete your
own mail (unless all mail reading programs were also setgid).
--petermsc@qubix.UUCP (06/10/83)
It is true that /bin/mail allows you to write to files but there
is no security hole. I run our /bin/mail suid root. It will
not, however let you write to files owned by root or anyone else.
Obviously someone thought of this and the program sets itself to
its real user ID before trying to write to files.
--
Mark
...{decvax,ucbvax}!decwrl!qubix!msc
...{ittvax,amd70}!qubix!msc
decwrl!qubix!msc@Berkeley.ARPApdl@root44.UUCP (06/12/83)
Mail readers SHOULDN'T delete empty mailboxes, since the owner normally decides what mode the mailbox will have (to allow/disallow reading by other users etc.). System III operates with set-gid mail and seems to work O.K., the problem is therefore in nasty mail readers that remove mailboxes! Dave Lukes. (...!vax135!ukc!root44!pdl)
rusty@sdcarl.UUCP (06/13/83)
i'm not sure this is a complete fix, but what i did was to add setuid(getuid()) in the routine sendmail() just before it exec's delivermail. i think the problem is an interaction between /bin/mail being setuid root and delivermail not knowing that the uid it is being exec'd with came from a program that was setuid.
SJOBRG.ANDY%MIT-OZ%mit-mc@sri-unix.UUCP (06/14/83)
Why not just hack out all of the mail processing stuff from /bin/mail so it is JUST a mail deliverer...that way there are no security holes. It then should probably be called something other than /bin/mail, and /usr/ucb/Mail should be linked to /usr/ucb/mail just so lusers that still insist on trying to use /bin/mail get the right thing.
dbj.rice%rand-relay@sri-unix.UUCP (06/15/83)
From: Dave Johnson <dbj.rice@rand-relay> We noticed the "gaping security hole" in /bin/mail here at Rice and found a simple to fix the problem (actually, Bill LeFebvre here found the solution). Make /bin/mail do a setuid(getuid()) after forking a subprocess but before execing /etc/delivermail. Delivermail is actually the one that mails to files and it doesn't expect to be a setuid program. It thus doesn't check for access() to write on the file, but merely does it and lets it fail if it will. /bin/mail IS supposed to be setuid to root, but delivermail IS NOT. The setuid(getuid()) in /bin/mail sets the effective uid back to the real uid, undoing the effect of /bin/mail being a setuid program before running delivermail.