Date: Sun, 25 Jul 1999 11:36:49 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Sue Blake <sue@welearn.com.au> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? Message-ID: <199907251836.LAA41121@apollo.backplane.com> References: <19990726040233.E7349@welearn.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
A sandbox is a security term. It can mean two things:
* A process which is placed inside a set of virtual walls that are
designed to prevent someone who breaks into the process from being
able to break into the wider system.
The process is said to be able to "play" inside the walls. That is,
nothing the process does in regards to executing code is supposed to
be able to breech the walls so you do not have to do a detailed audit
of its code to be able to say certain things about its security.
The walls might be a userid, for example. This is the definition used
in the security and named man pages.
Take the 'ntalk' service, for example (see /etc/inetd.conf). This
service used to run as userid root. Now it runs as userid tty. The
tty user is a sandbox desiegned to make it more difficult for someone
who has successfully hacked into the system via ntalk from being
able to hack beyond that user id.
* A process which is placed inside a simulation of the machine. This
is more hard-core. Basically it means that someone who is able to
break into the process may believe that he can break into the wider
machine but is, in fact, only breaking into a simulation of that
machine and not modifying any real data.
The most common way to accomplish this is to build a simulated
environment in a subdirectory and then run the processes in that
directory chroot'd (i.e. "/" for that process is this directory, not
the real "/" of the system).
Another common use is to mount an underlying filesystem read-only and
then create a filesystem layer on top of it that gives a process a
seemingly writeable view into that filesystem. The process may believe
it is able to write to those files, but only the process sees the
effects -- other processes in the system do not, necessarily.
An attempt is made to make this sort of sandbox so transparent that
the user (or hacker) does not realize that he is sitting in it.
UNIX implements two core sanboxes. One is at the process level, and one
is at the userid level.
Every UNIX process is completely firewalled off from every other UNIX
process. One process can modify the address space of another. This is
unlike Windows where a process can easily overwrite the address space of
any other, leading to a crash.
A UNIX process is owned by a patricular userid. If the userid is not
the root user, it serves to firewall the process off from processes owned
by other users. The userid is also used to firewall off on-disk data.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Hi clever people
:
:Nobody seems to be confident about the answer to my post to -questions.
:Below is the only public answer. It is typical of many private answers
:I received from otherwise knowledgeable people willing to make a
:partial educated guess but not willing to expose their ignorance
:publicly. They're all keen to know whatever I can find out :-)
:
: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.
:
:As you see it is far from the complete 4-5 part answer I need. The
:problem that I see is that our named.conf refers to this sandbox thing,
:implies that it is actually the default method for BIND in FreeBSD (I
:don't think it is though), and directs the user to man pages which
:don't provide the necessary info to be able to confidently
:(un)implement it.
:
: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.
:
:(Email cc would be appreciated)
:
:--
:
:Regards,
: -*Sue*-
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907251836.LAA41121>