From owner-freebsd-doc Mon Jul 26 15:52:19 1999 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id BF4BD14C40 for ; Mon, 26 Jul 1999 15:52:16 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA38628; Mon, 26 Jul 1999 15:50:01 -0700 (PDT) (envelope-from gnats@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 To: freebsd-gnats-submit@freebsd.org X-Send-Pr-Version: www-1.0 Subject: docs/12823: [PATCH] New FAQ Entry: "What is a sandbox?" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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 - + + + What is a sandbox? + +

"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. + >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message