From owner-freebsd-security Sun Apr 19 10:05:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17806 for freebsd-security-outgoing; Sun, 19 Apr 1998 10:05:42 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (ts01-45.waterford.indigo.ie [194.125.139.108]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17786 for ; Sun, 19 Apr 1998 17:05:22 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id SAA00814; Sun, 19 Apr 1998 18:03:42 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804191703.SAA00814@indigo.ie> Date: Sun, 19 Apr 1998 18:03:42 +0000 In-Reply-To: Marc Slemko "Re: suid/sgid programs" (Apr 19, 9:54am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Marc Slemko , Niall Smart Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 9:54am, Marc Slemko wrote: } Subject: Re: suid/sgid programs > On Sun, 19 Apr 1998, Niall Smart wrote: > > > > I think the point he was making was that most users don't use UUCP, and > > therefore we shouldn't be shipping UUCP related utilities with set[ug]id > > bits. Presumably if you can configure UUCP you can use chmod. > > Erm... that is an extremely poor policy. Figuring out what needs to be > setuid or setgid to what isn't trivial. I'm not sure what you are trying > to save here. What is the real issue if someone compromises the user or > group uucp? I understand your point, but I think we are getting too focused on the UUCP utilities in particular which is confusing the issue. My point is that FreeBSD ships with a lot more set[ug]id binaries than the average user needs. Some examples being ccdconfig, ncrcontrol, mtrace, timedc and the UUCP bins. I think a policy of keeping the barest minimum of set[ug]id utilities, leaving the system administrator to chmod the ones he needs at his site, offers a more secure approach than that of putting a set[ug]id bit on every utility which needs one that anyone could ever possibly want to use. I'm not advocating taking this approach to its extremes, but it simply does not make sense to be shipping enabled subsystems which could result in a system compromise when only a tiny proportion of the user population use those subsystems. Of course others will argue that this is all a load of baloney and what we *really* need is a full code audit, even if we had the resources to do this, I would still maintain it is a good idea to ship the system with as few set[ug]id utilities as is practical. Look at Solaris or IRIX for example, there are tens of setuid programs on those systems by default, most of which are never used. And the first step in trying to secure one of those OS is to knock the setuid bits from about three quarters of those files. I disagree that figuring out what needs to be set[ug]id is difficult, confusion about why a directory is such and such a permission or why such and such a utility needs to run as root usually indicates a lack of understanding of how the system is working. If you don't fully understand the permissions on each file/directory in your filesystems then it's your tough luck when things start to go wrong. Regards, Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message