From owner-freebsd-security Sun Jul 25 22:22:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from news1.cio.med.va.gov (news1.cio.med.va.gov [205.230.50.17]) by hub.freebsd.org (Postfix) with ESMTP id 0321215291 for ; Sun, 25 Jul 1999 22:22:30 -0700 (PDT) (envelope-from lluisma@osi-technologies.com) Received: from osi-technologies.com (rems8.cio.med.va.gov [204.176.52.23]) by news1.cio.med.va.gov (8.8.8+Sun/8.8.8) with ESMTP id BAA25865; Mon, 26 Jul 1999 01:14:58 -0400 (EDT) Message-ID: <379BF011.6A7610B@osi-technologies.com> Date: Mon, 26 Jul 1999 01:20:17 -0400 From: "E.L." X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message