Some more structural changes for the MAC Framework chapter of the

Developer's Handbook: break out the "Entry Point Framework" section
into a number of sections: MAC Policy Declaration, Entry Point
Introduction, MAC Policy Entry Point Reference.  Re-order sections
a bit so there's a more logical progression and fewer large chunks
of text over many pages.  This greatly improves readability.

Obtained from:	TrustedBSD Project
Sponsored by:	DARPA, Network Associates Laboratories
This commit is contained in:
Robert Watson 2003-04-20 05:48:12 +00:00
parent 93cbd61b9c
commit f4d495b054
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=16617
2 changed files with 242 additions and 226 deletions
en_US.ISO8859-1/books
arch-handbook/mac
developers-handbook/mac

View file

@ -369,44 +369,8 @@
</sect2>
</sect1>
<sect1 id="mac-entry-point">
<title>Entry Point Framework</title>
<para>Four classes of entry points are offered to policies
registered with the framework: entry points associated with
the registration and management of policies, entry points
denoting initialization, creation, destruction, and other life
cycle events for kernel objects, events associated with access
control decisions that the policy module may influence, and
calls associated with the management of labels on objects. In
addition, a <function>mac_syscall()</function> entry point is
provided so that policies may extend the kernel interface
without registering new system calls.</para>
<para>Policy module writers should be aware of the kernel
locking strategy, as well as what object locks are available
during which entry points. Writers should attempt to avoid
deadlock scenarios by avoiding grabbing non-leaf locks inside
of entry points, and also follow the locking protocol for
object access and modification. In particular, writers should
be aware that while necessary locks to access objects and
their labels are generally held, sufficient locks to modify an
object or its label may not be present for all entry points.
Locking information for arguments is documented in the MAC
framework entry point document.</para>
<para>Policy entry points will pass a reference to the object
label along with the object itself. This permits labeled
policies to be unaware of the internals of the object yet
still make decisions based on the label. The exception to this
is the process credential, which is assumed to be understood
by policies as a first class security object in the kernel.
Policies that do not implement labels on kernel objects will
be passed NULL pointers for label arguments to entry
points.</para>
<sect2 id="mac-mpo-general">
<title>General-Purpose Module Entry Points</title>
<sect1 id="mac-policy-declaration">
<title>MAC Policy Declaration</title>
<para>Modules may be declared using the
<function>MAC_POLICY_SET()</function> macro, which names the
@ -518,6 +482,50 @@
is loaded before the network subsystem is active (i.e., the
policy is not being loaded late), then all Mbufs are guaranteed
to have label storage.</para></note>
</sect1>
<sect1 id="mac-entry-point-intro">
<title>Entry Point Introduction</title>
<para>Four classes of entry points are offered to policies
registered with the framework: entry points associated with
the registration and management of policies, entry points
denoting initialization, creation, destruction, and other life
cycle events for kernel objects, events associated with access
control decisions that the policy module may influence, and
calls associated with the management of labels on objects. In
addition, a <function>mac_syscall()</function> entry point is
provided so that policies may extend the kernel interface
without registering new system calls.</para>
<para>Policy module writers should be aware of the kernel
locking strategy, as well as what object locks are available
during which entry points. Writers should attempt to avoid
deadlock scenarios by avoiding grabbing non-leaf locks inside
of entry points, and also follow the locking protocol for
object access and modification. In particular, writers should
be aware that while necessary locks to access objects and
their labels are generally held, sufficient locks to modify an
object or its label may not be present for all entry points.
Locking information for arguments is documented in the MAC
framework entry point document.</para>
<para>Policy entry points will pass a reference to the object
label along with the object itself. This permits labeled
policies to be unaware of the internals of the object yet
still make decisions based on the label. The exception to this
is the process credential, which is assumed to be understood
by policies as a first class security object in the kernel.
Policies that do not implement labels on kernel objects will
be passed NULL pointers for label arguments to entry
points.</para>
</sect1>
<sect1 id="mac-entry-point-reference">
<title>MAC Policy Entry Point Reference</title>
<sect2 id="mac-mpo-general">
<title>General-Purpose Module Entry Points</title>
<sect3 id="mac-mpo-init">
<title><function>&mac.mpo;_init</function</title>

View file

@ -369,44 +369,8 @@
</sect2>
</sect1>
<sect1 id="mac-entry-point">
<title>Entry Point Framework</title>
<para>Four classes of entry points are offered to policies
registered with the framework: entry points associated with
the registration and management of policies, entry points
denoting initialization, creation, destruction, and other life
cycle events for kernel objects, events associated with access
control decisions that the policy module may influence, and
calls associated with the management of labels on objects. In
addition, a <function>mac_syscall()</function> entry point is
provided so that policies may extend the kernel interface
without registering new system calls.</para>
<para>Policy module writers should be aware of the kernel
locking strategy, as well as what object locks are available
during which entry points. Writers should attempt to avoid
deadlock scenarios by avoiding grabbing non-leaf locks inside
of entry points, and also follow the locking protocol for
object access and modification. In particular, writers should
be aware that while necessary locks to access objects and
their labels are generally held, sufficient locks to modify an
object or its label may not be present for all entry points.
Locking information for arguments is documented in the MAC
framework entry point document.</para>
<para>Policy entry points will pass a reference to the object
label along with the object itself. This permits labeled
policies to be unaware of the internals of the object yet
still make decisions based on the label. The exception to this
is the process credential, which is assumed to be understood
by policies as a first class security object in the kernel.
Policies that do not implement labels on kernel objects will
be passed NULL pointers for label arguments to entry
points.</para>
<sect2 id="mac-mpo-general">
<title>General-Purpose Module Entry Points</title>
<sect1 id="mac-policy-declaration">
<title>MAC Policy Declaration</title>
<para>Modules may be declared using the
<function>MAC_POLICY_SET()</function> macro, which names the
@ -518,6 +482,50 @@
is loaded before the network subsystem is active (i.e., the
policy is not being loaded late), then all Mbufs are guaranteed
to have label storage.</para></note>
</sect1>
<sect1 id="mac-entry-point-intro">
<title>Entry Point Introduction</title>
<para>Four classes of entry points are offered to policies
registered with the framework: entry points associated with
the registration and management of policies, entry points
denoting initialization, creation, destruction, and other life
cycle events for kernel objects, events associated with access
control decisions that the policy module may influence, and
calls associated with the management of labels on objects. In
addition, a <function>mac_syscall()</function> entry point is
provided so that policies may extend the kernel interface
without registering new system calls.</para>
<para>Policy module writers should be aware of the kernel
locking strategy, as well as what object locks are available
during which entry points. Writers should attempt to avoid
deadlock scenarios by avoiding grabbing non-leaf locks inside
of entry points, and also follow the locking protocol for
object access and modification. In particular, writers should
be aware that while necessary locks to access objects and
their labels are generally held, sufficient locks to modify an
object or its label may not be present for all entry points.
Locking information for arguments is documented in the MAC
framework entry point document.</para>
<para>Policy entry points will pass a reference to the object
label along with the object itself. This permits labeled
policies to be unaware of the internals of the object yet
still make decisions based on the label. The exception to this
is the process credential, which is assumed to be understood
by policies as a first class security object in the kernel.
Policies that do not implement labels on kernel objects will
be passed NULL pointers for label arguments to entry
points.</para>
</sect1>
<sect1 id="mac-entry-point-reference">
<title>MAC Policy Entry Point Reference</title>
<sect2 id="mac-mpo-general">
<title>General-Purpose Module Entry Points</title>
<sect3 id="mac-mpo-init">
<title><function>&mac.mpo;_init</function</title>