PERFORCE change 24010 for review
Chris Costello
chris at freebsd.org
Tue Jan 21 04:21:02 GMT 2003
http://perforce.freebsd.org/chv.cgi?CH=24010
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
Extension//EN"[
+<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page
+Entities//EN">
+%man;
+
<!ENTITY % not.published "INCLUDE">
<!ENTITY % chapters SYSTEM "chapters.ent">
@@ -143,63 +147,130 @@
<abstract>
<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>
</abstract>
</bookinfo>
<preface id="preface">
<title>Preface</title>
- <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>
</preface>
- <part id="traditional-mechanisms">
- <title>Traditional Security Mechanisms</title>
+ <part id="introduction">
+ <title>Introduction</title>
<partintro>
- <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="introduction.security-defined">
+ <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="introduction.security-definitions">
+ <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="introduction.security-definitions.security-policy">
+ <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="introduction.security-definitions.resource-classification">
+ <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—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>
</part>
</book>
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message
More information about the trustedbsd-cvs
mailing list