Date: Mon, 26 Jul 1999 06:54:57 +1000 From: Sue Blake <sue@welearn.com.au> To: security@freebsd.org Subject: Re: sandbox?? Message-ID: <19990726065455.N7324@welearn.com.au> In-Reply-To: <19990725214712.F14954@daemon.ninth-circle.org>; from Jeroen Ruigrok/Asmodai on Sun, Jul 25, 1999 at 09:47:12PM %2B0200 References: <19990726040233.E7349@welearn.com.au> <19990725214712.F14954@daemon.ninth-circle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <sue@welearn.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990726065455.N7324>