PERFORCE change 24010 for review

Chris Costello chris at
Tue Jan 21 04:21:02 GMT 2003

Change 24010 by chris at chris_holly on 2003/01/20 20:20:47

	Rewrite the preface.
	Introducing the introduction.  Define a few terms and set the tone
	for the rest of the document.

Affected files ...

.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/sec-arch/book.sgml#4 edit

Differences ...

==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/sec-arch/book.sgml#4 (text+ko) ====

@@ -35,6 +35,10 @@
 <!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based
+<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page
 <!ENTITY % not.published "INCLUDE">
 <!ENTITY % chapters SYSTEM "chapters.ent">
@@ -143,63 +147,130 @@
       <para>This document illustrates the security architecture of the
-        FreeBSD operating system, its strengths and weaknesses, and
-        addresses important points in regards to secure application
-        programming, using common sense and FreeBSD library features
-        in order to keep one step ahead of application-related
-        security holes.</para>
+        FreeBSD operating system.  The information within this
+        document is intended to provide developers with a breakdown of
+        each system security mechanism, its intended role, its
+        semantics, and its application in the operating system.</para>
   <preface id="preface">
-    <bridgehead id="preface-audience" renderas="sect1">Intended
-      Audience</bridgehead>
+    <section id="audience">
+      <title>This Book's Audience</title>
-    <para>The FreeBSD Security Architecture handbook is intended for
-      system administrators and application programmers seeking full
-      use of FreeBSD's security features, as well as beginning
-      programmers in search of a guide for proper and secure
-      programming.</para>
+      <para>This book is primarily targeted at system developers in an
+        effort to reduce the chances of conflict of interest and
+        potential for security-related bugs in the development of the
+        system, and to increase overall development productivity.  It
+        is not intended as a tutorial for applications developers
+        wishing to minimize the potential for exploits; the
+        &man.sprog.7; manual page is intended to serve that
+        purpose.</para>
+    </section>
-  <part id="traditional-mechanisms">
-    <title>Traditional Security Mechanisms</title>
+  <part id="introduction">
+    <title>Introduction</title>
-      <para>This part of the FreeBSD Security Architecture handbook
-        involves the implementation and their intrinsic roles in the
-        FreeBSD security architectures.  Among other things, the
-        reader will be able to understand:</para>
+      <para>This part of the FreeBSD Security Architecture Handbook
+        sets forth a few definitions and conventions that will be used
+        throughout this publication.  While security is a fairly
+        general concept, it and many of its associated terms will be
+        used in a very specific manner, largely consistent with the
+        definitions used by those who implement and maintain the
+        FreeBSD security architecture.</para>
+    </partintro>
+    <chapter id="">
+      <title>Security Defined</title>
+      <para>System security is often looked at as having the quality
+        of being inaccessible by unauthorized users.  Application
+        security is looked at as having the quality of being able to
+        handle any sort of input, regardless of validity.  Network
+        security is considered as having a fortress-like
+        impenetrability from the perspective of an outside
+        observer.</para>
+      <para>The common thread in all of these definitions is
+        essentially that security is the state of functioning as
+        intended.  Those that should have access to various files in
+        the system do, and those that should not do not.  Those that
+        should have access to the network have it, and those that
+        should not do not.</para>
+      <para><emphasis>Security, therefore, is defined as the
+          enforcement of the appropriate use of system
+          resources.</emphasis>  The implementation may enforce this
+        arbitrarily and may have its own ideas on what
+        <quote>appropriate</quote> is, but generally,
+        <quote>appropriate</quote> means that resources are protected
+        in a manner favoring privacy and the overall well-being of the
+        system.</para>
+    </chapter>
+    <chapter id="">
+      <title>Security-Related Definitions</title>
+      <para>Aside from <quote>security,</quote> this document will
+        make reference to other terms which must be clearly defined.
+        These terms will be used in the strictest sense of the
+        definitions set forth below.</para>
+      <section id="">
+        <title>Security Policy</title>
-      <itemizedlist>
-        <listitem>
-          <para>Traditional UNIX file access modes and ownership,
-            known as Discretionary Access Control, or
-            <acronym>DAC</acronym></para>
-        </listitem>
+        <para>While <quote>security</quote> is defined as
+          <emphasis>the enforcement of the appropriate use of system
+            resources</emphasis>, <quote>security policy</quote> is
+          defined as <emphasis>the set of rules that determine what
+            constitutes <quote>appropriate</quote></emphasis>.  These
+          rules can usually be laid out in a similar fashion to a
+          standard or RFC document: <quote>this resource MUST be used
+            in this fashion only</quote>, <quote>this resource MUST
+            NOT be used in this fashion</quote>, etc.</para>
-        <listitem>
-          <para>The super-user model</para>
-        </listitem>
+        <para>The FreeBSD operating system does not specify one single
+          security policy.  Rather, a conglomeration of policies
+          specially tailored to specific <emphasis>classes</emphasis>
+          of resources, such as network-related resources, virtual
+          memory resources, file system resources, and system uses,
+          comes together to form the overall FreeBSD security
+          architecture.</para>
-        <listitem>
-          <para><emphasis>This list is a work in
-              progress.</emphasis></para>
-        </listitem>
-      </itemizedlist>
-    </partintro>
+        <para>Security policies are found in a variety of forms.
+          <emphasis>DAC</emphasis>, on file system objects,
+          <emphasis>MAC</emphasis>, on all system subjects and
+          objects.</para>
+      </section>
-    &chap.traditional.unixdac;
-    &chap.traditional.superuser;
-  </part>
+      <section
+               id="">
+        <title>Resource Classifications</title>
-  <part id="security-concepts">
-    <title>Essential System Security Concepts</title>
+        <para>This document classifies system resources into
+          <emphasis>subjects</emphasis> and
+          <emphasis>objects</emphasis>.  Most simply, a
+          <emphasis>subject</emphasis> is something that performs some
+          action.  Examples of subjects might be processes, sockets,
+          and pipes.  Logically, an <emphasis>object</emphasis> is
+          something that has some action performed on it.  Examples of
+          objects might be file system objects, devices, network
+          interfaces, processes, and processes.</para>
-    &chap.concepts.unix;
-    &chap.concepts.trusted;
+        <para>The overlap in the examples for subjects and objects is
+          intentional&mdash;it emphasizes the point that due to the
+          principle that subjects might perform some action on one
+          another, then in having some action performed on it, that
+          subject must then be an object.  It is advised that the
+          reader does not make the mistake of equating
+          <emphasis>subject</emphasis> with
+          <emphasis>person</emphasis>.</para>
+      </section>
+    </chapter>
To Unsubscribe: send mail to majordomo at
with "unsubscribe trustedbsd-cvs" in the body of the message

More information about the trustedbsd-cvs mailing list