From owner-p4-projects  Fri Jan 24 15:53: 8 2003
Delivered-To: p4-projects@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id E8F6F37B405; Fri, 24 Jan 2003 15:53:05 -0800 (PST)
Delivered-To: perforce@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6A5E837B401
	for <perforce@freebsd.org>; Fri, 24 Jan 2003 15:53:05 -0800 (PST)
Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0934343ED8
	for <perforce@freebsd.org>; Fri, 24 Jan 2003 15:53:05 -0800 (PST)
	(envelope-from chris@freebsd.org)
Received: from repoman.freebsd.org (localhost [127.0.0.1])
	by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id h0ONr4bv030473
	for <perforce@freebsd.org>; Fri, 24 Jan 2003 15:53:04 -0800 (PST)
	(envelope-from chris@freebsd.org)
Received: (from perforce@localhost)
	by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h0ONr498030470
	for perforce@freebsd.org; Fri, 24 Jan 2003 15:53:04 -0800 (PST)
Date: Fri, 24 Jan 2003 15:53:04 -0800 (PST)
Message-Id: <200301242353.h0ONr498030470@repoman.freebsd.org>
X-Authentication-Warning: repoman.freebsd.org: perforce set sender to chris@freebsd.org using -f
From: Chris Costello <chris@FreeBSD.org>
Subject: PERFORCE change 24156 for review
To: Perforce Change Reviews <perforce@freebsd.org>
Sender: owner-p4-projects@FreeBSD.ORG
Precedence: bulk
List-ID: <p4-projects.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20p4-projects>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20p4-projects>
X-Loop: FreeBSD.ORG

http://perforce.freebsd.org/chv.cgi?CH=24156

Change 24156 by chris@chris_holly on 2003/01/24 15:53:02

	o Clean up grammar a bit.
	o Change the title of "Resource Classifications" to "Subjects and
	  Objects"
	o Clarify the definition of Security Policy.  Adam Migus reports that
	  some NAI meeting came to the conclusion that we should not refer
	  to security policies as resource managers.

Affected files ...

.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/sec-arch/book.sgml#6 edit
.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/sec-arch/introduction/security-defined.sgml#3 edit
.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/sec-arch/introduction/security-definitions.sgml#2 edit

Differences ...

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


==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/sec-arch/introduction/security-defined.sgml#3 (text+ko) ====

@@ -14,7 +14,7 @@
     that should not do not.  Those that should have access to the
     network have it, and those that should not do not.  Enforcing
     <emphasis>intent</emphasis> is the job of the security policy,
-    configured by the system administrator.</para>
+    as configured by the system administrator.</para>
 
   <para><emphasis>Security, therefore, is defined as the enforcement
       of a particular set of security policies.</emphasis>  The

==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/sec-arch/introduction/security-definitions.sgml#2 (text+ko) ====

@@ -9,15 +9,16 @@
   <section id="introduction.security-definitions.security-policy">
     <title>Security Policy</title>
 
-    <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>
+    <para><quote>Security</quote> is defined as <emphasis>the
+        enforcement of a particular set of security
+        policies</emphasis>.  <quote>Security policy</quote>, then, is
+      defined as <emphasis>the set of rules that determine which
+        subject/object interactions to permit, and which
+        subject/object interactions to deny</emphasis>.  These rules
+      can usually be laid out in a similar fashion to a standard or
+      RFC document: <quote>this object MUST be acted upon in this
+        fashion only</quote>, <quote>this subject MUST NOT act upon
+        this object in this fashion</quote>, etc.</para>
 
     <para>The FreeBSD operating system does not specify one single
       security policy.  Rather, a conglomeration of policies
@@ -33,10 +34,12 @@
       objects.</para>
   </section>
 
+  <!-- XXX: Can we come up with a better name for this section? -->
   <section
-           id="introduction.security-definitions.resource-classification">
-    <title>Resource Classifications</title>
+           id="introduction.security-definitions.classifications">
+    <title>Subjects and Objects</title>
 
+    <!-- XXX: Does this resource reference also need to go? -->
     <para>This document classifies system resources into
       <emphasis>subjects</emphasis> and
       <emphasis>objects</emphasis>.  Most simply, a

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe p4-projects" in the body of the message