PERFORCE change 34992 for review

Robert Watson rwatson at
Fri Jul 25 16:48:46 GMT 2003

Change 34992 by rwatson at rwatson_paprika on 2003/07/25 09:47:47

	First 45 pages of the secarch document; has been following
	me around on my notebook for a while, and it would be a good
	idea to get it in P4 so that when I drop my notebook, it's
	not lost.  The kernel section is doing quite well (VFS and
	networking need work); userspace needs more fleshing out
	generally, especially relating to PAM, NSS, and crypto

Affected files ...

.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/developers-handbook/secarch/chapter.sgml#2 edit

Differences ...

==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/developers-handbook/secarch/chapter.sgml#2 (text+ko) ====

@@ -1,0 +1,2808 @@
+    Copyright (c) 2002, 2003 Networks Associates Technology, Inc.
+    All rights reserved.
+    This software was developed for the FreeBSD Project by Network
+    Associates Laboratories, the Security Research Division of Network
+    Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"),
+    as part of the DARPA CHATS research program.
+    Redistribution and use in source and binary forms, with or without
+    modification, are permitted provided that the following conditions
+    are met:
+    1. Redistributions of source code must retain the above copyright
+       notice, this list of conditions and the following disclaimer.
+    2. Redistributions in binary form must reproduce the above copyright
+       notice, this list of conditions and the following disclaimer in the
+       documentation and/or other materials provided with the distribution.
+    $FreeBSD$
+<chapter id="secarch">
+  <chapterinfo>
+    <authorgroup>
+      <author>
+        <firstname>Robert</firstname>
+        <surname>Watson</surname>
+        <affiliation>
+          <orgname>TrustedBSD Project, Network Associates 
+	    Laboratories</orgname>          
+	  <address><email>rwatson at</email></address>
+	</affiliation>
+      </author>
+    </authorgroup>
+  </chapterinfo>
+  <title>FreeBSD Security Architecture</title>
+  <sect1 id="secarch-copyright">
+    <title>FreeBSD Security Architecture Copyright</title>
+    <para>This software was developed for the FreeBSD Project by Network
+      Associates Laboratories, the Security Research Division of Network
+      Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+      ("CBOSS"), as part of the DARPA CHATS research program.</para>
+    <para>Redistribution and use in source (SGML DocBook) and
+      'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth)
+      with or without modification, are permitted provided that the
+      following conditions are met:</para>
+    <orderedlist>
+      <listitem>
+        <para>Redistributions of source code (SGML DocBook) must
+          retain the above copyright notice, this list of conditions
+          and the following disclaimer as the first lines of this file
+          unmodified.</para>
+      </listitem>
+      <listitem>
+        <para>Redistributions in compiled form (transformed to other
+          DTDs, converted to PDF, PostScript, RTF and other formats)
+          must reproduce the above copyright notice, this list of
+          conditions and the following disclaimer in the documentation
+          and/or other materials provided with the distribution.</para>
+      </listitem>
+    </orderedlist>
+    <important>
+    </important>
+  </sect1>
+  <sect1 id="secarch-synopsis">
+    <title>Synopsis</title>
+    <para>The FreeBSD operating system contains a variety of security
+      elements intended to support secure and reliable system operation.
+      These elements include:</para>
+      <itemizedlist>
+	<listitem><para>Segmented address space to protect kernel
+	  operation from accidental or malicious user process
+	  interference.</para></listitem>
+	<listitem><para>Inter-process memory protections to limit the
+	  impact of buggy or malicious user applications on other
+	  running applications.</para></listitem>
+	<listitem><para>Association of user credentials with processes,
+	  including user identifiers, group list membership, jail virtual
+	  system, and mandatory access control label, supporting a
+	  multi-user environment.</para></listitem>
+	<listitem><para>Privilege model based on a privileged root user
+	  (uid 0)</para></listitem>
+	<listitem><para>Inter-process controls to prevent improper
+	  interference between processes belonging to different users,
+	  as well as to protect processes that undergo privilege level
+	  changes.</para></listitem>
+	<listitem><para>Discretionary file system protections based on
+	  user/group ownership, file permission mask, and file flags.
+	  Optionally, extended discretionary access control list support
+	  on the UFS and UFS2 file systems.
+	  Special file modes to support uid and gid transition on
+	  execution.</para></listitem>
+	<listitem><para>Mapping of network credentials received via
+	  NFS Remote Procedure Calls (RPCs) to local credentials.
+	  Administrative limits, by network address, to NFS services.
+	  </para></listitem>
+	<listitem><para>Discretionary protections on System V IPC
+	  primitives (shared memory, message queues, and semaphores)
+	  based on ownership and permissions.</para></listitem>
+	<listitem><para>Extensible kernel and user access control
+	  through a pluggable MAC Framework, permitting kernel modules
+	  to bind additional security label data to processes and
+	  system objects, and to enforce discretionary or mandatory
+	  policies, including Biba and LOMAC integrity, MLS
+	  confidentiality, and other augmented system security
+	  policies.</para></listitem>
+	<listitem><para>Pluggable Authentication Module (PAM) support
+	  permitting administrators to require appropriate authentication
+	  in a multi-user environment.
+	  Modules support traditional passwords, one-time passwords,
+	  distributed passwords and authentication services such as
+	  KerberosIV and Kerberos5, and support a variety of hardware
+	  authentication tokens.
+	  In addition, modules authorize login access to the system,
+	  provide for accounting, implement password changing, and
+	  enforce password change policies such as password length
+	  requirements.</para></listitem>
+	<listitem><para>Name Service Switch (NSS) support permitting
+	  a variety of local and distributed directory services to
+	  provide account and authentication data.</para></listitem>
+	<listitem><para>A variety of remote access and management
+	  tools with cryptographic protection of network traffic.
+	  </para></listitem>
+      </itemizedlist>
+      <note><para>This revision of the FreeBSD Security Architecture
+	describes the architecture as found in FreeBSD 5.1, and may
+	not accurately describe other versions of the FreeBSD
+	operating system.</para></note>
+  </sect1>
+  <sect1 id="secarch-approach">
+    <title>Approach</title>
+    <para>As a general-purpose, multi-user operating system, FreeBSD
+      includes a number of security elements intended to form the
+      foundation for a secure application environment.
+      This includes basic system integrity, confidentiality, and
+      availability services.
+      This approach is intended to resist attack in a variety of forms,
+      and against a variety of attack methodologies.
+      In the next section, basic security concepts and assumptions are
+      discussed, including the goals of integrity, confidentiality, and
+      availability as addressed by FreeBSD.</para>
+    <para>In general, FreeBSD adopts the same stance as most other
+      operating systems based on the UNIX model: the kernel is isolated
+      from user processes, which represent a variety of programs in
+      execution in isolated address spaces.
+      Processes each carry a process credential, managed by the kernel,
+      describing user and group information for the process, which will
+      be used to authorized access to other kernel objects.
+      Based on the credential and various object properties, several
+      mandatory and discretionary protection models control the
+      interactions between processes, and access by the processes to
+      various system resources (including storage, network
+      communications, etc.)</para>
+    <para>As installed, FreeBSD supports easy communication and
+      collaboration between users, while providing the primitives to
+      prevent inappropriate release or modification of data owned by
+      users.
+      Some users are granted special system administion privileges by
+      virtue of being members of specific groups (such as the "operator"
+      and "wheel" groups); in addition, a special administrative account,
+      "root", is used to manage the system.
+      However, the security primitives and configuration are frequently
+      adapted to support much stronger or fine-grained security
+      deployment requirements, including containment of mutually
+      untrusting processes.</para>
+    <para>FreeBSD also contains a number of extensions permitting
+      greater flexibility and control, including a system
+      partitioning model widely used by ISPs (jail), support
+      for Mandatory Access Control, and extensible access control
+      policies through the MAC Framework.
+      These mechanisms permit administrators to control the flow of
+      information in systems in a variety of ways, including using the
+      MLS mandatory sensitivity policy, and the Biba integrity policy.
+      These capabilities are similar to those found in many commercial
+      trusted operating systems, and permit FreeBSD to be used 
+      in environments less reminiscent of the time-sharing
+      systems from which the UNIX access control requirements are
+      derived.
+      Making use of these primitives permits the administrator to reduce
+      their level of trust in user accounts on the system, limiting the
+      consequences of compromise of individual user accounts or
+      services.</para>
+    <para>In recognition of the importance of networks and network
+      infrastructure, FreeBSD provides a variety of remote login
+      services, as well as advanced cryptographic protocols used to
+      protect the integrity of these services.</para>
+  </sect1>
+  <sect1 id="secarch-concepts">
+    <title>Security Architecture Concepts</title>
+    <para>FreeBSD is a multi-tasking multi-user operating system, serving
+      in a variety of environments with a variety of security requirements.
+      Common deployment environments include single-user or multi-user
+      workstations, large-scale ISP environments, web or file server
+      clusters, and high-end embedded network appliances including
+      network-attached storage, routers, and firewalls.
+      The FreeBSD operating system combines many of the strongest elements
+      of traditional UNIX security, modern cryptographic services, and
+      trusted operating system elements to support the requirements of
+      these environments through flexibility and adaptability.</para>
+    <variablelist>
+      <varlistentry>
+	<term>Authorization</term>
+	<listitem>
+	  <para>Authorization refers to the process by which access control
+	    decisions are made--typically, authorization may be performed
+	    on the basis of an authenticated user identity, presentation
+	    of a cryptographic token, an inherited or acquired capability,
+	    explicit access control lists, or a variety of other policy
+	    driven considerations.
+	    Authorization checks occur in both the kernel and userspace
+	    components of FreeBSD.</para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term>Authentication</term>
+	<listitem>
+	  <para>Authentication refers to the process by which a system
+	    (in this case, operating system) determines and confirms
+	    the identity of a user (or another system) it interacts
+	    with.
+	    Frequently in the context of FreeBSD, this refers to early
+	    stages in the login process, in which a user presents a
+	    username and password; however, it may also refer to
+	    inter-host authentication using host SSH keys, IKE key
+	    negotiation for IPsec, and a variety of other elements.
+	    Authentication typically relies on testing the knowledge of
+	    a third party in relation to secrets that only an
+	    appropriate third party could know: for example, testing a
+	    shared secret (such as a password), one time passwords, or
+	    through use of a Public Key Infrastructure.
+	    Typically, system authorization occurs in the context of
+	    an authenticated user identity; however, authorization
+	    decisions may be made prior to user authentication, or in
+	    the case of network activity, without access to any
+	    authenticated identity.</para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term>Availability</term>
+	<listitem>
+	  <para>Availability refers to the design requirement that
+	    services offered by a system be, in as much as is possible,
+	    uninterrupted despite unexpected or undesired circumstances.
+	    In the context of FreeBSD, this concept frequently drives
+	    the requirement for resource accounting, resource limits to
+	    prevent unfair exhaustion of system resources, scheduler
+	    behavior, access controls, and authentication.
+	    Availability is expressed with regard to a subject: frequently,
+	    to maintain availability for one user, it is necessary to
+	    reduce or deny access to services for another user.
+	    Availability is frequently considered in the context of a
+	    malicious user attempting to deny service to other users.
+	    </para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term>Integrity</term>
+	<listitem>
+	  <para>Integrity refers to the protection of system operation
+	    and stored data from undesired modification by unauthorized
+	    parties; the integrity of the operating system is required
+	    to ensure proper operation.
+	    The integrity of user data is then protected by the operating
+	    system by means of authentication and authorization.
+	    Integrity guarantees are often important to the notion of
+	    system availability, as interference with system integrity
+	    frequently has an impact on operation.
+	    Cryptographic tools may also be used to measure the integrity
+	    of the system.</para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term>Confidentiality</term>
+	<listitem>
+	  <para>Confidentiality refers to the protection of system and
+	    stored data from undesired leakage to unauthorized
+	    parties: confidentiality of system authentication data
+	    is required to ensure successful authentication, protection
+	    of entropy, etc.
+	    Confidentiality of system and user data is protected by the
+	    operating system by means of authentication and
+	    authorization.
+	    Cryptographic tools may also be used to maintain the secrecy
+	    of data.</para>
+	</listitem>
+      </varlistentry>
+      <varlistentry>
+	<term>Cryptography</term>
+	<listitem>
+	  <para>Cryptography refers to the use of mathematical
+	    algorithms and techniques used to provide guarantees for
+	    the protection of data communications and processes.
+	    Typically, cryptographic techniques are used in three
+	    forms in FreeBSD: the protection of authentication data,
+	    protection of data on storage arrays, and for the purposes
+	    of secure network communications; cryptographic services
+	    are also provided for the benefit of applications.
+	    Guarantees of cryptographic algorithms and protocols often
+	    include integrity, confidentiality, non-repudiation, and
+	    freshness.</para>
+	</listitem>
+      </varlistentry>
+    </variablelist>
+  </sect1>
+  <sect1 id="secarch-kernel">
+    <title>Kernel Security Model</title>
+    <para></para>
+    <sect2 id="secarch-kernel-addressspace">
+      <title>Kernel Address Space Separation</title>
+      <para>FreeBSD, as is the case with most UNIX-derived operating
+	systems, executes the kernel in a supervisor hardware mode
+	that prevents direct process access to kernel memory and
+	hardware resources by user processes, providing integrity and
+	confidentiality protections for kernel data structures and code.
+	On all current hardware architectures, this is accomplished by
+	reserving a segment of the system address space for read/write
+	access only by appropriately authorized task descriptors; access
+        to privileged instructions, such as those used to configure
+        page tables, flush TLBs, and configure new tasks, is limited
+        to code executing kernel mode in the common case.
+	On the i386 platform, this is implemented using rings -- the
+	kernel operates in ring 0, and user processes operate in ring 3.
+	Processes are forced to communicate with the kernel through a
+	variety of more explicit traps, including exceptions generated by
+	arithmetic traps in the instruction stream, exceptional memory
+	accesses such as page faults, or system calls via call gates.
+	Kernel code interacting with user processes is written carefully
+	so as to provide only support only the desired interactions
+	between the kernel and user processes.</para>
+      <para>Within the kernel, direct manipulation of user memory contents
+	is generally avoided, and instead abstracted through a series of
+	copy routines that enforce appropriate protections, preventing
+	(among other things) the kernel from derefencing user-provided
+	pointers to kernel address space.
+	In general, direct access to system hardware devices is prohibited
+	to user processes--they must make use of control kernel service
+	APIs to access disk storage, I/O busses, etc.
+	This rule is circumvented under special circumstances, such as the
+	creation of user process device drivers (most frequently, for the
+	X11 window system).
+	To bypass this protection, privilege is required, or must be
+	delegated.</para>
+    </sect2>
+    <sect2 id="secarch-kernel-bypass">
+      <title>Direct Hardware and Kernel Memory Access</title>
+      <para>Some bypass mechanisms are provided to permit privileged user 
+	processes to monitor the kernel or interact with the hardware
+	through controlled abstractions, or in execptional cases,
+	to interact with the hardware in an unabstracted form.</para>
+      <para>Most hardware devices are exposed to user applications
+	via the device file system (devfs), which presents these devices
+	as file-like objects.
+	Protection properties (such as access control lists) on the
+	pseudo-files are combined with direct authorization in the device
+	drivers to control access.
+	Two devices, <filename>/dev/mem</filename> and
+	<filename>/dev/kmem</filename> permit unrestricted access to system 
+	memory and kernel memory, and are generally controlled so that only
+	highly privileged processes may use them.
+	The kmem interface was used extensively in earlier versions of
+	FreeBSD and other UNIX-derived systems as a means to monitor kernel
+	activities; in more recent versions of FreeBSD, the &man.sysctl.3;
+	API is used to monitor and manipulate a structure kernel MIB,
+	providing a more controlled interface with defined semantics.
+	The kmem interface may also be used for debugging purposes.</para>
+      <para>On many hardware platforms, it is possible for the kernel to 
+	authorize user processes to perform I/O directly; on the i386
+	platform, opening the <filename>/dev/io</filename> device enables
+	direct I/O access.
+	Other platforms provide similar functionality.
+	Many platforms also offer hardware-specific via the
+	&man.sysarch.2; system call; some of the functions provided by the
+	system call are process-local, but others may provide privileged
+	services.
+	For example, the i386 sysarch() call implements a
+	<literal>I386_SET_IOPERM</literal> operation that also enables
+	direct hardware I/O.
+	Careful maintenance of the protections of these special devices
+	and interfaces is vital to the proper protection of the kernel
+	and user processes via address space protections.</para>
+    </sect2>
+    <sect2 id="secarch-kernel-modules">
+      <title>Kernel Extension via Kernel Modules</title>
+      <para>FreeBSD permits the boot-time and run-time extension of the 
+	operating system kernel through loadable kernel modules.
+	This facility is used to load device drivers supporting new
+	hardware devices on-demand, add support for new file systems, as
+	well as binary emulation layers and other services.
+	Run-time extension of the kernel involves loading of the module
+	from a file into the kernel address space, followed by dynamic
+	linking of that module into the execution environment, and
+	eventual execution of any events and services in the module.
+	As such, the system calls to cause loading or unloading of kernel
+	modules are carefully controlled operations, as loading new code
+	into the kernel could by used by attackers to bypass other
+	protections.
+	Modules may also be loaded as part of the boot process; file
+	system protections are used to protect the integrity of any files 
+	involved in the boot process.</para>
+      <para>Protection of the boot sequence is vital to the secure 
+	operation of the system; this requires protection of any hardware 
+	devices involved in the boot process, as well as any files (such
+	as the boot loader, kernel, modules, and configuration files)
+	from inappropriate access.</para>
+    </sect2>
+  </sect1>
+  <sect1 id="secarch-processes">
+    <title>Process Protections</title>
+    <para>Processes represent the high-level abstraction of a program
+      "in execution"; each process consists of a virtual memory address
+      space (including a mapping of executable code from a file), signal
+      delivery information, process credentials, one or more threads in
+      execution, pool of resources limits, and an array of file
+      descriptors holding references to a variety of I/O and system
+      objects.
+      Processes generally run "in isolation", communicating with other
+      processes only through explicit and intentional communication
+      channels (such as files, IPC primitives, etc).  Shared memory is
+      permitted, but must be explicitly configured by the process.</para>
+    <para>Programs, as executed in processes, are generally derived
+      from an executable image (file) that has been mapped into the
+      process address space.
+      While the kernel does not provide explicit support for it, most
+      applications on FreeBSD make use of dynamically linked libraries,
+      implemented via the memory mapping of library files into the
+      process address space.
+      In practice, most programs executing on FreeBSD systems
+      are composed from a variety of run-time linked libraries, and
+      frequently pluggable modules loaded as shared objects.</para>
+    <para>The ability to directly modify process memory or other
+      operation parameters represents the ability to control the
+      execution of the process, and hence manipulate its operation.
+      By providing memory and other protections, the FreeBSD kernel
+      limits inappropriate interference between processes, preventing
+      accidental or intentional leakage of data, damage to data or
+      operational integrity, and leakage of system privilege.
+      System debugging interfaces break down these barries, and must
+      be carefully controlled.</para>
+    <sect2 id="secarch-process-credentials">
+      <title>Process Credentials</title>
+      <para>FreeBSD assigns each process a credential, which holds
+	a variety of information relating to the privileges available
+	to the process.
+	The process credential contains several elements, including real,
+	saved, and effective user IDs, group IDs, resource limit
+	information for the user, a reference to a system jail, and an
+	extensible MAC label.
+	This data will be used to compute access control results
+	associated with most security-sensitive operations.</para>
+      <para>Consistency and performance are provided in the
+	multi-threaded kernel by also assigning a credential to each
+	thread.
+	The thread credential is compared to the primary process
+	credential whenever the thread enters the kernel, and if it
+	differs from the process credential, it is updated to reflect
+	the latest snapshot of the process credential.
+	This ensures a consistent credential for the duration of the
+	system call, and most access control checks for thread
+	operations are performed against the thread credential (a
+	thread-local variable) as it does not require explicit locking.
+	During update operations, the process lock is held across a
+	check and update of the process credential to ensure consistency
+	and prevent races.</para>
+      <para>The semantics of the various credential fields are
+	defined both by historical application requirements, and
+	in the POSIX specifications.
+	In general, the effective uid, effective gid, and additional
+	groups will be used to implement access control checks.
+	Processes may use the saved and real uid and gid to preserve
+	other credential elements for conditional use during execution:
+	for example, when a setuid application is executed, the saved
+	uid and gid are updated to the values of the effective uid
+	and gid prior to the execution.
+	This permits setud applications to swap between the original
+	and file-originated ids, permitting the privileges to be
+	blended in a controlled manner.
+	Real and saved uids and gids will also be used in controlling
+	inter-process access control, and will be used under some
+	circumstances to control resource limits.</para>
+      <para>Credentials are also cached in a variety of other
+	kernel data structures, generally at the point at which
+	initial access to the object occurs.
+	This caching permits "time of open" UNIX security semantics to
+	be implemented for a several objects, including file descriptors
+	and mountpoints.
+	These credential references are then used to authorize
+	asynchronous write-behind, such as found in NFS.</para>
+      <para>As credentials are frequently referenced throughout the
+	system, but rarely modified, credentials are stored as
+	copy-on-write.
+	This permits new read-only references to credential structures
+	to be created with minimal memory overhead.
+	When a credential must be modified, a new copy of the credential
+	is created, modified, and then the process reference is updated
+	to point to the new credential.</para>
+      <para>A variety of hazards are associated with dynamic changes
+	in process credentials, as processes may be the object of
+	operations, not just the subject.
+	When a process runs with upgraded or downgraded privileges, risks
+	may exist.
+	For example, even if a process reduces its level of privilege, it
+	may have cached access to objects or memory that is not revoked
+	with the explicit credential change (such as keying material in
+	library-managed or free'd memory).
+	When a process receives upgraded privileges, such as on execution
+	of a setuid binary, the system must revoke access to debug
+	the process by other processes that may already have had
+	debugging sessions opon.</para>
+      <para>These protections are introduced in three ways: first,
+	disallowing of operations that may upgrade of process credentials
+	if access to the process cannot be revoked.
+	Second, storage of a "credential change flag", named P_SUGID for
+	historical reasons, which will be used to modify the
+	inter-process access control policy by indicating a change has
+	happened in the process life time.
+	Third, the explicit revocation of existing access to the process.
+	Additional information about inter-process access control may be
+	found later in this chapter.</para>
+      <para>In most situations, the user credential structure is
+	sufficient to encapsulate all the necessary subject information
+	required for an access control decision.
+	However, under some circumstances, additional process information
+	may also be used in the decision to exempt closely related
+	processes from certain protections--for example, participation in
+	the same sesion is sufficient to authorize delivery of the
+	"continue" signal between processes, regardless of credentials.
+      </para>
+    </sect2>
+    <sect2 id="secarch-privilege-model">
+      <title>Root Privilege Model</title>
+      <para>The uid 0, assigned to the root user, is given special
+	privilege to bypass system protections, including most
+	discretionary and mandatory protections on the local
+	system.
+	This privilege is referred to as the "superuser", and is used
+	for system processes, during the boot and shutdown processes,
+	and for management purposes.
+	Because of this concentration of privilege, required to
+	perform a number of system activities, system services
+	running with root privilege are popular targets for attack,
+	as gain access to uid 0 grants access to most other
+	privileges in the system.</para>
+      <para>FreeBSD ships with the securelevel protection mechanism,
+	first distributed with BSD 4.4.
+	Securelevels limit the scope of root privilege based on a
+	monotonically increasing current securelevel.
+	As the securelevel increases, various privileges are removed,
+	including the privilege to directly access disk devices, to
+	change file system protection flags, and to modify the
+	firewall configuration.
+	This model does not provide comprehensive protection against
+	the compromise of root privilege, but if properly configured,
+	can be used to improve the safety of the recovery
+	process.</para>
+      <para>The privileges of uid 0 are also bounded when used in
+	combination with the jail() security extension, described
+	later in this chapter.</para>
+      <para>The TrustedBSD MAC Framework is also capability of
+	limiting certain root privileges, such as the cability to
+	read files based on system labels.
+	The MAC Framework and policies are described later in this
+	chapter.</para>
+    </sect2>
+    <sect2 id="secarch-resource-limits">
+      <title>Process Resource Limits</title>
+      <para>FreeBSD is fundamentally designed around a resource-sharing
+	model, in which the operating system controls access to a
+	set of real hardware resources and mediates access to ensure
+	consistent and appropriate use.
+	As UNIX-derived systems are frequently deployed in environments
+	in which users or processes contend for resources, a variety of
+	approaches are taken to preventing inappropriate exclusion of
+	other users or processes.
+	This includes scheduler behavior to provide for "fair"
+	distribution of CPU resources between independent processes
+	based on priorities, a file system quota mechanism to bound
+	maximum consumption of resources by user or group, and a set
+	of process resource limits bounding access to a variety of
+	resources at the granularity of uids globally, and process
+	hierarchies.
+	In multiuser environments, such as ISP shell servers, resource
+	limits are vitally important to successful long-term operation:
+	users have a number of unfortunate habits, including the
+	creation of programs that (intentionally or otherwise) attempt
+	to consume all available system resources.</para>
+      <sect3 id="secarch-scheduler">
+	<title>System Scheduler Priorities</title>
+	<para>FreeBSD 5.1 ships with two system schedulers, one of
+	  which must be selected at kernel compile-time.
+	  The 4.4BSD scheduler implements a time-sharing, floating
+	  priority scheduler based on user-assigned process priorities,
+	  with additional support for real-time and idle scheduling.
+	  The ULE scheduler implements a similar scheduling policy, but
+	  contains optimizations for threading, non-symmetric
+	  CPU topologies, and scheduler structural optimizations for
+	  MP environments.</para>
+	<para>The UNIX priority scheme assigns fixed priorities to
+	  kernel and user processes; lower priority values indicate
+	  a higher precedence.
+	  Kernel processes generally take priorities based on
+	  compile-time configuration.
+	  User processes inherit their priority from their parent
+	  process, and priorities may be updated using the
+	  setpriority() system call, which operates on a process,
+	  process group, or all processes owned by a specified user.
+	  In general, privilege is required to lower the priority (raise
+	  the precedence) of a process.
+	  Processes may perform operations to modify the scheduling
+	  properties of another process; policies associated with
+	  these operations are described in the Inter-Process
+	  Authorization section.
+	  Kernel locking primitives make use of priority propagation to
+	  prevent priority inversions on contended kernel
+	  resources.</para>
+	<para>In addition to the UNIX process priority ranges, processes
+	  may also operate with realtime or idle priority.
+	  Real time processes preempt processes of lower priorities, and
+	  when contending against equal priority processes, are executed
+	  round-robin.
+	  Idle priority processes operate only when no other processes
+	  are able to execute.
+	  Because both realtime and idle priority processes can result in
+	  priority inversions, privilege is required to modify the
+	  realtime or idle priorities of a process.</para>
+      </sect3>
+      <sect3 id="secarch-globalmeasurement">
+	<title>Per-Uid Global Resource Measurement</title>
+	<para>FreeBSD permits limits on the number of processes and
+	  amount of socket buffer space, two particularly sensitive
+	  system resources.
+	  Measurements are taken globally on a per-uid basis.
+	  The FreeBSD kernel maintains a global list of both consumed
+	  and maximum resources per-uid in reference-counted uidinfo
+	  structures.
+	  References to the uidinfo structure for the effective and real
+	  uids are cached in the user credential structure, and are
+	  updated when the uid of a process changes.</para>
+	<para>Process counts are maintained based on the number of
+	  processes owned by a particular real uid.
+	  Updates to the per-uid process count are performed when the
+	  first process is created, whenever a process forks or exits,
+	  and whenever a process changes its real uid.
+	  Resource limits on process counts are checked only on process
+	  fork; uid change operations will not fail by virtue of a
+	  resource limit.</para>
+	<para>Socket buffer sizes are maintained based on the sum of
+	  the high watermark sizes of sockets allocated by a
+	  particular effective uid.
+	  Updates to the per-uid socket buffer count are performed when
+	  a socket is allocated (via the socket() system call or as part
+	  of a new incoming connection), or when data is sent or
+	  received on the socket that may expand the high watermark.
+	  Resource limits are checked only when new sockets are
+	  created.</para>
+      </sect3>
+      <sect3 id="secarch-plimits">
+	<title>Per-Process Limits</title>
+	<para>Some resource limits, such as number of processes and
+	  maximum socket buffer per uid, are measured globally across
+	  the system.
+	  Other resources, such as VM space consumption or stack size,
+	  are measured locally to the process.
+	  In both cases, the limits imposed are process-local in that
+	  resource limits are a per-process property.
+	  Each process has a reference to a per-process limit structure,
+	  which consists of a set of limits associated with different
+	  resources.
+	  Each limit contains two elements: a soft (current) limit, and
+	  a hard (maximum) limit which represents the greatest value the
+	  current limit may be increased to without privilege.
+	  Process limits are inheritted on fork(); internally, the
+	  limits are stored copy-on-write.
+	  Resource limits are tested on the allocation of the resource,
+	  such as on the allocation of new memory, creation of a socket,
+	  or forking of a process.</para>
+	<para>Resources measured and controlled by the plimit structure
+	  include CPU time, maximum file size, maximum address space
+	  "data" size, maximum address space "stack" size, maximum
+	  size of core file, maximum resident set size, maximum
+	  memory pages that may be locked into physical memory, the
+	  maximum number of processes for the real uid, maximum number
+	  of open files, maximum size consumed by socket buffers for
+	  the effective uid, and maximum virtual memory size (including
+	  file mappings).</para>
+      </sect3>
+    </sect2>
+    <sect2 id="secarch-interprocess-authorization">
+      <title>Inter-Process Authorization</title>
+      <para>Processes interact explicitly through a variety of
+	communication channels, including the file system and IPC
+	services.
+	They may also directly interact through a series of inter-process
+	services.
+	These include signalling (which may act as IPC, modify
+	scheduling, or signal termination), a variety of monitoring
+	mechanisms such as those used to implement &;, scheduler
+	services to modify a process priority or schedule model, and a
+	set of debugging interfaces permitting a process to closely
+	monitor and modify the behavior of another process.
+	Inter-process operations permit the flow of information and
+	control between processes: signals may directly control the
+	operation and behavior of a process; visibility of process
+	command lines share information about what the process is doing,
+	scheduling services may prevent a process from running or cause it
+	to operate improperly; debugging often permits direct control of
+	the process and access to any resources accessible to the target
+	process.</para>
+     <para>Protections associated with these services are important to
+	prevent serious security vulnerabilities: in most cases, the
+	protection model requires that, to modify the behavior of another
+	process via signalling, scheduling, or debugging, the subject
+	(initiating) process must have the identical or superset
+	privileges to the object (target) process.
+	Additional protects may be assigned to a process if the process
+	has modified or downgraded is privileges, as it may still have
+	local references to information or resources beyond those
+	normally available to its new privileges; these protections are
+	typically used to prevent attaching a debugger to a process that
+	has run as root, and is now executing as another uid during the
+	login process, or to protect setuid or setgid programs in
+	execution.
+	Vulnerabilities exploitable without these protections might
+	include access to password files or keying material still held
+	by the process.<para>
+      <para>An important limitation to the safety of inter-process
+	operations is derived from the UNIX "process id" (pid) model.
+	Each process is assigned a numeric identifier, unique for the
+	lifetime of the process.
+	Operations targetted at processes generally specify the
+	target process by means of its pid: however, pids may (will) be
+	reused following the death of a process.
+	While FreeBSD can be operated in a mode in which pids are
+	randomly allocated, eventual reuse of a pid is guaranteed
+	with any reasonable uptime.
+	As a result, signals may be delivered to improper processes as
+	a result of races in pid use.
+	While inter-process access control prevents the malicious
+	delivery of signals to processes based on differing
+	credentials, it cannot prevent the accidental delivery of a
+	signal to an unintended process by an authorized process.
+	</para>
+      <para>MAC Framework policy modules are permitted to augment 
+	inter-process protections, and many do so.</para>
+    </sect2>
+  </sect1>
+  <sect1 id="secarch-fileobjects">
+    <title>File Descriptors, File Systems, and Storage Security</title>
+    <para></para>
+    <sect2 id="secarch-fds">
+      <title>File Descriptors</title>
+      <para>Each FreeBSD process has an associated array of references
+	to active I/O objects, known as file descriptors, which
+	refer to active object sessions.
+	For most processes, the file descriptor array will not be
+	shared; however, it is possible to create processes that share
+	file descriptors using the rfork() call--this behavior is
+	required to emulate Linux threading.
+	Each object session, described by a <structname>struct
+	file</structname> in the kernel, has an associated underlying
+	object, operation vector, cached credential from the time of
+	creation, access mode, and current offset.</para>
+      <para>Object sessions are initially referred to by one file
+	descriptor, but references may be duplicated to additional file
+	descriptors, as well as inheritted across fork() operations, and
+	passed to other processes using UNIX Domain Socket ancillary right
+	transfer.
+	In FreeBSD 5.1, objects referenced by file descriptors are: IPC
+	pipes, IPC sockets, vnodes (files, directories, device nodes,
+	POSIX fifos, etc), kqueues (kernel event notification queues).
+	References to object sessions remain until the the descriptor is
+	explicitly closed via the close() or rfork() system calls, or
+	implicitly closed on process exec() or exit().
+	File descriptor arrays may not be modified except by processes
+	that reference them--however, the active object sessions may be
+	modified, as may the underlying objects.
+	File descriptor properties, such as offset and active access
+	flags, may be explicitly modified using system calls such as
+	seek() or fcntl(), or implicitly as a result of operations making
+	use of the file descriptor, such as read() or write().</para>
+      <para>In most cases, accesses made using a file descriptor are
+	authorized using the cached file credential from the creation
+	of the file descriptor: for example, NFS read operations
+	initiated as a result of a read on the file descriptor will
+	be authorized using the credential that opened the file,
+	which may be different from the credential used to initiate
+	the read operation.
+	However, some accesses are authorized using the active
+	credential: typically, this includes meta-data and
+	administrative operations such as fchmod() on files, or ioctl()
+	on sockets.
+	Mandatory protections enforced by the MAC Framework may depend
+	on either the active or file credential.
+	For local file systems, protections are typically only enforced
+	with the open() operation, with the exception of
+	securelevel-related flags such as system immutable.</para>
+    </sect2>
+    <sect2 id="secarch-filesystem">
+      <title>File System Protection Model</title>
+      <sect3 id="secarch-fsnamespace">
+	<title>File System Namespace Protections</title>
+	<para>The FreeBSD virtual file system (VFS) consists of
+	  a namespace constructed out of individual file system
+	  mounts, and a set of objects (including directories and
+	  files) that make up the namespace. 
+	  Processes look up objects relative to either the process
+	  root directory, or process current working directory; in
+	  general, objects cannot be accessed without passing
+	  through the file system namespace; objects that cannot
+	  be named by a process are, in most cases, inaccessible to
+	  the process, although references to unnameable objects
+	  outside a process's namespace may be passed via IPC.</para>
+	<para>As a result of these properties, three common protections
+	  are available to protect objects in the file system
+	  namespace: chroot() or mountpoint covering may be used
+	  to prevent the process from constructing a name to the
+	  object; namespace protections, such as access control
+	  lists on directories, can prevent a process from traversing
+	  the namespace to an object; finally, protections on the
+	  object itself can prevent inappropriate access to an
+	  object--for example, file permissions may permit read of
+	  an object, but not write.
+	  Objects may appear more than once in the same namespace by
+	  virtue of hard links and synthetic mountpoints: as a result,
+	  caution must be applied when relying on namespace-based
+	  protections to limit access to an object.</para>
+	<para>Modifications to the namespace may be performed by
+	  adding or removing file system mounts, attaching, overlaying,
+	  or detaching parts of the namespace, or by modifying elements
+	  in the namespace by perform operations on objects in the
+	  namespace.
+	  Mount and unmount operations require privilege in FreeBSD
+	  by default; however, the system policy may be configured to
+	  permit user mounts under limited circumstances.
+	  Access to the mount primitives is generally limited because
+	  the ability to directly access the underlying storage
+	  mechanism connotes the ability to manipulate the file system
+	  namespace and protections, bypassing OS limits on those
+	  operations.
+	  When user mounts are permitted, the underlying device must
+	  be readable (and optionally writable) by the user performing
+	  the mount operation; in addition, users may only mount
+	  new file systems on top of objects (typically, directories)
+	  that they own.
+	  Modifications to elements in a file system namespace are
+	  typically authorized in a file system-specific manner, based
+	  on the mandatory and discretionary protections offered by
+	  the file system.</para>
+	<para>The MAC Framework permits file system operations to
+	  be controlled across all file systems, with protections
+	  implemented above the per-filesystem layer.
+	  File systems may support multi-label operation, assigning
+	  labels to each object in the file system in a file-system
+	  specific manner, or single-label operation in which all
+	  objects in the file system share the same label, requiring
+	  no special support by the file system for MAC.</para>
+      <sect3 id="secarch-fsobjects">
+	<title>File System Objects and Operations</title>
+	<para>The FreeBSD VFS defines several classes of objects, and
+	  operations that apply to one or more of those objects.
+	  The following operations may be supported on a virtual file
+	  node:</para>
+	<variablelist>
+	  <varlistentry>
+	    <term>create()</term>
+	    <listitem>
+	      <para>Create a new file system object; parent directory,

>>> TRUNCATED FOR MAIL (1000 lines) <<<
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