From owner-freebsd-security Sun Jul 25 22:48: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (Postfix) with ESMTP id 6B79514C36 for ; Sun, 25 Jul 1999 22:47:58 -0700 (PDT) (envelope-from jkb@shell6.ba.best.com) Received: (from jkb@localhost) by shell6.ba.best.com (8.9.3/8.9.2/best.sh) id WAA27881; Sun, 25 Jul 1999 22:47:07 -0700 (PDT) Message-ID: <19990725224707.A27741@best.com> Date: Sun, 25 Jul 1999 22:47:07 -0700 From: "Jan B. Koum " To: "E.L." , Sue Blake Cc: security@FreeBSD.ORG Subject: Re: sandbox?? References: <19990726040233.E7349@welearn.com.au> <19990725214712.F14954@daemon.ninth-circle.org> <19990726065455.N7324@welearn.com.au> <379BF011.6A7610B@osi-technologies.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <379BF011.6A7610B@osi-technologies.com>; from E.L. on Mon, Jul 26, 1999 at 01:20:17AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Securing DNS (OpenBSD/FreeBSD Version): http://www.psionic.com/papers/dns/dns-openbsd/ -- Yan On Mon, Jul 26, 1999 at 01:20:17AM -0400, "E.L." wrote: > If you want an example, see openbsd 2.5(www.openbsd.org) where the default > config for named uses this sandbox concept. > EX > > Sue Blake wrote: > > > On Sun, Jul 25, 1999 at 09:47:12PM +0200, Jeroen Ruigrok/Asmodai wrote: > > > [ Please direct all follow-ups to security@freebsd.org as the topic fits > > > that list. Reply-To set ] > > > > > > * Sue Blake (sue@welearn.com.au) [990725 20:29]: > > > > > > > > On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: > > > > > In article <19990719212431.D300@welearn.com.au>, > > > > > Sue Blake wrote: > > > > > : Could someone tell me what is a sandbox, what does it do, how does it > > > > > : work, how do I use it, or where is it documented? > > > > > : named(8) and security(8) seem to assume one already knows. > > > > > > > > > > It's a generic term. It refers to a restricted environment in > > > > > which something is to be done. Exactly how a sandbox is > > > > > implemented depends on the specific application. > > > > > > > > If nobody understands how this sandbox thing works, we should change > > > > the named.conf that we supply. If somebody does, then they or someone > > > > who they teach (me if really necessary) needs to document it so that > > > > anyone seriously interested can figure it out on thier own (or at least > > > > accept the defaults with confidence), and then change at least the > > > > named.conf to point to that info. It sounds like a good idea, worth > > > > giving people the resources to use it. > > > > > > Basically one has to depict a sandbox like a, erhm, sandbox ;) > > > > > > It's a dug hole with raised low stone walls to keep kindergarten aged kids > > > within the sandbox to play with the sand, etc. > > > > But ironically, in this case (named) we want to keep the FreeBSD "kids" > > out of the sandbox until they are sure they know how to implement it :-) > > > > Either we need documentation (and/or pointers) for the background > > theory and a guide to its actual implementation for named in FreeBSD to > > encourage people to use it, or we need to disambiguate and discourage > > its use in named.conf while providing non-sandbox examples for > > secondaries in the new style config file that the "kids" can learn from > > without confusion. After some good feedback on sandboxes, it seems that > > the latter is the more appropriate, particularly in view of the > > concurrent scarcity of documentation for BIND 8. > > > > Thanks for the security explanation. A lot of people seem to be > > interested in this but too afraid to ask :-) There must be a good book > > that explains it all. Anyone know? It would almost be worth buying and > > studying another book in order to be eligible to ask questions on how > > to use the examples provided in the new named.conf :-) Better still, if > > it can be condensed into something digestible by newbies I might try > > writing a summary introduction with examples, recommending either for > > or against its use by learners. > > > > -- > > > > Regards, > > -*Sue*- > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message