Attachment 5336 Details for Bug 12823 – file.diff

[patch] file.diff

file.diff (text/plain), 3.46 KB, created by jobaldwi on 1999-07-26 23:50:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: jobaldwi

Created: 1999-07-26 23:50:00 UTC

Size: 3.46 KB

patch

obsolete

>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>
>+
>+ &quot;Sandbox&quot; is a security term. It can mean two things:
>+
>+ <itemize>
>+ <item>
>+ 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.
>+ </item>
>+
>+ <item>
>+ 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
>+ &dash; 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.
>+ </item>
>+ </itemize>
>+
>+ 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.
>+
> </sect>

Actions: View | Diff

Attachments on bug 12823: 5336