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: Fri Jul 21 2000 - 14:46:00 CDT

Olaf Kirch writes:
> On Fri, Jul 21, 2000 at 12:14:52AM -0400, Kragen Sitaker wrote:
> > owned by group inetd. So gaining group inetd and thus having a chance
> > of becoming root by compromising a launcher would be just as hard as
> > gaining root by breaking inetd is today.
>
> No. Break one of the inetd-launched setuid foobar applications,
> become user foobar, overwrite the foobar launcher with /bin/bash.
> Reconnect to foobar socket, and inetd will give you a shell running
> group inetd.

You are right, of course. So this approach is only useful for
running-as-root launchers, which must then set their uids to something
else. (Which need not depend on input; the fingerd launcher could set
its uid to 'nobody' or 'fingerd', then exec fingerd, all without
parsing any input.) Thanks for catching that.

> I once used to be a huge fan of this obstacle course type of security,
> too. A longish discussion with Rogier Wolff made me see the light :-)

Is this discussion archived somewhere? I am obviously still
unenlightened :)

> The point is that if you stretch out your security and insert more or
> less random privilege boundaries, you may end up with less security
> than before. The case of this inetd design illustrates this. The
> design is well-intentioned but the effect is that if I break fingerd,
> I don't just get nobody privilege, but I own the entire inetd process.

Well, unless fingerd is started by a setuid-root launcher that then
uses setuid() to become nobody.

The point is a good one: simple designs are less likely to have flaws,
and more security domains produces a more complex design. I still
think that they are worth the complexity costs.

> I'm all in favor of taking Occam's razor to daemons running as root.
> Some lend themselves very well to splitting off lesser-privileged
> portions, vice Chris' telnetd patch. Some don't, and these include
> things such as inetd and crond which need to execute programs as
> arbitrary users.

Well, inetd and crond only need to execute certain very particular
programs as certain very particular users. It would be nice to remove
their ability to run any arbitrary program as any arbitrary user,
including root.

Pavel Kankovsky writes:
> On Thu, 20 Jul 2000, Kragen Sitaker wrote:
>
> > - "portmap" is running as user "bin". It should probably be in a
> > different group.
>
> Portmap should die.

That would be nice, wouldn't it? :)

> > - "mingetty" is running as root for no obvious reason. Can someone
> > enlighten me?
>
> It needs to start login.

Hey spiffy, /bin/login isn't setuid on my system anymore. I hadn't
noticed that. That explains why I can't do 'login' from a shell window
any more.

Debian telnetd uses a little 4710 helper (from this very mailing list)
to spawn login as root; perhaps mingetty could do the same. Red Hat
telnetd doesn't bother. Bad Red Hat.

> > - Apache is running as root so it can bind to port 80 and become nobody.
>
> Only the "supervisor" process runs as root and it makes some sense because
> children cannot mess with it.

They can still mess with each other.

> > The ideal situation would be that each daemon runs as a different uid
> > in a different chrooted area.
>
> Ideally, each INSTANCE should run in its own compartment (uid + chroot).

Of course you are correct. Unfortunately, adding compartments at
run-time on a Unix system is tough. (Also, because of the dumpable
magic Chris pointed out, we wouldn't gain much in this particular
case.)

Bill Nottingham writes:
> > On Thu, 20 Jul 2000, Kragen Sitaker wrote:
> > > The exceptions were init, kflushd, kupdate, kpiod, kswapd, mdrecoveryd,
> > > apmd (?), gpm, and X.
>
> k* & mdrecoveryd are kernel threads.

Right, so they need to run as root ;)

> > > - "xfs" is running as "xfs" instead of root; good for Red Hat. It's
> > > not chrooted, though.
>
> It really can't be, unless you want it chrooted somewhere
> under /usr where it can still access all the fonts. You want
> it to be able to re-read its configuration and re-access fonts
> without restarting the server (as that breaks all the connections.)

My Sun NFS-mounts its root partition; I copied all the fonts into it so
I wouldn't need xfs on my Linux server. You could just as easily copy
or hardlink the fonts into a chroot jail.

chroot doesn't interfere with SIGHUP handling, unless there's something
I'm missing.

> Trying to package hardlinks across a distribution is really ugly.
> (Not that that should stop you, but it's hard to implement in the
> current framework for a generic install...)

Do you mean "across multiple distributions"? I agree. If not, what's
the difficulty? That rpm has to understand chroots? Yeah, it does :)

Adam Goryachev writes:
> > > - Apache is running as root so it can bind to port 80 and become
> > > nobody.
> > >
> > > 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
>
> ugh, which means that if someone breaks one chroot, and somehow can modify
> your binaries, they can affect all other chroot's. You just lost the
> advantage of having multiple chroot's....

If the binaries are writable only by root, modifying them requires
getting root. If you get root, chroot() doesn't do you any good any
more anyway.

> I used rpm with the --root /chroot-<name> to setup a couple of chroot's...

Is this smart enough to install all the libraries needed by a
particular program? I haven't tried it.

> Actually, I could definitely reduce that number, especially if I removed
> initscripts,

Heh :) OK, it *is* smart enough --- it's a little *too* smart. :) 

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