Merging the FAQ -> handbook, build time options, proof of concept patch
Tom Rhodes
trhodes at FreeBSD.org
Thu Dec 2 18:26:33 UTC 2004
Hey gang,
Ok, this damn FAQ issue needs to be put to rest right now. About
a year (more/less?) ago, Nik and I think Murray were discussing
placing FAQ entries into the handbook, at the end of the chapters
and filtering them out with some make(1) magic. After reading
the BOF comments (compaints more or less) about how we never
discussed the FAQ, along with a thread on it from last night;
I whipped up the following patch.
Here is the gist of what is going on here:
Relevent information from the FAQ get's merged into the chapters
they should be in.
They are added with the WITH_FAQ=yes make variable. If that is
no specified, the FAQ portions are not built.
Finally, everyone take a section/area of the FAQ and either
update and move it to the handbook, or remove it if irrelivent.
While I know some things will not go anywhere in the handbook,
like the funnies, I propose a different chapter where that
stuff can be dropped into.
Comments and suggestions are welcome here; NOTE: Simon gets a thank
you for a quick hint on the scheme. Again, proof of concept patch,
I have only used one FAQ entry here. Lets get the ball rolling
and do something rather than bitch about doing something. Thank
you in advance!
--
Tom Rhodes
diff -ruN handbook/Makefile handbook.new/Makefile
--- handbook/Makefile Thu Dec 2 13:16:02 2004
+++ handbook.new/Makefile Thu Dec 2 13:15:41 2004
@@ -8,6 +8,10 @@
#
# Handbook-specific variables
#
+# WITHOUT_FAQ Build the handbook without the FAQ appended to the
+# end of each chapter.
+#
+#
# WITH_PGPKEYS The print version of the handbook only prints PGP
# fingerprints by default. If you would like for the
# entire key to be displayed, then set this variable.
@@ -214,6 +218,10 @@
#
.if defined(WITH_PGPKEYS)
JADEFLAGS+= -V withpgpkeys
+.endif
+
+.if defined(WITH_FAQ)
+JADEFLAGS+= -ifilter.faq
.endif
.for p in ftp cvsup
diff -ruN handbook/book.sgml handbook.new/book.sgml
--- handbook/book.sgml Thu Dec 2 13:16:02 2004
+++ handbook.new/book.sgml Thu Dec 2 13:15:41 2004
@@ -45,6 +45,8 @@
<!ENTITY % chap.freebsd-glossary "IGNORE">
<!ENTITY % chap.mac "IGNORE">
+<!ENTITY % filter.faq "IGNORE">
+
<!ENTITY % pgpkeys SYSTEM "../../../share/pgpkeys/pgpkeys.ent"> %pgpkeys;
]>
diff -ruN handbook/security/chapter.sgml handbook.new/security/chapter.sgml
--- handbook/security/chapter.sgml Thu Dec 2 13:16:03 2004
+++ handbook.new/security/chapter.sgml Thu Dec 2 13:15:40 2004
@@ -7568,6 +7568,99 @@
</calloutlist>
</sect2>
</sect1>
+
+
+<![ %filter.faq; [
+ <sect1 id="security-faq">
+ <title>General Security FAQ</title>
+
+ <qandaset>
+ <qandaentry>
+ <question id="sandbox">
+ <para>What is a sandbox?</para>
+ </question><answer>
+
+ <para><quote>Sandbox</quote> is a security term. It can
+ mean two things:</para>
+
+ <itemizedlist>
+ <listitem>
+
+ <para>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.</para>
+
+ <para>The process is said to be able to
+ <quote>play</quote> 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.</para>
+
+ <para>The walls might be a userid, for example. This is
+ the definition used in the security and named man
+ pages.</para>
+
+ <para>Take the <literal>ntalk</literal> service, for
+ example (see /etc/inetd.conf). This service used to run
+ as userid <username>root</username>. Now it runs as userid
+ <username>tty</username>. The <username>tty</username> 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.</para>
+ </listitem>
+
+ <listitem>
+
+ <para>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.</para>
+
+ <para>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.
+ <filename>/</filename> for that process is this
+ directory, not the real <filename>/</filename> of the
+ system).</para>
+
+ <para>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.</para>
+
+ <para>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.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>&unix; implements two core sandboxes. One is at the
+ process level, and one is at the userid level.</para>
+
+ <para>Every &unix; process is completely firewalled off from every
+ other &unix; process. One process cannot 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.</para>
+
+ <para>A &unix; process is owned by a particular userid. If
+ the userid is not the <username>root</username> 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.</para>
+ </answer>
+ </qandaentry>
+ </qandaset>
+ </sect1>
+]]>
+
</chapter>
<!--
More information about the freebsd-doc
mailing list