Date: Sun, 19 Apr 1998 19:18:54 -0500 From: Karl Denninger <karl@mcs.net> To: Marc Slemko <marcs@znep.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Message-ID: <19980419191854.00143@mcs.net> In-Reply-To: <Pine.BSF.3.95.980419121151.16057t-100000@alive.znep.com>; from Marc Slemko on Sun, Apr 19, 1998 at 12:25:40PM -0600 References: <19980419124742.02609@mcs.net> <Pine.BSF.3.95.980419121151.16057t-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 19, 1998 at 12:25:40PM -0600, Marc Slemko wrote: > On Sun, 19 Apr 1998, Karl Denninger wrote: > > > 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! > > Erm... but if someone wants to see what ccds are configured, they don't > need to be root and shouldn't. > > Same thing with netstat, etc. Fine. Anyone who wants to do that can make them SGID kmem or as otherwise appropriate. For the vast majority this is unnecessary. (BTW, making something SGID kmem only allows READ access to kmem. Making something SUID root gives it READ and WRITE access to anything, including kernel and user memory along with all devices (assuming the securelevel is set to -1)). > > 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. > > Then your definition of zero is different than mine. Fine, then you can change your system at whim, with full knowledge of the consequences of doing so. The default should be secure from such things. > > Administrative functions should remain accessible only with administrative > > privileges. If someone wants to override that, they can SUID/SGID the > > appropriate binaries themselves. > > There is a big difference between administrative functions and letting > a user know how things are configured. What is the purpose of an *ordinary user* knowing what the ccd configuration is? Not a dba, not someone who is doing system programming, but an ordinary user? If you argue that anyone should be able to see configuration details, then the fix is easy - sgid or suid the binary as appropriate. > > 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. > > But if someone can break the uid that lpr runs as then they can probably > break root anyway. You need more work than just saying "we shall change > the uid" to make it secure. Yes, improvements are possible and the work > has already been done in various lpd replacements. But it isn't as simple > as declaring that it shall work and having it be so. That's not true if lpd binds to the port and then setuid()s itself. That's irrevocable if done correctly (no flip-flop capable). > > 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. > > But if someone can break the uid that crontab runs as, they have root > anyway. Not necessarily. There are ways around that problem. >> 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. > > No, it (the way it is currently coded) needs to keep at least a saved uid > of root so that it can start refusing connections when the load gets high, > etc. Well, the way it is currently coded, perhaps. But there are other ways to skin that cat :-) > Going wild with saying "oh, this can just use some other user" is great > but it isn't as simple as saying it is the case. There are real reasons > why many things do use root and why arbitrarily creating some other user > for them doesn't add any security but just creates another user that, when > compromised, give easy root. You have to understand exactly why each > program has the privs that it currently does and fully understand the > impact of changing it. Uh, I do understand that in most cases, and in those where I don't, if/when I get around to fixing it I learn. -- -- 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?19980419191854.00143>