On Tue, Jan 30, 2001 at 04:27:12PM -0500, Greg A. Woods wrote:
> "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

Swell, so do I:

uriel:work/bind-9.1.0# grep named /etc/passwd /etc/group
/etc/passwd:named:*:14:14:named chroot user:/chroot/named:/sbin/nologin
/etc/group:named:*:14:root,gr

... but that has nothing to do with the chroot issue, it has to do
with directly usable buffer overflows in a named running as root.

> 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.

Stop right there. They've just *drastically* elevated their access
to your system.

Who cares if they can't write--they now have a working shell, which
means they can exploit other problems that you may not have fixed
because you deemed them not to be remote exploits and "you don't let
anyone else on the system". No cron-based IDS as you describe (which
is technically not an IDS but a log checker) is sufficient to stop
this, since it's all going to happen in under thirty seconds, after
which you can be damn sure their tracks will be covered if they
actually want to keep your system.

This is the kind of thinking that screwed over a lot of folks who
trusted RedHat 6.2.

> 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
[etc]

Uh, that's a lot of work that a chroot fixes much more efficiently
by completely hiding the rest of the system from the attacker. I'm
not happy if I've got somebody in my named chroot (especially since
it means he can see zone files I allow only two hosts to transfer),
but I'd rather he were there than traipsing around my system.

> 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.

Not true at all. Allowing an *entirely* unprivileged user even just
a shell running as a mostly unprivileged local user who can see
"only world-readable" files is horrendously worse than keeping them
in a chroot jail. There are no two ways around this, and if you
can't see that, I'm scared.

The point of not running named as root is so that script kiddie
tools that deliver a payload directly through a buffer overflow in
BIND won't execute their payload as root. The point of running
named in a chroot is so that a buffer overflow that is exploited
to gain a shell doesn't let the remote attacker see anything else
of the system *but* BIND. Neither is a substitute for the other.
Period.

       ~ g r @ eclipsed.net