From owner-freebsd-security Mon Nov 16 21:28:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17085 for freebsd-security-outgoing; Mon, 16 Nov 1998 21:28:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA17070 for ; Mon, 16 Nov 1998 21:28:21 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id VAA23429; Mon, 16 Nov 1998 21:27:33 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 21:27:33 -0800 (PST) From: Matthew Dillon Message-Id: <199811170527.VAA23429@apollo.backplane.com> To: William McVey Cc: Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, jkh@zippy.cdrom.com (Jordan K. Hubbard), dima@best.net (Dima Ruban) Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 References: <199811162114.PAA06569@s07.sa.fedex.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> (1)Add a 'kmem' and 'tty' dummy user to /usr/src/etc/master.passwd. :> Unfortunately, the operator uid is already using 2 (why it didn't :> use 5 I'll never know), so give the kmem user uid 5 and the tty :> user uid 4 (same as their groups except for the operator<>kmem :> flip). : :If we are adding standard ids to the password file, what do you think of :adding the following loginids and groupids for services that can run :standalone as unprivilged users (these are ones I've set up on my set of :machines, it'd be nice to "standardize" them): : smtp (uid and gid of 25) : www (uid and gid of 80) : ftp (uid and gid of 21) : tftp (uid and gid of 69) : syslog (uid and gid of 514) : (another root daemon which probably doesn't need root, I : just made the changes on one of my machines... I'll let the : list know how it works out.) I agree. Normally I'd use the same uid as the group id if a group exists, or barring that the /etc/services port (but those start to infringe on what people use for real user id's, we probably have to keep the id's < 100). :I've never like lumping different types services under "daemon" or "nobody". Neither have I. I think it's a gaping security hole especially when web servers use nobody. :I'd chose uid/gid 515, of course, you probably could have predicted that. :Not coincidentally, I start numbering users as 1025. :-) 1000 for me, but I know a lot of people that start at 100. :> Use RCAPF_SETTIME to fix xntpd :> :> Use TCAPF_LOWPORT to fix xntpd, lpd, bind, sendmail, and possibly :> others. : :I'm not convinced that sendmail and lpd require TCAPF_LOWPORT. I think :inetd and the 'wait' attribute can do what they need, but I'm all for :adding the solution as defined above. It probably would be usefull for :bind (which as a single process needs to bind to udp/53 as well as tcp/53). I don't think they need it either, as long as sendmail and lpd are started as root and setuid() themselves after binding the port I'd be happy. :[ this is also directed to a running thread titled "sendmail changes in : OpenBSD 2.4" ] : :I'm a fan of running a setuid root mail.local, executable by only :only group 'smtp'. Sendmail invoked as a wait service out of inetd :as user/group of 'smtp'. This avoids the potential misuse of the :delivery program by regular users (which are not in group 'smtp'), :allows sendmail to run unprivileged, and requires no code changes :to operate. I've used this sort of security policy for other programs.. giving the ability to execute to the group, modes 710, but I'm not fond of it for general use. :To strip the setuid root bit from the delivery agent will require :the daemon to be privileged so that it can setuid to the user who's :mail is being handled. I would say a setuid root program that no-one :but the MTA can execute is the lesser of two evils. : : -- William I considered having a sysctl range for a non-root setuid() call capability, but figured too many people would start screaming. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message