🚀 go-pugleaf

sendmail runs as root for the rather obvious reason that it needs to bind
a socket to a restricted port number (25 == SMTP).  Before sendmail exec()'s
any processes, it does a setuid() to UID 1, which is daemon.  None of the
virus processes running on our system ran as root; rather they ran as
daemon.

Let's not flame sendmail for having the DEBUG command.  It actually is a
rather useful tool.  Instead of removing the DEBUG command, simply 
change the 3 lines of code that check for a particular debug flag being
set, and allowing mailing directly into programs, files and :include: lists.


Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming

In article <3031@haven.umd.edu> louie@trantor.umd.edu (Louis A. Mamakos) writes:
>sendmail runs as root for the rather obvious reason that it needs to bind
>a socket to a restricted port number (25 == SMTP).  Before sendmail exec()'s
>any processes, it does a setuid() to UID 1, which is daemon.  None of the
>virus processes running on our system ran as root; rather they ran as
>daemon.
>

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?

-- greg

----------
Greg Lindahl                                    internet:  gl8f@virginia.edu
University of Virginia Department of Astronomy    bitnet:  gl8f@virginia.bitnet
"grad students don't need disclaimers; the department doen't care what I think"

In article <164@heart-of-gold>, jc@heart-of-gold (John M Chambers) writes:
> 
> Is there a way to run sendmail under a non-root id?  
> 
It may not be possible for the following reason: there is no way currently
for any other id to concatenate a new message to /usr/spool/mail/fubar,
where fubar typically has rw to owner only. If permissions were not so, then
other users could peek into fubar's mail.
>
> I'm also rather familiar with sendmail's main competitor, uucp.  It seems
> to run quite well under a mail id, and doesn't need anything setuid to root.
> In fact, it's fairly conventional to make all the programs setuid to uucp,
> or even better, setgid to mail, with all the files and directories being
> owned by uucp/mail.  Mailboxes then end up owned by the user, with group
> mail and 660 permissions, and all that, and it works just fine.
>
Which system are you talking about? If it is BSD, the final delivery of mail
is always done by a suid program and not directly by UUCP, since quite
obviously there is no way for a program running as user "uucp" to write
to file that is owned by the user.

(The postal van may be out of bounds but you can always mug the postman :-)

However what you say gives me an idea. What if sendmail were made set-gid
"mail" (but not set-uid) and all mail related files, including
/usr/spool/mail/foo were made rw by group "mail", but no user is a member
of group "mail"? This would mean, of course, that /usr/spool/mail must
always contain a mbox for each user (since a rw file owned by user can
only be created by the user or root,) but that is a minor hassle. Maybe a
few hacks to make sure that /usr/spool/mail/fubar never gets deleted by any
program.
-- 
"We will fight for the right to be free {) badri@ee.rochester.edu
 We will build our own society         //\\ {ames,cmcl2,columbia,cornell,
 And we will sing, we will sing       ///\\\ garp,harvard,ll-xn,rutgers}!
 We will sing our own song."  -UB40    _||_   rochester!ur-valhalla!badri

In article <164@heart-of-gold>, jc@heart-of-gold (John M Chambers) writes:
>Is there a way to run sendmail under a non-root id?  
>
>Maybe I should clarify.  The obvious answer is "yes", since /etc/rc can
>always do something like
>	su mail /usr/lib/sendmail -bd -q1h
>This is not a good enough answer, however, because, while I can indeed do
>this on our Suns, the resulting process dies rather soon, resulting in no
>sendmail daemon running at all.  Why it dies, I don't understand.

When sendmail runs as the SMTP listener it must bind itself to a
priveledged port. This requires it run as the superuser.

You might consider writing a seperate process to deal with the
SMTP socket that hands off incoming messages to sendmail,
which could (probably) run setgid and not setuid. I say probably
becuase sendmail was written to run as the superuser, and would
require some hacking to function in a setgid environment.

The fact of the matter is sendmail needs a complete re-write.

--lyndon

) John M Chambers:
) > Is there a way to run sendmail under a non-root id?  

Badri Lokanathan:
) It may not be possible for the following reason: there is no way currently
) for any other id to concatenate a new message to /usr/spool/mail/fubar,

Sendmail doesn't *do* that, /bin/mail does.

In article <1572@valhalla.ee.rochester.edu> badri@valhalla.ee.rochester.edu (Badri Lokanathan) writes:
>In article <164@heart-of-gold>, jc@heart-of-gold (John M Chambers) writes:
>> 
>> Is there a way to run sendmail under a non-root id?  
>> 
>It may not be possible for the following reason: there is no way currently
>for any other id to concatenate a new message to /usr/spool/mail/fubar,
>where fubar typically has rw to owner only. If permissions were not so, then
>other users could peek into fubar's mail.

Funny thing is, sendmail doesn't deliver mail to the user's mailbox.  It
invokes '/bin/mail -d' to actually concatinate the mail to the end of the
user's mailbox.  Look at the defintion of the the local mailer in the
sendmail configuration file /usr/lib/sendmail.cf if you want to see how
it is invoked.

By invoking /bin/mail, sendmail doesn't have to know about which flavor
of mailbox locking you happen to be using on that system (link to lock file,
flock, etc).


Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming

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!

In article <735@tank.uchicago.edu>, matt@oddjob.uchicago.edu (Matt Crawford) writes:
> Badri Lokanathan:
> ) It may not be possible for the following reason: there is no way currently
> ) for any other id to concatenate a new message to /usr/spool/mail/fubar,
> 
> Sendmail doesn't *do* that, /bin/mail does.

True. I stand corrected. However I delved into the Installation and
Operation Guide (by Eric Allman) and found this interesting tidbit:
-------------------------------------------------------------------------------
	.
	.
4.7.1. To suid or not to suid?
		Sendmail can safely be made setuid to root. At the point where
       it is about to exec(2) a mailer, it checks to see if the userid
       is zero; if so, it resets the userid and groupid to a default
       (set by the u and g options.) This can be overridden by
       setting the S flag to the mailer for mailers that are trusted
       and must be called as root. However this will cause mail
       processing to be accounted (using sa(8)) to root rather than to
       the user sending mail.

4.7.2. Temporary file modes
		The mode of all temporary files that sendmail creates
	is determined by the "F" option. Reasonable values for this option
	are 0600 and 0644. If the more permissive mode is selected, it
	will not be necessary to run sendmail as root at all (even
	when running the queue).
	.
	.

5.3.6. Building mailer descriptions
	.
	.
	If the mailer must be called as root, the "S" flag should be
	given; this will not reset the userid before calling the
	mailer (sendmail must be running setuid to root for this to
	work.)
	.
	.
-------------------------------------------------------------------------------
These were the only references to setuid that I found in the
documentation (other than rebuilding the aliases database and another
reference to the S flag in appendix C with the ironic statement that a
safe environment ran sendmail as root!) No reference to socket 25
being a restricted port.
-- 
"We will fight for the right to be free {) badri@ee.rochester.edu
 We will build our own society         //\\ {ames,cmcl2,columbia,cornell,
 And we will sing, we will sing       ///\\\ garp,harvard,ll-xn,rutgers}!
 We will sing our own song."  -UB40    _||_   rochester!ur-valhalla!badri

In article <164@heart-of-gold> jc@heart-of-gold (John M Chambers) writes:
> Is there a way to run sendmail under a non-root id?  

i run sendmail under uid 1 (daemon) on some of our systems
here.  these systems include all of our 11/70s (2.9bsd) and
some of our isolated VAXen (4.3bsd, not on any TCP/IP network).
i am sure that it would be possible to run sendmail under
uid 1 on systems with TCP/IP, i just haven't had the desire
to.  with source, sendmail could easily be modified to
start up, obtain required resources, and then permanently
setuid(1).

when running non-super, several things are important.
  1) the spooling directory must be owned by the uid
     and/or gid that sendmail runs under.  sendmail must
     have permission to create and delete spooling files.
     i do this by running setgid to 1 and letting the
     group permissions on the spooling directory be "rwx".
  2) people who have turned off search ("x") permission
     on their login directories will not be able to
     use .forward files.
  3) load average checking won't work for systems that
     get load average through /dev/kmem.  (2.9bsd has
     a separate system call.)
  4) all mailers you call must be prepared to do their
     own setuid()ing, since sendmail will never start
     them as uid 0.  /bin/mail on my systems already runs
     setuid to 0, and the other mailers likewise do not
     depend on being started as 0.

i've run sendmail for a few years this way, and have had
no troubles with it.

--dan dorough, ucdavis systems programmer, ccdan@ucdavis.edu

As quoted from <3031@haven.umd.edu> by louie@trantor.umd.edu (Louis A. Mamakos):
+---------------
| sendmail runs as root for the rather obvious reason that it needs to bind
| a socket to a restricted port number (25 == SMTP).  Before sendmail exec()'s
| any processes, it does a setuid() to UID 1, which is daemon.  None of the
| virus processes running on our system ran as root; rather they ran as
| daemon.
+---------------

Is it possible to run sendmail on a UUCP-only system without any setuid, but
instead setgid mail like the System III/V mailer?  What kinds of changes
would it take?  (Note that ncoast will most probably NEVER run any kind of
networking, so there's no reason for us to keep a setuid-root mailer.)

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery  <PREFERRED!>	    ncoast!allbery@hal.cwru.edu
allberyb@skybridge.sdi.cwru.edu	      <ALSO>		   allbery@uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.

> obviously there is no way for a program running as user "uucp" to write
> to file that is owned by the user.
> 
> However what you say gives me an idea. What if sendmail were made set-gid
> "mail" (but not set-uid) and all mail related files, including
> /usr/spool/mail/foo were made rw by group "mail", but no user is a member
> of group "mail"? 

You just contradicted yourself! (;-)  This is how uucp runs here.  Actually,
it is setuid also, to uucp.  So are uuxqt and uusched.  Mail files are owned
by the user, are group mail and have 660 permissions.


>		This would mean, of course, that /usr/spool/mail must
> always contain a mbox for each user (since a rw file owned by user can
> only be created by the user or root,) but that is a minor hassle. Maybe a
> few hacks to make sure that /usr/spool/mail/fubar never gets deleted by any
> program.

That happens here, though it isn't necessary.  This is a Sys/V, and the
command "chown root temp" just worked for me.  Of course, temp's setuid
and setgid bits got turned off by the chown, for obvious reasons.  If
your systems doesn't allow mere users to use chown, then you'll need
some hack for creating a mailbox for new users.  Perhaps a program that
does nothing but create a mailbox, and is setuid-root.  That oughta be
simple enough that it can be verified.

Most versions of uucp mail will leave a mailbox there if it has permissions
other than 600.

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]

> Is it possible to run sendmail on a UUCP-only system without any setuid, but
> instead setgid mail like the System III/V mailer?  What kinds of changes
> would it take?  (Note that ncoast will most probably NEVER run any kind of
> networking, so there's no reason for us to keep a setuid-root mailer.)
> 
Actually, it's rather common to make uucp's critical programs (uucico, uuxqt,
rmail, uusched, uuetc.) both setuid-mail and setgid-mail.  If you do this,
then you "protect" innocent administrators (including yourself) from all 
the ways that these programs can inadvertently end up being run with uid=root.
This includes all the various things triggered by cron (which must run as
root), any of which may call mail which may call uucico and/or uuxqt...

I've seen the same problems with news, which keeps stumbling across files
owned by root (and thus unwritable by news), until I change rnews, expire,
etc. to be setuid-news and setgid-news.

In both cases, using both setuid and setgid makes certain that the programs
will always run with the restricted permissions and can't be tricked by
some hacker into running as you and sending out all your secret files to
some interested party.

Of course, there are rumored to be versions of Sys/V which "remembers" old
ids (specifically, root, when run from cron) and provide some way of getting
back the old id even though it differs from getuid() and geteuid().  Such
systems probably provide a way of getting to root even with setuid-mail.
(I hope I'm wrong.)

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]

>Of course, there are rumored to be versions of Sys/V which "remembers" old
>ids (specifically, root, when run from cron) and provide some way of getting
>back the old id even though it differs from getuid() and geteuid().

Every version of System V since at least System V Release 2 will, when
you run a set-UID program, remember both the "real" UID (generally the
one in effect when the program was "exec"ed) and the UID to which the
program is set-UID, and will permit you to use the "setuid()" call to
switch the effective UID back and forth between them an arbitrary number
of times - with one exception: if the effective UID is "root",
"setuid()" will set the real, effective, and "save set-user" UIDs to the
specified UID.

Except for the latter glitch, this is a win; it allows a set-UID program
to do privileged operations, then do operations with the credentials of
the user (without having to muck with "access()").  The intent behind
the aforementioned glitch is presumably to allow programs such as
"login" or "su" to set all the IDs.  SunOS also supports the saved
set-user ID notion; since it has "setreuid", it permits even set-UID
"root" programs to set the effective UID back and forth.  Systems that
have "setreuid", including SunOS, also generally permit you to exchange
the real and effective UIDs; this provides another way for programs to
switch back and forth.