OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Demo patch - run telnetd as non-root and chroot()'ed
From: Kragen Sitaker (kragenpobox.com)
Date: Thu Jul 20 2000 - 20:50:40 CDT

Tymm Twillman writes:
> Well, some of these have to run as root to handle re-opening log files
> when HUPed. Of course, setting up /var/log to be handled by another user
> I think would be a very fine way of handling this.

That would be syslogd, I think, and having another uid to handle this
would be very nice. Compromising the system logs is not normally
equivalent to compromising root, although it can be very helpful in
concealing other attempts to do so.

Apache has a similar situation.

> I believe gpm needs the access because it needs access to the mouse port;
> of course having a "mouse" user could also be used to handle this...
> although since you can have either a mouse or something else on
> /dev/ttySx... ugh.

gpm effectively has root access if root logs onto a console because it
can paste commands to be run as root. Accordingly, recent versions of
Linux (since 2.0?) restrict pasting to consoles to the root user and
the logged-on user. (Similar considerations, although less severe,
apply to reading contents of consoles.) So running gpm as a 'mouse'
user would not be useful.

> Also I'd kind of like to get some feedback on something I've been thinking
> about/working on in spare time. I don't like the fact that inetd passes
> root privs on to other packages at all (well, generally)...

inetd can run as uid.gid inetd.inetd; each program to be invoked by
inetd can have a mode-4710 launcher with uid.gid something.inetd in
order to run as some other uid.

> How do people
> feel about an inetd that uses modules that perform authentication for
> different protocols and then run servers as the user after
> authentication... it would require apps to be written specifically to
> conform to its way of handling things, but it means one main place, with
> shared code, for authenticating users, so it'd be easier to audit... and
> we wouldn't have to worry nearly as much about the holes in different
> applications from different vendors...

It might be a good thing to insulate inetd from these modules so that a
flaw in one of them will not compromise inetd. (This is especially bad
if the service being authenticated would not have run as root in the
old scheme.) Also, if they run in the inetd process, it must become
more complicated to be able to deal with select()-loop stuff or
multithreading.

Given these constraints, I think these modules should run as processes
forked from inetd; it is probably simplest, then, to exec() a file
instead of simply loading some shared library and running code from it.

Doing this does not require any changes to inetd, in fact. Little
setuid-root programs can do this for you. 

-- 
<kragenpobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves        
possess.
                -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]