From owner-freebsd-security Mon Dec 9 16:50:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA20067 for security-outgoing; Mon, 9 Dec 1996 16:50:39 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA20060 for ; Mon, 9 Dec 1996 16:50:36 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id RAA01839; Mon, 9 Dec 1996 17:50:15 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id RAA16198; Mon, 9 Dec 1996 17:48:31 -0700 (MST) Date: Mon, 9 Dec 1996 17:48:30 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Cy Schubert - ITSD Open Systems Group cc: bmk@pobox.com, security@freebsd.org Subject: Re: Running sendmail non-suid In-Reply-To: <199612092111.NAA17991@passer.osg.gov.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Dec 1996, Cy Schubert - ITSD Open Systems Group wrote: > > I'm setting up an internet-connected mail hub, and I'd like to run > > sendmail not suid root. I won't be needing any ~/.forward nonsense, > > as this machine will have no users at all, and will only forward mail > > based on /etc/aliases. There will be no local mailboxes on this machine > > at all. > > > > My intention for running sendmail without suid set is so that I can > > hopefully avoid some of the security problems that we've seen with > > sendmail in the past. > > > > Ideally, what I'd like to do is have sendmail running as root only long > > enough to bind to the smtp port, and then give up root, never to have > > it back. Preferably, running as 'nobody' or some other 'safe' user. > > > > Has anyone actually done this? Any advice or gotchas to look out for? > > Am I insane for wanting to do this? You are very sane to want to do this. Everyone else is insane. And I'm serious about that. Someone should put together a document on making sendmail run as a non-root uid. Another thing I'm thinking of playing with sometime. If you want something smap like, without the licensing restrictions, you could look at smtpd from ftp://ftp.obtuse.com/pub/smtpd. > > First you will need to create an smtp account. > > Next, chown /var/spool/mqueue, /var/mail, and /usr/sbin/sendmail to user > smtp. > > Run a cronjob out of root's cron every 5 minutes to process the queue. You are missing something here WRT how to have sendmail bind to port 25. There are three likely ways; have it run as root long enough to bind in a similar fashion to most webservers, run it from inetd, or modify the kernel to let a particular non-root user bind to port 25. If you have sendmail running as a daemon using either the first or third methods, you don't need to run sendmail from cron. > > Using this approach you'll manage to stop 95% of any attempts to use > sendmail to gain access to root. There is still a possibility of gaining > root with this setup if your smtp account is hacked. It would be a matter > of creating a mail spool file to setup a setuid-root shell. The general > consensus has usually been that this approach is less secure because it is > easier to gain access to a user account than root. Consider that sendmail running as a non-root user can't just magically become root. It has to be setup so it can do so. Normally this is a possible problem because it runs as root so it can switch to whatever user it wants. However, in this case the whole point is that it isn't running as root. If you wish to allow users to do things such as run programs from .forward files, it needs to be able to switch uids to an arbitrary user somehow, by doing something like running as root, hacking the kernel or calling a sub-program which is setuid. However, in this case it has been stated that there is no local delivery so no special method has to be designed to allow for this. If a NFS host that you trust is compromised, you are in trouble anyway. On nearly all systems, there is at least one person who has a non-root account that they use to su to root. Compromise that account, and you can have root the next time they su. A little more hassle, but not that much.