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
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
|
|
@ -369,44 +369,8 @@
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="mac-entry-point">
|
<sect1 id="mac-policy-declaration">
|
||||||
<title>Entry Point Framework</title>
|
<title>MAC Policy Declaration</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>
|
|
||||||
|
|
||||||
<para>Modules may be declared using the
|
<para>Modules may be declared using the
|
||||||
<function>MAC_POLICY_SET()</function> macro, which names 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
|
is loaded before the network subsystem is active (i.e., the
|
||||||
policy is not being loaded late), then all Mbufs are guaranteed
|
policy is not being loaded late), then all Mbufs are guaranteed
|
||||||
to have label storage.</para></note>
|
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">
|
<sect3 id="mac-mpo-init">
|
||||||
<title><function>&mac.mpo;_init</function</title>
|
<title><function>&mac.mpo;_init</function</title>
|
||||||
|
|
|
||||||
|
|
@ -369,44 +369,8 @@
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="mac-entry-point">
|
<sect1 id="mac-policy-declaration">
|
||||||
<title>Entry Point Framework</title>
|
<title>MAC Policy Declaration</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>
|
|
||||||
|
|
||||||
<para>Modules may be declared using the
|
<para>Modules may be declared using the
|
||||||
<function>MAC_POLICY_SET()</function> macro, which names 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
|
is loaded before the network subsystem is active (i.e., the
|
||||||
policy is not being loaded late), then all Mbufs are guaranteed
|
policy is not being loaded late), then all Mbufs are guaranteed
|
||||||
to have label storage.</para></note>
|
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">
|
<sect3 id="mac-mpo-init">
|
||||||
<title><function>&mac.mpo;_init</function</title>
|
<title><function>&mac.mpo;_init</function</title>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue