Mail Security and Locking Problems

[swatt at ittvax.UUCP]

Sam Praul is mistaken (sorry, Sam) about which program in the mail
system should be SUID to root:

 + DO NOT make /etc/delivermail SUID to root.  There is code in
   delivermail to do "setuid(getuid())" at various places, but
   I have never seen a claim that it is really secure. The
   successor "sendmail" is supposed to be secure.

 + DO make /bin/mail SUID to root.  This is usually a slightly
   smarter version of the standard v7 mail.

 + DO NOT make "rmail" a simple link to "/bin/mail" for UUCP;
   use the special "rmail" program that comes with delivermail.
   This one disallows "!" shell escapes.

Delivermail uses a separate mailer program for each type of delivery:
local, UUCP network, Arpa network, and so on.  It "cheats" and uses
"/bin/mail" for both local delivery and UUCP delivery.  Thus local mail
is passed from "ucbmail" (If you run it) to "delivermail" and finally
to "/bin/mail" for actual delivery.  Only the last stage needs to be
able to manipulate files in the mail spool area.

There is a bug in the standard 4.1bsd distribution (I don't know what
tape range) such that a number of programs which should have been SUID
were not.  There was an update notice which explained this.  The real
fix is:

	su root
	cd /usr/src/cmd
	setenv DESTDIR / ; MAKE MODES	(csh ["root" runs csh by default])
  or:
	DESTDIR=/ MAKE MODES		(bourne shell)

This will set the owner and modes correctly for a number of programs.
Setting the "DESTDIR" variable is important, or MAKE will try to diddle
things in  "/4bsd/...".  MAKE is a shell script if you're curious.  In
general, if you have questions about what belongs where and in what
mode and owned by whom, this is a good place to start.

If you have this problem, you should look at the 4.1bsd bug news
reports which come with the standard distribution; you might have
missed others. Some of these fixes are quite important and should be
made.

One of the "UNIX Newsletter" rags (I forget which one), first came out
with the mis-information about delivermail.  In general, the new
publications I've seen promote professional writing and production at
the expense of technical accuracy.  If you're getting technical advice
from various industry rags, make sure the article is signed by someone
claiming expertise; professional writers who summarize what they've
been told are prone to errors that could prove dangerous.

The above obviouly applies to advice you get from the net ...

	- Alan S. Watt