Date: Mon, 20 Jan 2003 20:21:02 -0800 (PST) From: Chris Costello <chris@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 24010 for review Message-ID: <200301210421.h0L4L2Td000610@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=24010 Change 24010 by chris@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@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301210421.h0L4L2Td000610>