Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Apr 1998 12:25:40 -0600 (MDT)
From:      Marc Slemko <marcs@znep.com>
To:        Karl Denninger <karl@mcs.net>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: suid/sgid programs
Message-ID:  <Pine.BSF.3.95.980419121151.16057t-100000@alive.znep.com>
In-Reply-To: <19980419124742.02609@mcs.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> 
> 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.

> 
> 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.

> 
> 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.
> 
[...]
> 
> 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.

> 
> 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.

> 
> 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. 

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.


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?Pine.BSF.3.95.980419121151.16057t-100000>