From owner-freebsd-security  Mon Dec 21 07:30:22 1998
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA05506
          for freebsd-security-outgoing; Mon, 21 Dec 1998 07:30:22 -0800 (PST)
          (envelope-from owner-freebsd-security@FreeBSD.ORG)
Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA05487
          for <security@FreeBSD.ORG>; Mon, 21 Dec 1998 07:30:18 -0800 (PST)
          (envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 18929 invoked by uid 1001); 21 Dec 1998 15:30:14 +0000 (GMT)
To: eivind@yes.no
Cc: des@flood.ping.uio.no, dillon@FreeBSD.ORG, security@FreeBSD.ORG
Subject: Re: cvs commit: src/etc rc.conf
In-Reply-To: Your message of "Mon, 21 Dec 1998 16:11:10 +0100"
References: <19981221161110.E14124@follo.net>
X-Mailer: Mew version 1.05+ on Emacs 19.34.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Mon, 21 Dec 1998 16:30:14 +0100
Message-ID: <18927.914254214@verdi.nethelp.no>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> > If named is run in the sandbox, it will have to be restarted every
> > time an interface comes up after being down an hour or more - less if
> > you lower interface-interval in /etc/namedb/named.conf, which you
> > probably will if you run a caching nameserver on a box that has a
> > dynamic IP address (e.g. a dialout gateway). It will also complain
> > loudly every time it receives any of SIGHUP, SIGINT, SIGILL, SIGSYS or
> > SIGTERM unless you perform the appropriate named.conf magic to move
> > the pid and dump files to a directory writeable by bind:bind.
> > 
> > OBTW, the /etc/named/s/ hack is just that - a hack, and an ugly one at
> > that.
> > 
> > You'll just have to come to terms with the fact that named needs
> > privs.
> 
> ... unless you do a series of small modifications.  It is not as if
> rescanning the interfaces is a _large_ task, or one that couldn't be
> done by a forked out half of named, decreasing the chance of a problem
> spreading.

named, possibly with some small modifications, could easily run in the
sandbox for a fairly large class of important configurations, namely
the ISP which runs primary and/or secondary service for thousands of
domains on one box - and this box is a dedicated name server.

(On such a box, interfaces change rarely if at all - so I would be
quite comfortable with removing the code for rescanning of interfaces.
An initial scan would still be necessary.)

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message