Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jul 1999 15:41:29 -0700 (PDT)
From:      jobaldwi@vt.edu
To:        freebsd-gnats-submit@freebsd.org
Subject:   docs/12823: [PATCH] New FAQ Entry: "What is a sandbox?"
Message-ID:  <19990726224129.6B0E2150B9@hub.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         12823
>Category:       docs
>Synopsis:       [PATCH] New FAQ Entry: "What is a sandbox?"
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 26 15:50:00 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     John Baldwin
>Release:        3.2-STABLE
>Organization:
>Environment:
n/a
>Description:
This patch adds a new question to the sys admin portion of the FAQ.
>How-To-Repeat:

>Fix:
patch:

Index: admin.sgml
===================================================================
RCS file: /usr/cvs/doc/FAQ/admin.sgml,v
retrieving revision 1.25
diff -u -r1.25 admin.sgml
--- admin.sgml  1999/07/11 18:03:59     1.25
+++ admin.sgml  1999/07/26 22:38:46
@@ -969,6 +969,74 @@
      # return
      # exit
 </verb>
-     
+
+    <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 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.
+       </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 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>


>Release-Note:
>Audit-Trail:
>Unformatted:


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?19990726224129.6B0E2150B9>