os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Added: What is a sandbox?

Browse source 
Original text by: dillon@apollo.backplane.com

PR:		docs/12823
Submitted by:	jobaldwi@vt.edu
This commit is contained in:
Jesus Rodriguez Cuesta 1999-07-28 12:36:46 +00:00
parent e9b420e0d1
commit e49e431805
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=5260
1 changed files with 70 additions and 2 deletions

72
FAQ/admin.sgml
View file

@ -1,4 +1,4 @@
<!-- $Id: admin.sgml,v 1.25 1999-07-11 18:03:59 roberto Exp $ -->
<!-- $Id: admin.sgml,v 1.26 1999-07-28 12:36:46 jesusr Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect>
@ -970,5 +970,73 @@ cd /cdrom/bin
# exit
</verb>
</sect>
<sect1>
<heading>What is a sandbox?</heading>
<p>&quot;Sandbox&quot; is a security term. It can mean two things:
<itemize>
<item>
<p>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.
<p>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.
<p>The walls might be a userid, for example. This is the
definition used in the security and named man pages.
<p>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 designed 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.
</item>
<item>
<p>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.
<p>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).
<p>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
&dash; other processes in the system do not, necessarily.
<p>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.
</item>
</itemize>
<p>UNIX implements two core sanboxes. One is at the process
level, and one is at the userid level.
<p>Every UNIX process is completely firewalled off from every
other UNIX process. One process can not 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.
<p>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.
</sect>