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 - 17:30:38 CDT

Chris Evans writes:
> I really think this is the direction Linux security needs to go in. After
> all, a thorough audit may still miss holes, so why not make them
> moderately irrelevant?

I agree. This is wonderful.

> If sufficient interest/enthusiasm is generated by this, I'm sure I can
> clean it up and get it accepted into the offical netkit.

What should I do to convince you I'm enthusiastic? Should I send you
US$500? Beer? ;)

> 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 exceptions were init, kflushd, kupdate, kpiod, kswapd, mdrecoveryd,
apmd (?), gpm, and X.

Here are the other results:
- I'm running "pump", which needs to be able to send DHCP requests,
  receive DHCP responses, and reconfigure eth0. If you're logging in
  via telnetd or ftpd, sending or receiving raw Ethernet frames is
  equivalent to root, but in a ssh environment, it's not. (Of course,
  a compromised "pump" could make the machine inaccessible via the
  network, or cause IP-address collisions.) So pump should run as a
  non-root user and use one, two, or three privileged helpers.
- "portmap" is running as user "bin". It should probably be in a
  different group.
- "syslogd" is running as root. Why? So it can listen on /dev/log?
- "klogd" is running as root because only root can call syslog().
- "atd" is running as "daemon". Bravo for Red Hat. Why doesn't it
  have a userid of its own? Isn't "atd" one of the canonical
  applications for userv?
- "crond" is running as root, presumably so it can run programs on
  behalf of everyone. userv? At least an unprivileged helper?
- "inetd" is running as root so it can bind to low ports.
- "lpd" is running as root apparently so it can listen on /dev/printer
  and TCP port 515.
- "sendmail" --- 'nuff said.
- "xfs" is running as "xfs" instead of root; good for Red Hat. It's
  not chrooted, though.
- "mingetty" is running as root for no obvious reason. Can someone
  enlighten me?
- "gdm" is running as root presumably so it can run things as arbitrary
  users.
- Apache is running as root so it can bind to port 80 and become nobody.

> [1] OK - so /tmp is a lousy chroot() destination. Maybe FSSTND needs
> /var/empty or something.

The ideal situation would be that each daemon runs as a different uid
in a different chrooted area. Hardlinks make this fairly cheap,
spacewise, as long as each area is on the same partition; is there a
convenient tool for setting up chroot jails? I could hammer something
together with Perl and strace in an hour or two, but it would only work
about 90% of the time. 

-- 
<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"]