Date: Sun, 19 Apr 1998 12:47:42 -0500 From: Karl Denninger <karl@mcs.net> To: rotel@indigo.ie Cc: Marc Slemko <marcs@znep.com>, freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Message-ID: <19980419124742.02609@mcs.net> In-Reply-To: <199804191703.SAA00814@indigo.ie>; from Niall Smart on Sun, Apr 19, 1998 at 06:03:42PM %2B0000 References: <marcs@znep.com> <199804191703.SAA00814@indigo.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 19, 1998 at 06:03:42PM +0000, Niall Smart wrote: > 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. Actually, I would argue that ZERO user populations need those subsystems. Things like "ccdconfig" simply don't need to be run as a user process. If someone is going to be setting up a ccd set, they are ALREADY going to be root! Take the permissions off these things folks. They don't need to be there, and exporting things like this to the user community serves, IMHO, ZERO purpose. Administrative functions should remain accessible only with administrative privileges. If someone wants to override that, they can SUID/SGID the appropriate binaries themselves. The same, by the way, goes for a lot of other things. I see the sanity in SUIDing "ping" for example, since it needs to be root to get the raw socket which it must use in order to create the ICMP packets to send. Same with traceroute. But the huge majority of SUID things out there? They are nothing other than a security menace. IMHO of course. This is all that is SUID here on our cluster machines in the / and /usr directories. /bin/rcp /sbin/ping /usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/batch /usr/bin/login /usr/bin/rlogin /usr/bin/rsh /usr/bin/crontab /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/newaliases /usr/bin/mailq /usr/bin/hoststat /usr/bin/login.saved /usr/sbin/sendmail /usr/sbin/traceroute I'd love to be able to get rid of permissions on the LPD commands, but unfortunately they really do need them. Those are the ones which, at present, give me the most "willies" right now. The other thing I'd like to explore is the capability of getting rid of the SUIDness to *root* on some of these. LPR, for example, doesn't need to be SUID to root - it may need to be SUID to some safe UID, but root simply isn't required - it attaches to a *non privileged* IP port. Same with crontab, at and batch. *CRON* needs to run as root, but crontab and friends DO NOT. They need to be SUID to something, but again, not root. Sendmail and friends need to be root long enough to bind to port 25. But after that, they could switch to another UID and STAY THERE. Local delivery agents need to be SUID to root on their own, but sendmail doesn't need to run that way other than long enough to perform the BIND to the port. UUCP does this "right" in this package is SUID to *uucp*. That's much safer than root, as uucp doesn't have any special capabilities. Unfortunately I *need* to have login SUID around here due to some things that it does which aren't standard :-) Then again, the BSD standard has it SUID anyway, so you can do a "login" from a shell session and effectively sign in as someone else. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980419124742.02609>