From owner-p4-projects Mon Jan 20 20:21:10 2003 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id D176B37B406; Mon, 20 Jan 2003 20:21:04 -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 6661937B405 for ; Mon, 20 Jan 2003 20:21:04 -0800 (PST) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9313E43F1E for ; Mon, 20 Jan 2003 20:21:03 -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 h0L4L3bv000613 for ; Mon, 20 Jan 2003 20:21:03 -0800 (PST) (envelope-from chris@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h0L4L2Td000610 for perforce@freebsd.org; Mon, 20 Jan 2003 20:21:02 -0800 (PST) Date: Mon, 20 Jan 2003 20:21:02 -0800 (PST) Message-Id: <200301210421.h0L4L2Td000610@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to chris@freebsd.org using -f From: Chris Costello Subject: PERFORCE change 24010 for review To: Perforce Change Reviews Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 @@ +%man; + @@ -143,63 +147,130 @@ 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. + 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. Preface - Intended - Audience +
+ This Book's Audience - 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. + 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. +
- - Traditional Security Mechanisms + + Introduction - 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: + 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. + + + + Security Defined + + 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. + + 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. + + Security, therefore, is defined as the + enforcement of the appropriate use of system + resources. The implementation may enforce this + arbitrarily and may have its own ideas on what + appropriate is, but generally, + appropriate means that resources are protected + in a manner favoring privacy and the overall well-being of the + system. + + + + Security-Related Definitions + + Aside from security, 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. + +
+ Security Policy - - - Traditional UNIX file access modes and ownership, - known as Discretionary Access Control, or - DAC - + While security is defined as + the enforcement of the appropriate use of system + resources, security policy is + defined as the set of rules that determine what + constitutes appropriate. These + rules can usually be laid out in a similar fashion to a + standard or RFC document: this resource MUST be used + in this fashion only, this resource MUST + NOT be used in this fashion, etc. - - The super-user model - + The FreeBSD operating system does not specify one single + security policy. Rather, a conglomeration of policies + specially tailored to specific classes + 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. - - This list is a work in - progress. - - - + Security policies are found in a variety of forms. + DAC, on file system objects, + MAC, on all system subjects and + objects. +
- &chap.traditional.unixdac; - &chap.traditional.superuser; - +
+ Resource Classifications - - Essential System Security Concepts + This document classifies system resources into + subjects and + objects. Most simply, a + subject is something that performs some + action. Examples of subjects might be processes, sockets, + and pipes. Logically, an object is + something that has some action performed on it. Examples of + objects might be file system objects, devices, network + interfaces, processes, and processes. - &chap.concepts.unix; - &chap.concepts.trusted; + 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 + subject with + person. +
+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message