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: Chris Evans (chrisferret.lmh.ox.ac.uk)
Date: Fri Jul 21 2000 - 06:24:38 CDT

On Thu, 20 Jul 2000, Kragen Sitaker wrote:

> > P.S. Note that the majority of daemons can be run with non-root and
> > chroot(), even if they sometimes need a pipe to a distrusting privileged
> > helper. And if they were, we would be in a _much_ better security
> > situation.
>
> I counted the processes running as root on my Red Hat 6.1 machine. The
> vast majority were running as root either because they had to run
> things as arbitrary users (I think userv is a solution to this, but I
> can't actually figure out what userv does by reading the
> documentation), because they need to bind to low ports, or because they
> need some single little privilege that Linux accords only to root.

The "run things as arbitrary users" case is interesting.

In the case of things like ftpd or samba, there's a solution I'd like to
advocate. Generally, ftpd/samba require the user to authenticate with
username/password, so they run as root.

Obviously, the above approach leads to horrific remote root compromises as
seen in the (not so distant) past.

A better architechture would be something like

- Launch ftpd as root
- Create a pipe pair for interprocess communication
- ftpd forks()
- child drops all privs/chroot()s and starts parsing network data
- when child has a username/password login request, it passes
username/password down pipe in some manner
- parent checks username/password combo (hopefully re-using the code in
something like PAM's pwdb_chkpwd)
- If username/password credentials are OK, parent fork()'s, switches to
correct uid and exec()'s the "real" ftpd process

With the above approach, a security hole in the ftpd code won't be a root
compromise, regardless of whether it is an anonymous or local user
login. Of course, that's only true if the privileged username/password
checker is hole-free. That isn't too hard to arrange, though, because it
is such a small piece of code. It is even easier to arrange if some of the
PAM stuff is re-used.

Cheers
Chris