[ On Tuesday, September 9, 2003 at 12:06:24 (-0400), Dan Melomedman wrote: ]
> Subject: Re: BSD Authentication
>
> As far as services are concerned, the right thing to do
> is to drop root, and chroot to a jail as soon as it's not needed. Too bad
> this methodology isn't used often. Sendmail and BIND traditionally
> didn't have this feature.  I believe the new BIND finally has this
> feature, and the risk for the root exploit is lower with the new BIND.

Yes, BIND "finally" gained this feature quite some time ago.  (sadly a
great many sites are still running BIND as root all the time)

Unfortunately it doesn't do something like Sendmail one bit of good in
many modern systems, at least not with the default configs and installs,
since any foreign code exploit can just make use of the saved
set-user-ID feature to re-instate root privileges for itself.  I'm not
even sure OpenSSH has gained any real security from this kind of
excercise either -- but rather they may just have added a lot of
unnecessary complexity and created a false sense of security that could
actually introduce more risk.  (I've not studied the way OpenSSH tries
to do privilege separation since I don't normally use it.)

I've turned off saved set-user-ID on my development system and once I've
ironed out some of the code relying on this non-portable feature from a
few remaining applications I use but have not already fixed then I'm
going to deploy systems where I can be sure that once a process gives up
its privileges then they really are always permanently given up and stay
that way.

It's quite amazing to see some of the places where I've hacked out some
of the most ludicrous attempts to pretend that temporarily dropping
privileges gives some added level of security.  Some folks must think it
is so much better to stick their heads in the sand for all the time when
they don't really need to see what's around them.  After all they can
always pop up and look danger in the eye at any time they really need
to!  ;-)

I've even encountered a few set-uid-root programs which do eventually
properly do the right thing to permanently drop privs after they've done
their setup, but they also temporarily "drop" their privs during the
parts of their setup code where they don't need such privs (even when
having full privs does no harm).  I have no idea why some programmer who
knows full well that they have to do something special to permanently
drop privs on saved set-user-ID systems would still be so blind to what
they're doing and also abuse that feature to pretend the process is not
really still capable of being privileged during the time when they've
temporarily dropped its privs.

Given what I've seen to date the utility of the saved set-user-ID
feature is far over-shadowed by the outright abuse it has been put to by
more than one well meaning but un-thinking programmer.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>