Flesh out the kernel architecture section of the MAC Framework
bits of the Developer's Handbook some. Needs more work, but now goes into a bit more detail. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
This commit is contained in:
Robert Watson
parent
6304541cd0
commit
105124763b
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=16600
2 changed files with 232 additions and 58 deletions
en_US.ISO8859-1/books
|
|
@ -135,41 +135,128 @@
|
|||
the compile-time or run-time extension of the kernel access
|
||||
control model. New system policies may be implemented as
|
||||
kernel modules and linked to the kernel; if multiple policy
|
||||
modules are present, their results will be composed. While the
|
||||
framework is intended to support a variety of access control
|
||||
models, its design was derived from the requirements of a set
|
||||
of specific access control models required for the TrustedBSD
|
||||
and CBOSS Projects. This includes support for fixed and
|
||||
floating label Biba integrity policies, the MLS
|
||||
confidentiality policy, the Type Enforcement rule-based access
|
||||
control policy, and the ability to support layering of the NSA
|
||||
FLASK framework above the TrustedBSD MAC framework. This
|
||||
document describes the rough architecture of the framework,
|
||||
with the understanding that this is a work-in-progress and may
|
||||
change substantially as requirements evolve.</para>
|
||||
modules are present, their results will be composed. The
|
||||
MAC Framework provides a variety of access control infratructure
|
||||
services to assist policy writers, including support for
|
||||
transient and persistent policy-agnostic object security
|
||||
labels. This support is currently considered experimental.</para>
|
||||
|
||||
<para>Mandatory Access Control (MAC), refers to a set of
|
||||
access control policies that are mandatorily enforced on
|
||||
users by the operating system. MAC policies may be contrasted
|
||||
with Discretionary Access Control (DAC) protections, by which
|
||||
non-administrative users may (at their discretion) protect
|
||||
objects. In traditional UNIX systems, DAC protections include
|
||||
file permissions and access control lists; MAC protections include
|
||||
process controls preventing inter-user debugging and firewalls.
|
||||
A variety of MAC policies have been formulated by operating system
|
||||
designers and security researches, including the Multi-Level
|
||||
Security (MLS) confidentiality policy, the Biba integrity policy,
|
||||
Role-Based Access Control (RBAC), and Type Enforcement (TE). Each
|
||||
model bases decisions on a variety of factors, including user
|
||||
identity, role, and security clearance, as well as security labels
|
||||
on objects representing concepts such as data sensitivity and
|
||||
integrity.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mac-kernel-arch">
|
||||
<title>Kernel Architecture</title>
|
||||
|
||||
<para>The TrustedBSD MAC framework provides the opportunity for
|
||||
policy modules to be augment system access control decisions.
|
||||
Policies are permitted the opportunity to restrict the set of
|
||||
rights available for processes at a variety of relevant points
|
||||
in the kernel. In addition, they are provided the opportunity
|
||||
to tag processes and various kernel objects with labels storing
|
||||
access control information. Policy modules may register
|
||||
interest in a subset of the total available events or objects,
|
||||
and are not required to implement events or objects that are not
|
||||
relevant to the policy. Multiple modules may be loaded at once,
|
||||
and the results of the modules are composed as necessary to
|
||||
build an over-all system policy. Policy modules may be
|
||||
implemented such that they can be loaded on-demand at run-time,
|
||||
or such that they may only be loaded early in the boot process.
|
||||
This permits policies requiring pervasive labeling of all
|
||||
objects to prevent improper use.</para>
|
||||
<para>The TrustedBSD MAC Framework permits kernel modules to
|
||||
extend the operating system security policy, as well as
|
||||
providing infrastructure functionality required by many
|
||||
access control modules. If multiple policies are
|
||||
simultaneously loaded, the MAC Framework will usefully (for
|
||||
some definition of useful) compose the results of the
|
||||
policies. The MAC Framework contains a number of kernel
|
||||
elements:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Framework management interfaces</para></listitem>
|
||||
<listitem><para>Policy registration and management</para></listitem>
|
||||
<listitem><para>Extensible security label for kernel
|
||||
objects</para></listitem>
|
||||
<listitem><para>Policy entry point composition
|
||||
operators</para></listitem>
|
||||
<listitem><para>Label management primitives</para></listitem>
|
||||
<listitem><para>Entry point API invoked by kernel
|
||||
services</para></listitem>
|
||||
<listitem><para>Entry point API to policy modules</para></listitem>
|
||||
<listitem><para>Entry points implementations (policy life cycle,
|
||||
object life cycle/label management, access control
|
||||
checks).</para></listitem>
|
||||
<listitem><para>Policy-agnostic label-management system
|
||||
calls</para></listitem>
|
||||
<listitem><para><function>mac_syscall()</function> multiplex
|
||||
system call</para></listitem>
|
||||
<listitem><para>Various security policies implemented as MAC
|
||||
policy modules</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Kernel services interact with the MAC Framework in two ways:
|
||||
they invoke a series of APIs to notify the framework of relevant
|
||||
events, and they a policy-agnostic label structure in
|
||||
security-relevent objects. This label structure is maintained by
|
||||
the MAC Framework via label management entry points, and permits
|
||||
the Framework to offer a labeling service to policy modules
|
||||
through relatively uninvasive changes to the kernel subsystem
|
||||
maintaining the object. For example, label structures have been
|
||||
added to processes, process credentials, sockets, pipes, vnodes,
|
||||
mbufs, network interfaces, IP reassembly queues, and a variety
|
||||
of other security-relevant structures. Kernel services also
|
||||
invoke the MAC Framework when they perform important security
|
||||
decisions, permitting policy modules to augment those decisions
|
||||
based on their own criteria (possibly including data stored in
|
||||
security labels).</para>
|
||||
|
||||
<para>Security policies are either linked directly into the kernel,
|
||||
or compiled into loadable kernel modules that may be loaded at
|
||||
boot, or dynamically using the module loading system calls at
|
||||
runtime. Policy modules interact with the system through a
|
||||
set of declared entry points, providing access to a stream of
|
||||
system events and permitting the policy to influence access
|
||||
control decisions. Each policy contains a number of elements:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Optional configuration parameters for
|
||||
policy.</para></listitem>
|
||||
<listitem><para>Centralized implementation of the policy
|
||||
logic and parameters.</para></listitem>
|
||||
<listitem><para>Optional implementation of policy life cycle
|
||||
events, such as initialization and destruction.</para></listitem>
|
||||
<listitem><para>Optional support for initializing, maintaining, and
|
||||
destroying labels on selected kernel objects.</para></listitem>
|
||||
<listitem><para>Optional support for user process inspection and
|
||||
modification of labels on selected objects.</para></listitem>
|
||||
<listitem><para>Implementation of selected access control
|
||||
entry points that are of interest to the policy.</para></listitem>
|
||||
<listitem><para>Declaration of poicy identity, module entry
|
||||
points, and policy properties.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>When more than one policy module is loaded into the kernel
|
||||
at a time, the results of the policy modules will be composed
|
||||
by the framework using a composition operator. This operator
|
||||
is currently hard-coded, and requires that all active policies
|
||||
must approve a request for it to occur. As policies may
|
||||
return a variety of error conditions (success, access denied,
|
||||
object doesn't exist, ...), a precedence operator selects the
|
||||
resulting error from the set of errors returned by policies.
|
||||
While it is not guaranteed that the resulting composition will
|
||||
be useful or secure, we've found that it is for many useful
|
||||
selections of policies.</para>
|
||||
|
||||
<para>As many interesting access control extensions rely on
|
||||
security labels on objects, the MAC Framework provides a set
|
||||
of policy-agnostic label management system calls covering
|
||||
a variety of user-exposed objects. Common label types
|
||||
include partition identifiers, sensitivity labels, integrity
|
||||
labels, compartments, domains, roles, and types. Policy
|
||||
modules participate in the internalization and externalization
|
||||
of string-based labels provides by user applications, and can
|
||||
expose multiple label elements to applications if desired.</para>
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="mac-userland-arch">
|
||||
<title>Userland Architecture</title>
|
||||
|
||||
|
|
|
|||
|
|
@ -135,41 +135,128 @@
|
|||
the compile-time or run-time extension of the kernel access
|
||||
control model. New system policies may be implemented as
|
||||
kernel modules and linked to the kernel; if multiple policy
|
||||
modules are present, their results will be composed. While the
|
||||
framework is intended to support a variety of access control
|
||||
models, its design was derived from the requirements of a set
|
||||
of specific access control models required for the TrustedBSD
|
||||
and CBOSS Projects. This includes support for fixed and
|
||||
floating label Biba integrity policies, the MLS
|
||||
confidentiality policy, the Type Enforcement rule-based access
|
||||
control policy, and the ability to support layering of the NSA
|
||||
FLASK framework above the TrustedBSD MAC framework. This
|
||||
document describes the rough architecture of the framework,
|
||||
with the understanding that this is a work-in-progress and may
|
||||
change substantially as requirements evolve.</para>
|
||||
modules are present, their results will be composed. The
|
||||
MAC Framework provides a variety of access control infratructure
|
||||
services to assist policy writers, including support for
|
||||
transient and persistent policy-agnostic object security
|
||||
labels. This support is currently considered experimental.</para>
|
||||
|
||||
<para>Mandatory Access Control (MAC), refers to a set of
|
||||
access control policies that are mandatorily enforced on
|
||||
users by the operating system. MAC policies may be contrasted
|
||||
with Discretionary Access Control (DAC) protections, by which
|
||||
non-administrative users may (at their discretion) protect
|
||||
objects. In traditional UNIX systems, DAC protections include
|
||||
file permissions and access control lists; MAC protections include
|
||||
process controls preventing inter-user debugging and firewalls.
|
||||
A variety of MAC policies have been formulated by operating system
|
||||
designers and security researches, including the Multi-Level
|
||||
Security (MLS) confidentiality policy, the Biba integrity policy,
|
||||
Role-Based Access Control (RBAC), and Type Enforcement (TE). Each
|
||||
model bases decisions on a variety of factors, including user
|
||||
identity, role, and security clearance, as well as security labels
|
||||
on objects representing concepts such as data sensitivity and
|
||||
integrity.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mac-kernel-arch">
|
||||
<title>Kernel Architecture</title>
|
||||
|
||||
<para>The TrustedBSD MAC framework provides the opportunity for
|
||||
policy modules to be augment system access control decisions.
|
||||
Policies are permitted the opportunity to restrict the set of
|
||||
rights available for processes at a variety of relevant points
|
||||
in the kernel. In addition, they are provided the opportunity
|
||||
to tag processes and various kernel objects with labels storing
|
||||
access control information. Policy modules may register
|
||||
interest in a subset of the total available events or objects,
|
||||
and are not required to implement events or objects that are not
|
||||
relevant to the policy. Multiple modules may be loaded at once,
|
||||
and the results of the modules are composed as necessary to
|
||||
build an over-all system policy. Policy modules may be
|
||||
implemented such that they can be loaded on-demand at run-time,
|
||||
or such that they may only be loaded early in the boot process.
|
||||
This permits policies requiring pervasive labeling of all
|
||||
objects to prevent improper use.</para>
|
||||
<para>The TrustedBSD MAC Framework permits kernel modules to
|
||||
extend the operating system security policy, as well as
|
||||
providing infrastructure functionality required by many
|
||||
access control modules. If multiple policies are
|
||||
simultaneously loaded, the MAC Framework will usefully (for
|
||||
some definition of useful) compose the results of the
|
||||
policies. The MAC Framework contains a number of kernel
|
||||
elements:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Framework management interfaces</para></listitem>
|
||||
<listitem><para>Policy registration and management</para></listitem>
|
||||
<listitem><para>Extensible security label for kernel
|
||||
objects</para></listitem>
|
||||
<listitem><para>Policy entry point composition
|
||||
operators</para></listitem>
|
||||
<listitem><para>Label management primitives</para></listitem>
|
||||
<listitem><para>Entry point API invoked by kernel
|
||||
services</para></listitem>
|
||||
<listitem><para>Entry point API to policy modules</para></listitem>
|
||||
<listitem><para>Entry points implementations (policy life cycle,
|
||||
object life cycle/label management, access control
|
||||
checks).</para></listitem>
|
||||
<listitem><para>Policy-agnostic label-management system
|
||||
calls</para></listitem>
|
||||
<listitem><para><function>mac_syscall()</function> multiplex
|
||||
system call</para></listitem>
|
||||
<listitem><para>Various security policies implemented as MAC
|
||||
policy modules</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Kernel services interact with the MAC Framework in two ways:
|
||||
they invoke a series of APIs to notify the framework of relevant
|
||||
events, and they a policy-agnostic label structure in
|
||||
security-relevent objects. This label structure is maintained by
|
||||
the MAC Framework via label management entry points, and permits
|
||||
the Framework to offer a labeling service to policy modules
|
||||
through relatively uninvasive changes to the kernel subsystem
|
||||
maintaining the object. For example, label structures have been
|
||||
added to processes, process credentials, sockets, pipes, vnodes,
|
||||
mbufs, network interfaces, IP reassembly queues, and a variety
|
||||
of other security-relevant structures. Kernel services also
|
||||
invoke the MAC Framework when they perform important security
|
||||
decisions, permitting policy modules to augment those decisions
|
||||
based on their own criteria (possibly including data stored in
|
||||
security labels).</para>
|
||||
|
||||
<para>Security policies are either linked directly into the kernel,
|
||||
or compiled into loadable kernel modules that may be loaded at
|
||||
boot, or dynamically using the module loading system calls at
|
||||
runtime. Policy modules interact with the system through a
|
||||
set of declared entry points, providing access to a stream of
|
||||
system events and permitting the policy to influence access
|
||||
control decisions. Each policy contains a number of elements:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Optional configuration parameters for
|
||||
policy.</para></listitem>
|
||||
<listitem><para>Centralized implementation of the policy
|
||||
logic and parameters.</para></listitem>
|
||||
<listitem><para>Optional implementation of policy life cycle
|
||||
events, such as initialization and destruction.</para></listitem>
|
||||
<listitem><para>Optional support for initializing, maintaining, and
|
||||
destroying labels on selected kernel objects.</para></listitem>
|
||||
<listitem><para>Optional support for user process inspection and
|
||||
modification of labels on selected objects.</para></listitem>
|
||||
<listitem><para>Implementation of selected access control
|
||||
entry points that are of interest to the policy.</para></listitem>
|
||||
<listitem><para>Declaration of poicy identity, module entry
|
||||
points, and policy properties.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>When more than one policy module is loaded into the kernel
|
||||
at a time, the results of the policy modules will be composed
|
||||
by the framework using a composition operator. This operator
|
||||
is currently hard-coded, and requires that all active policies
|
||||
must approve a request for it to occur. As policies may
|
||||
return a variety of error conditions (success, access denied,
|
||||
object doesn't exist, ...), a precedence operator selects the
|
||||
resulting error from the set of errors returned by policies.
|
||||
While it is not guaranteed that the resulting composition will
|
||||
be useful or secure, we've found that it is for many useful
|
||||
selections of policies.</para>
|
||||
|
||||
<para>As many interesting access control extensions rely on
|
||||
security labels on objects, the MAC Framework provides a set
|
||||
of policy-agnostic label management system calls covering
|
||||
a variety of user-exposed objects. Common label types
|
||||
include partition identifiers, sensitivity labels, integrity
|
||||
labels, compartments, domains, roles, and types. Policy
|
||||
modules participate in the internalization and externalization
|
||||
of string-based labels provides by user applications, and can
|
||||
expose multiple label elements to applications if desired.</para>
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="mac-userland-arch">
|
||||
<title>Userland Architecture</title>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue