[ On Tuesday, January 30, 2001 at 10:22:08 (-0500), gabriel rosenkoetter wrote: ]
> Subject: Re: chrooted bind
>
> On Tue, Jan 30, 2001 at 03:27:39PM +0100, Thilo Manske wrote:
> > BTW: It's not difficult to let bind run as an other user either
> > (options -g & -u), I use this for >2 years now. I wonder why this is not
> > used more often...
> 
> People are silly and don't read documentation.
> 
> Really, though, this doesn't buy you much without the chroot.
> (You're still letting a fairly priveleged user onto your system.)

"fairly privileged"?  I think not, at least not if you've set it up
properly.  (though I guess it depends most on what ever else you might
be running on the same machines)

I use the following _unique_ user for my configs

	dns:*:32771:40:DNS Server Daemon:/etc/namedb:/sbin/nologin

You could even use the 'nobody' UID, but if you're running an NFS
envrionment, or also running some other daemon as that UID, then that
might not be such a good idea.

Sure the cracker's going to get a shell running as that user, but that's
it.  The only place they'll be able to write to is to any world-writable
directories, and maybe to /var/named or some such place if you've used
these options:

options {
        # keep named out of world-writable directories....
        dump-file "/var/named/named_dump.db";
        statistics-file "/var/named/named.stats";
        memstatistics-file "/var/named/named.memstats";
};

and naturally they will also only be able to read world-readable files.

The only thing that's harder to do is to restrict that user's use of
system resources (i.e. CPU and memory) since of course you don't want to
restrict the named process' use of these resources.  With newer NetBSD
and /etc/login.conf you can put that user in a different class that has
severely restricted capabilities -- you need only give it enough
resources to run a very few processes at a time (named-xfer's), and of
course the resources those processes might need.  Since you don't likely
want to restrict named itself you need to add these options too (though
perhaps with not quite as wide open settings as I show):

options {
	coresize unlimited;
	datasize unlimited;
	files default;
	stacksize unlimited;
};

(note I haven't actually tested this -- but it is my understanding that
these limits are set before named calls setuid())

Unfortunately I don't think you can restrict the per-process CPU time
without affecting the main named (though I suppose a bit of programming
would be all that's necessary to add a 'cpu-time' option).

So, depending on the particular system's specific configuration and
uses, such a unique user is almost completely *unprivileged*, at least
in the terms of unix system "privileges".


From there You can very easily set up an intrusion detection system
using process accounting (set "accounting=YES" in /etc/rc.conf) -- the
only process that should ever be run as that user (other than the main
named itself) is named-xfer.  If you run a cron job every five or ten
minutes to warn you if any other processes appear in the output of
(using the UID in my example above) "sa -u | grep '^[ ]*32771 '" then
you'll be able to catch most any cracker before they can do any real
damage.  If you're not already using process accounting for something
else then just make sure to also run 'sa -sq' periodically (perhaps by
way of the existing hooks in /etc/daily) to truncate the accounting
file, but make sure to re-audit the "yesterday's" accounting file just
to be sure nothing was lost in the roll-over (note too that even that
file is not "atomicly" updated -- 'sa' should write it as it processes
each record and it should truncate the file just after it read the last
record from it, but that's another issue for another day...).

This pre-supposes that you've already got a set of procedures for
monitoring and responding to any alerts generated by such an intrusion
detection system, but of course you already do, right?  :-)

Obviously running chroot'ed is better in a generic sense, but it's very
difficult to generalise on whether or not the relative reduction in risk
is worth the added complexity of the resulting configuration since it
really depends entirely on the specific environment it is done in.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>