Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!tytso
From: tytso@athena.mit.edu (Theodore Y. Tso)
Newsgroups: comp.mail.sendmail
Subject: Re: Non-root sendmail?
Message-ID: <7902@bloom-beacon.MIT.EDU>
Date: 11 Nov 88 22:28:15 GMT
References: <164@heart-of-gold> <3031@haven.umd.edu> <756@hudson.acc.virginia.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tytso@athena.mit.edu (Theodore Y. Tso)
Organization: Massachusetts Institute of Technology
Lines: 27

In article <756@hudson.acc.virginia.edu> gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) writes:
>Is there any reason why sendmail has to run as the same "daemon" which
>owns the files generated by the "at" command? This is unfortunate,
>because anyone who can break sendmail and get a suid daemon shell can
>(according to a friend of mine) then generate an "at" command and go
>edit the command file to have root execute the command. This allows
>you to generate a root suid shell.
>
>Shouldn't we be glad that our friendly virus didn't know this :-) Why
>are these daemons the same?

On machines that I care about :-), /usr/spool/at gets owned by root and
the at, atq, and atrm commands are setuid root.  The reason?
It's precisely as you mentioned --- being able to fake out "at" is
equivelent to having root access.

On to a more interesting sendmail question:  why is it that when
sendmail invokes a pipe to a program, if it can resolve the sender of
the mail message to a local user, it runs the program as that user?
That seems to me to be completely wrong, since there's absolutely no
authentication over an SMTP port --- this could be an easy way to
breach security, even if the DEBUG command isn't there.  For example,
the user may have been careless in a .forward or in the aliases file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o				mit-eddie!mit-athena!tytso
3 Ames St., Cambridge, MA 02139		tytso@athena.mit.edu
			If it's for real, it isn't!