From nobody@FreeBSD.ORG Mon Jul 26 15:41:29 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 6B0E2150B9; Mon, 26 Jul 1999 15:41:29 -0700 (PDT)
Message-Id: <19990726224129.6B0E2150B9@hub.freebsd.org>
Date: Mon, 26 Jul 1999 15:41:29 -0700 (PDT)
From: jobaldwi@vt.edu
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: [PATCH] New FAQ Entry: "What is a sandbox?"
X-Send-Pr-Version: www-1.0

>Number:         12823
>Category:       docs
>Synopsis:       [PATCH] New FAQ Entry: "What is a sandbox?"
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jesusr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 26 15:50:00 PDT 1999
>Closed-Date:    Wed Jul 28 05:37:01 PDT 1999
>Last-Modified:  Wed Jul 28 05:44:49 PDT 1999
>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:
Responsible-Changed-From-To: freebsd-doc->jesusr 
Responsible-Changed-By: jesusr 
Responsible-Changed-When: Mon Jul 26 16:10:53 PDT 1999 
Responsible-Changed-Why:  
Working it. 

From: Sue Blake <sue@welearn.com.au>
To: jobaldwi@vt.edu
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: docs/12823: [PATCH] New FAQ Entry: "What is a sandbox?"
Date: Tue, 27 Jul 1999 09:26:05 +1000

 On Mon, Jul 26, 1999 at 03:41:29PM -0700, jobaldwi@vt.edu wrote:
 
 > +
 > +      <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.
 > +
 
 Oops, wasn't this identified as a typo? IIRC a "not" was omitted:
 One process cannot modify the address space of another.
 
 
 
 -- 
 
 Regards,
         -*Sue*-
  
  
 

From: John Baldwin <jobaldwi@vt.edu>
To: Sue Blake <sue@welearn.com.au>
Cc: freebsd-gnats-submit@FreeBSD.ORG, jobaldwi@smtp2.erols.com
Subject: Re: docs/12823: [PATCH] New FAQ Entry: "What is a sandbox?"
Date: Mon, 26 Jul 1999 19:47:32 -0400 (EDT)

 On 26-Jul-99 Sue Blake wrote:
 > On Mon, Jul 26, 1999 at 03:41:29PM -0700, jobaldwi@vt.edu wrote:
 > 
 >> +
 >> +      <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.
 >> +
 > 
 > Oops, wasn't this identified as a typo? IIRC a "not" was omitted:
 > One process cannot modify the address space of another.
 
 Yes..  *hangs head*...
 
 > Regards,
 >         -*Sue*-
 
 ---
 
 John Baldwin <jobaldwi@vt.edu> -- http://members.freedomnet.com/~jbaldwin/
 PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc
 "Power Users Use the Power to Serve!"  -  http://www.freebsd.org
 
State-Changed-From-To: open->closed 
State-Changed-By: jesusr 
State-Changed-When: Wed Jul 28 05:37:01 PDT 1999 
State-Changed-Why:  
Commited, thanks! 
. 
>Unformatted:
