git: fedfc8434f - main - vale/style: Utilize vales vocabulary engine
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 04 May 2023 20:14:07 UTC
The branch main has been updated by bofh:
URL: https://cgit.FreeBSD.org/doc/commit/?id=fedfc8434f1c37b51b66fb43614cb3784f4eef13
commit fedfc8434f1c37b51b66fb43614cb3784f4eef13
Author: Muhammad Moinur Rahman <bofh@FreeBSD.org>
AuthorDate: 2023-05-04 19:23:45 +0000
Commit: Muhammad Moinur Rahman <bofh@FreeBSD.org>
CommitDate: 2023-05-04 20:13:56 +0000
vale/style: Utilize vales vocabulary engine
- Remove spelling-exceptions list
- Vale has it's own engine to add custom vocabulary for adding project
specific keywords. Add a vocabulary named Terms
- Add the file accept.txt which words should be accepted without any
errors
- Utilize documentation/content/en/books/arch-handbook/mac/_index.adoc
as proof of concept to remove all sort of errors/warnings/suggestion.
- Remove EOLSpace
- Fix Semantic Line Breakings
- Add relevant keywords to the new Vocab file accept.txt
- Some codewords were not marked with single tick ` so mark those properly
that spelling engine do not throw errors
Approved by: carlavilla (mentor)
Differential Revision: https://reviews.freebsd.org/D39703
---
.vale.ini | 1 +
.vale/styles/FreeBSD/spelling-exceptions.txt | 79 -
.vale/styles/Vocab/Terms/accept.txt | 32 +
.../content/en/books/arch-handbook/mac/_index.adoc | 1570 ++++++++++++--------
4 files changed, 978 insertions(+), 704 deletions(-)
diff --git a/.vale.ini b/.vale.ini
index 4364a08aaf..60ce75b98d 100644
--- a/.vale.ini
+++ b/.vale.ini
@@ -1,5 +1,6 @@
StylesPath = .vale/styles
MinAlertLevel = suggestion
+Vocab = Terms
[asciidoctor]
# enable
diff --git a/.vale/styles/FreeBSD/spelling-exceptions.txt b/.vale/styles/FreeBSD/spelling-exceptions.txt
deleted file mode 100644
index bd3e66f545..0000000000
--- a/.vale/styles/FreeBSD/spelling-exceptions.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Accetta
-Beranek
-Cheriton
-[Cc]hroot
-DARPA
-Englewood
-Ethernets
-Ewens
-Excelan
-FIFOs
-Filestores
-Fortran
-Gandi
-Gingell
-Interlan
-Interprocess
-Karels
-Kbyte
-Kernighan
-Macklem
-Makefile
-Microsystems
-O'Reilly
-Ousterhout
-Ritchie
-Rosenblum
-Rozier
-Sebastopol
-Tevanian
-Winsock
-autoconfiguration
-basename
-chdir
-checksubdir
-chmod
-chown
-coroutine
-coroutines
-datagrams
-deallocate
-deallocation
-descendents
-distfile
-errno
-execve
-fchmod
-fchown
-filestore
-filestores
-fstat
-interprocess
-lseek
-malloc
-mkdir
-mknod
-mmap
-multiuser
-noncanonical
-nongraphic
-pathnames
-poudriere
-prepended
-public_html
-[Qq]uarterly
-readv
-recv
-recvfrom
-recvmsg
-reimplemented
-rmdir
-rmport
-sendmsg
-sendto
-subhierarchies
-subdirectory
-unbuffered
-untyped
-vnode
-writev
diff --git a/.vale/styles/Vocab/Terms/accept.txt b/.vale/styles/Vocab/Terms/accept.txt
new file mode 100644
index 0000000000..7b081da1af
--- /dev/null
+++ b/.vale/styles/Vocab/Terms/accept.txt
@@ -0,0 +1,32 @@
+(?i)bpf
+APIs
+Biba
+DTDs
+Redistributions
+Safeport
+[Dd]atagram
+[Dd]evfs
+[Mm]map
+[Uu]serland
+[Vv]node
+demultiplexer
+dereference
+errno
+ioctls
+lookups
+mbuf
+multicast
+multilabel
+multithreaded
+mutex
+namespace
+procfs
+pluggable
+statfs
+syscall
+sysctl\'s
+tunables
+uid
+unloadable
+vp
+wakeup
diff --git a/documentation/content/en/books/arch-handbook/mac/_index.adoc b/documentation/content/en/books/arch-handbook/mac/_index.adoc
index a1ee13c101..4cc5b3be83 100644
--- a/documentation/content/en/books/arch-handbook/mac/_index.adoc
+++ b/documentation/content/en/books/arch-handbook/mac/_index.adoc
@@ -1,6 +1,6 @@
---
title: Chapter 6. The TrustedBSD MAC Framework
-authors:
+authors:
- author: Chris Costello
email: chris@FreeBSD.org
- author: Robert Watson
@@ -64,34 +64,46 @@ Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML
[IMPORTANT]
====
-THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS ASSOCIATES TECHNOLOGY, INC "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL NETWORKS ASSOCIATES TECHNOLOGY, INC BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS ASSOCIATES TECHNOLOGY, INC "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL NETWORKS ASSOCIATES TECHNOLOGY, INC BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
====
[[mac-synopsis]]
== Synopsis
-FreeBSD includes experimental support for several mandatory access control policies, as well as a framework for kernel security extensibility, the TrustedBSD MAC Framework. The MAC Framework is a pluggable access control framework, permitting new security policies to be easily linked into the kernel, loaded at boot, or loaded dynamically at run-time. The framework provides a variety of features to make it easier to implement new security policies, including the ability to easily tag security labels (such as confidentiality information) onto system objects.
+FreeBSD includes experimental support for several mandatory access control policies, as well as a framework for kernel security extensibility, the TrustedBSD MAC Framework.
+The MAC Framework is a pluggable access control framework, permitting new security policies to be easily linked into the kernel, loaded at boot, or loaded dynamically at run-time.
+The framework provides a variety of features to make it easier to implement new security policies, including the ability to easily tag security labels (such as confidentiality information) onto system objects.
This chapter introduces the MAC policy framework and provides documentation for a sample MAC policy module.
[[mac-introduction]]
== Introduction
-The TrustedBSD MAC framework provides a mechanism to allow 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. The MAC Framework provides a variety of access control infrastructure services to assist policy writers, including support for transient and persistent policy-agnostic object security labels. This support is currently considered experimental.
+The TrustedBSD MAC framework provides a mechanism to allow 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.
+The MAC Framework provides a variety of access control infrastructure services to assist policy writers, including support for transient and persistent policy-agnostic object security labels.
+This support is currently considered experimental.
This chapter provides information appropriate for developers of policy modules, as well as potential consumers of MAC-enabled environments, to learn about how the MAC Framework supports access control extension of the kernel.
[[mac-background]]
== Policy Background
-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), Domain and Type Enforcement (DTE), 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.
+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), Domain and Type Enforcement (DTE), 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.
-The TrustedBSD MAC Framework is capable of supporting policy modules that implement all of these policies, as well as a broad class of system hardening policies, which may use existing security attributes, such as user and group IDs, as well as extended attributes on files, and other system properties. In addition, despite the name, the MAC Framework can also be used to implement purely discretionary policies, as policy modules are given substantial flexibility in how they authorize protections.
+The TrustedBSD MAC Framework is capable of supporting policy modules that implement all of these policies, as well as a broad class of system hardening policies, which may use existing security attributes, such as user and group IDs, as well as extended attributes on files, and other system properties.
+In addition, despite the name, the MAC Framework can also be used to implement purely discretionary policies, as policy modules are given substantial flexibility in how they authorize protections.
[[mac-framework-kernel-arch]]
== MAC Framework Kernel Architecture
-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 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.
[[mac-framework-kernel-arch-elements]]
=== Kernel Elements
@@ -116,56 +128,103 @@ The MAC Framework contains a number of kernel elements:
The TrustedBSD MAC Framework may be directly managed using sysctl's, loader tunables, and system calls.
-In most cases, sysctl's and loader tunables of the same name modify the same parameters, and control behavior such as enforcement of protections relating to various kernel subsystems. In addition, if MAC debugging support is compiled into the kernel, several counters will be maintained tracking label allocation. It is generally advisable that per-subsystem enforcement controls not be used to control policy behavior in production environments, as they broadly impact the operation of all active policies. Instead, per-policy controls should be preferred, as they provide greater granularity and greater operational consistency for policy modules.
+In most cases, sysctl's and loader tunables of the same name modify the same parameters, and control behavior such as enforcement of protections relating to various kernel subsystems.
+In addition, if MAC debugging support is compiled into the kernel, several counters will be maintained tracking label allocation.
+It is generally advisable that per-subsystem enforcement controls not be used to control policy behavior in production environments, as they broadly impact the operation of all active policies.
+Instead, per-policy controls should be preferred, as they provide greater granularity and greater operational consistency for policy modules.
Loading and unloading of policy modules is performed using the system module management system calls and other system interfaces, including boot loader variables; policy modules will have the opportunity to influence load and unload events, including preventing undesired unloading of the policy.
[[mac-framework-kernel-arch-synchronization]]
=== Policy List Concurrency and Synchronization
-As the set of active policies may change at run-time, and the invocation of entry points is non-atomic, synchronization is required to prevent loading or unloading of policies while an entry point invocation is in progress, freezing the set of active policies for the duration. This is accomplished by means of a framework busy count: whenever an entry point is entered, the busy count is incremented; whenever it is exited, the busy count is decremented. While the busy count is elevated, policy list changes are not permitted, and threads attempting to modify the policy list will sleep until the list is not busy. The busy count is protected by a mutex, and a condition variable is used to wake up sleepers waiting on policy list modifications. One side effect of this synchronization model is that recursion into the MAC Framework from within a policy module is permitted, although not generally used.
+As the set of active policies may change at run-time, and the invocation of entry points is non-atomic, synchronization is required to prevent loading or unloading of policies while an entry point invocation is in progress, freezing the set of active policies for the duration.
+This is accomplished by means of a framework busy count: whenever an entry point is entered, the busy count is incremented; whenever it is exited, the busy count is decremented.
+While the busy count is elevated, policy list changes are not permitted, and threads attempting to modify the policy list will sleep until the list is not busy.
+The busy count is protected by a mutex, and a condition variable is used to wake up sleepers waiting on policy list modifications.
+One side effect of this synchronization model is that recursion into the MAC Framework from within a policy module is permitted, although not generally used.
-Various optimizations are used to reduce the overhead of the busy count, including avoiding the full cost of incrementing and decrementing if the list is empty or contains only static entries (policies that are loaded before the system starts, and cannot be unloaded). A compile-time option is also provided which prevents any change in the set of loaded policies at run-time, which eliminates the mutex locking costs associated with supporting dynamically loaded and unloaded policies as synchronization is no longer required.
+Various optimizations are used to reduce the overhead of the busy count, including avoiding the full cost of incrementing and decrementing if the list is empty or contains only static entries (policies that are loaded before the system starts, and cannot be unloaded).
+A compile-time option is also provided which prevents any change in the set of loaded policies at run-time, which eliminates the mutex locking costs associated with supporting dynamically loaded and unloaded policies as synchronization is no longer required.
As the MAC Framework is not permitted to block in some entry points, a normal sleep lock cannot be used; as a result, it is possible for the load or unload attempt to block for a substantial period of time waiting for the framework to become idle.
[[mac-framework-kernel-arch-label-synchronization]]
=== Label Synchronization
-As kernel objects of interest may generally be accessed from more than one thread at a time, and simultaneous entry of more than one thread into the MAC Framework is permitted, security attribute storage maintained by the MAC Framework is carefully synchronized. In general, existing kernel synchronization on kernel object data is used to protect MAC Framework security labels on the object: for example, MAC labels on sockets are protected using the existing socket mutex. Likewise, semantics for concurrent access are generally identical to those of the container objects: for credentials, copy-on-write semantics are maintained for label contents as with the remainder of the credential structure. The MAC Framework asserts necessary locks on objects when invoked with an object reference. Policy authors must be aware of these synchronization semantics, as they will sometimes limit the types of accesses permitted on labels: for example, when a read-only reference to a credential is passed
to a policy via an entry point, only read operations are permitted on the label state attached to the credential.
+As kernel objects of interest may generally be accessed from more than one thread at a time, and simultaneous entry of more than one thread into the MAC Framework is permitted, security attribute storage maintained by the MAC Framework is carefully synchronized.
+In general, existing kernel synchronization on kernel object data is used to protect MAC Framework security labels on the object: for example, MAC labels on sockets are protected using the existing socket mutex.
+Likewise, semantics for concurrent access are generally identical to those of the container objects: for credentials, copy-on-write semantics are maintained for label contents as with the remainder of the credential structure.
+The MAC Framework asserts necessary locks on objects when invoked with an object reference.
+Policy authors must be aware of these synchronization semantics, as they will sometimes limit the types of accesses permitted on labels: for example, when a read-only reference to a credential is passed to a policy via an entry point, only read operations are permitted on the label state attached to the credential.
[[mac-framework-kernel-arch-policy-synchronization]]
=== Policy Synchronization and Concurrency
-Policy modules must be written to assume that many kernel threads may simultaneously enter one more policy entry points due to the parallel and preemptive nature of the FreeBSD kernel. If the policy module makes use of mutable state, this may require the use of synchronization primitives within the policy to prevent inconsistent views on that state resulting in incorrect operation of the policy. Policies will generally be able to make use of existing FreeBSD synchronization primitives for this purpose, including mutexes, sleep locks, condition variables, and counting semaphores. However, policies should be written to employ these primitives carefully, respecting existing kernel lock orders, and recognizing that some entry points are not permitted to sleep, limiting the use of primitives in those entry points to mutexes and wakeup operations.
+Policy modules must be written to assume that many kernel threads may simultaneously enter one more policy entry points due to the parallel and preemptive nature of the FreeBSD kernel.
+If the policy module makes use of mutable state, this may require the use of synchronization primitives within the policy to prevent inconsistent views on that state resulting in incorrect operation of the policy.
+Policies will generally be able to make use of existing FreeBSD synchronization primitives for this purpose, including mutexes, sleep locks, condition variables, and counting semaphores.
+However, policies should be written to employ these primitives carefully, respecting existing kernel lock orders, and recognizing that some entry points are not permitted to sleep, limiting the use of primitives in those entry points to mutexes and wakeup operations.
-When policy modules call out to other kernel subsystems, they will generally need to release any in-policy locks in order to avoid violating the kernel lock order or risking lock recursion. This will maintain policy locks as leaf locks in the global lock order, helping to avoid deadlock.
+When policy modules call out to other kernel subsystems, they will generally need to release any in-policy locks in order to avoid violating the kernel lock order or risking lock recursion.
+This will maintain policy locks as leaf locks in the global lock order, helping to avoid deadlock.
[[mac-framework-kernel-arch-registration]]
=== Policy Registration
-The MAC Framework maintains two lists of active policies: a static list, and a dynamic list. The lists differ only with regards to their locking semantics: an elevated reference count is not required to make use of the static list. When kernel modules containing MAC Framework policies are loaded, the policy module will use `SYSINIT` to invoke a registration function; when a policy module is unloaded, `SYSINIT` will likewise invoke a de-registration function. Registration may fail if a policy module is loaded more than once, if insufficient resources are available for the registration (for example, the policy might require labeling and insufficient labeling state might be available), or other policy prerequisites might not be met (some policies may only be loaded prior to boot). Likewise, de-registration may fail if a policy is flagged as not unloadable.
+The MAC Framework maintains two lists of active policies: a static list, and a dynamic list.
+The lists differ only with regards to their locking semantics: an elevated reference count is not required to make use of the static list.
+When kernel modules containing MAC Framework policies are loaded, the policy module will use `SYSINIT` to invoke a registration function; when a policy module is unloaded, `SYSINIT` will likewise invoke a de-registration function.
+Registration may fail if a policy module is loaded more than once, if insufficient resources are available for the registration (for example, the policy might require labeling and insufficient labeling state might be available), or other policy prerequisites might not be met (some policies may only be loaded prior to boot).
+Likewise, de-registration may fail if a policy is flagged as not unloadable.
[[mac-framework-kernel-arch-entrypoints]]
=== Entry Points
-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 provide a policy-agnostic label structure pointer in security-relevant objects. The label pointer 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 non-invasive changes to the kernel subsystem maintaining the object. For example, label pointers 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). Most of these security critical decisions will be explicit access control checks; however, so
me affect more general decision functions such as packet matching for sockets and label transition at program execution.
+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 provide a policy-agnostic label structure pointer in security-relevant objects.
+The label pointer 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 non-invasive changes to the kernel subsystem maintaining the object.
+For example, label pointers 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).
+Most of these security critical decisions will be explicit access control checks; however, some affect more general decision functions such as packet matching for sockets and label transition at program execution.
[[mac-framework-kernel-arch-composition]]
=== Policy Composition
-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 return success. As policies may return a variety of error conditions (success, access denied, object does not exist, ...), a precedence operator selects the resulting error from the set of errors returned by policies. In general, errors indicating that an object does not exist will be preferred to errors indicating that access to an object is denied. While it is not guaranteed that the resulting composition will be useful or secure, we have found that it is for many useful selections of policies. For example, traditional trusted systems often ship with two or more policies using a similar composition.
+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 return success.
+As policies may return a variety of error conditions (success, access denied, object does not exist, ...), a precedence operator selects the resulting error from the set of errors returned by policies.
+In general, errors indicating that an object does not exist will be preferred to errors indicating that access to an object is denied.
+While it is not guaranteed that the resulting composition will be useful or secure, we have found that it is for many useful selections of policies.
+For example, traditional trusted systems often ship with two or more policies using a similar composition.
[[mac-framework-kernel-arch-labels]]
=== Labeling Support
-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. By policy agnostic, we mean that policy modules are able to completely define the semantics of meta-data associated with an object. 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.
-
-In-memory labels are stored in slab-allocated `struct label`, which consists of a fixed-length array of unions, each holding a `void *` pointer and a `long`. Policies registering for label storage will be assigned a "slot" identifier, which may be used to dereference the label storage. The semantics of the storage are left entirely up to the policy module: modules are provided with a variety of entry points associated with the kernel object life cycle, including initialization, association/creation, and destruction. Using these interfaces, it is possible to implement reference counting and other storage models. Direct access to the object structure is generally not required by policy modules to retrieve a label, as the MAC Framework generally passes both a pointer to the object and a direct pointer to the object's label into entry points. The primary exception to this rule is the process credential, which must be manually dereferenced to access the credential label. This may change
in future revisions of the MAC Framework.
-
-Initialization entry points frequently include a sleeping disposition flag indicating whether or not an initialization is permitted to sleep; if sleeping is not permitted, a failure may be returned to cancel allocation of the label (and hence object). This may occur, for example, in the network stack during interrupt handling, where sleeping is not permitted, or while the caller holds a mutex. Due to the performance cost of maintaining labels on in-flight network packets (Mbufs), policies must specifically declare a requirement that Mbuf labels be allocated. Dynamically loaded policies making use of labels must be able to handle the case where their init function has not been called on an object, as objects may already exist when the policy is loaded. The MAC Framework guarantees that uninitialized label slots will hold a 0 or NULL value, which policies may use to detect uninitialized values. However, as allocation of Mbuf labels is conditional, policies must also be able to handle
a NULL label pointer for Mbufs if they have been loaded dynamically.
-
-In the case of file system labels, special support is provided for the persistent storage of security labels in extended attributes. Where available, extended attribute transactions are used to permit consistent compound updates of security labels on vnodes--currently this support is present only in the UFS2 file system. Policy authors may choose to implement multilabel file system object labels using one (or more) extended attributes. For efficiency reasons, the vnode label (`v_label`) is a cache of any on-disk label; policies are able to load values into the cache when the vnode is instantiated, and update the cache as needed. As a result, the extended attribute need not be directly accessed with every access control check.
+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.
+By policy agnostic, we mean that policy modules are able to completely define the semantics of meta-data associated with an object.
+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.
+
+In-memory labels are stored in slab-allocated `struct label`, which consists of a fixed-length array of unions, each holding a `void *` pointer and a `long`.
+Policies registering for label storage will be assigned a "slot" identifier, which may be used to dereference the label storage.
+The semantics of the storage are left entirely up to the policy module: modules are provided with a variety of entry points associated with the kernel object life cycle, including initialization, association/creation, and destruction.
+Using these interfaces, it is possible to implement reference counting and other storage models.
+Direct access to the object structure is generally not required by policy modules to retrieve a label, as the MAC Framework generally passes both a pointer to the object and a direct pointer to the object's label into entry points.
+The primary exception to this rule is the process credential, which must be manually dereferenced to access the credential label.
+This may change in future revisions of the MAC Framework.
+
+Initialization entry points frequently include a sleeping disposition flag indicating whether or not an initialization is permitted to sleep; if sleeping is not permitted, a failure may be returned to cancel allocation of the label (and hence object).
+This may occur, for example, in the network stack during interrupt handling, where sleeping is not permitted, or while the caller holds a mutex.
+Due to the performance cost of maintaining labels on in-flight network packets (Mbufs), policies must specifically declare a requirement that Mbuf labels be allocated.
+Dynamically loaded policies making use of labels must be able to handle the case where their init function has not been called on an object, as objects may already exist when the policy is loaded.
+The MAC Framework guarantees that uninitialized label slots will hold a 0 or NULL value, which policies may use to detect uninitialized values.
+However, as allocation of Mbuf labels is conditional, policies must also be able to handle a NULL label pointer for Mbufs if they have been loaded dynamically.
+
+In the case of file system labels, special support is provided for the persistent storage of security labels in extended attributes.
+Where available, extended attribute transactions are used to permit consistent compound updates of security labels on vnodes--currently this support is present only in the UFS2 file system.
+Policy authors may choose to implement multilabel file system object labels using one (or more) extended attributes.
+For efficiency reasons, the vnode label (`v_label`) is a cache of any on-disk label; policies are able to load values into the cache when the vnode is instantiated, and update the cache as needed.
+As a result, the extended attribute need not be directly accessed with every access control check.
[NOTE]
====
@@ -177,7 +236,11 @@ Currently, if a labeled policy permits dynamic unloading, its state slot cannot
The MAC Framework implements a number of system calls: most of these calls support the policy-agnostic label retrieval and manipulation APIs exposed to user applications.
-The label management calls accept a label description structure, `struct mac`, which contains a series of MAC label elements. Each element contains a character string name, and character string value. Each policy will be given the chance to claim a particular element name, permitting policies to expose multiple independent elements if desired. Policy modules perform the internalization and externalization between kernel labels and user-provided labels via entry points, permitting a variety of semantics. Label management system calls are generally wrapped by user library functions to perform memory allocation and error handling, simplifying user applications that must manage labels.
+The label management calls accept a label description structure, `struct mac`, which contains a series of MAC label elements.
+Each element contains a character string name, and character string value.
+Each policy will be given the chance to claim a particular element name, permitting policies to expose multiple independent elements if desired.
+Policy modules perform the internalization and externalization between kernel labels and user-provided labels via entry points, permitting a variety of semantics.
+Label management system calls are generally wrapped by user library functions to perform memory allocation and error handling, simplifying user applications that must manage labels.
The following MAC-related system calls are present in the FreeBSD kernel:
@@ -191,7 +254,8 @@ The following MAC-related system calls are present in the FreeBSD kernel:
* `mac_get_pid()` may be used to request the label of another process by process id.
* `mac_get_link()` is identical to `mac_get_file()`, only it will not follow a symbolic link if it is the final entry in the path, so may be used to retrieve the label on a symlink.
* `mac_set_link()` is identical to `mac_set_file()`, only it will not follow a symbolic link if it is the final entry in a path, so may be used to manipulate the label on a symlink.
-* `mac_execve()` is identical to the `execve()` system call, only it also accepts a requested label to set the process label to when beginning execution of a new program. This change in label on execution is referred to as a "transition".
+* `mac_execve()` is identical to the `execve()` system call, only it also accepts a requested label to set the process label to when beginning execution of a new program.
+This change in label on execution is referred to as a "transition".
* `mac_get_peer()`, actually implemented via a socket option, retrieves the label of a remote peer on a socket, if available.
In addition to these system calls, the `SIOCSIGMAC` and `SIOCSIFMAC` network interface ioctls permit the labels on network interfaces to be retrieved and set.
@@ -199,7 +263,9 @@ In addition to these system calls, the `SIOCSIGMAC` and `SIOCSIFMAC` network int
[[mac-policy-architecture]]
== MAC Policy Architecture
-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:
+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:
* Optional configuration parameters for policy.
* Centralized implementation of the policy logic and parameters.
@@ -229,37 +295,61 @@ static struct mac_policy_ops mac_policy_ops =
};
....
-The MAC policy entry point vector, `mac__policy__ops` in this example, associates functions defined in the module with specific entry points. A complete listing of available entry points and their prototypes may be found in the MAC entry point reference section. Of specific interest during module registration are the .mpo_destroy and .mpo_init entry points. .mpo_init will be invoked once a policy is successfully registered with the module framework but prior to any other entry points becoming active. This permits the policy to perform any policy-specific allocation and initialization, such as initialization of any data or locks. .mpo_destroy will be invoked when a policy module is unloaded to permit releasing of any allocated memory and destruction of locks. Currently, these two entry points are invoked with the MAC policy list mutex held to prevent any other entry points from being invoked: this will be changed, but in the mean time, policies should be careful about what kernel pri
mitives they invoke so as to avoid lock ordering or sleeping problems.
+The MAC policy entry point vector, `mac__policy__ops` in this example, associates functions defined in the module with specific entry points.
+A complete listing of available entry points and their prototypes may be found in the MAC entry point reference section.
+Of specific interest during module registration are the .mpo_destroy and .mpo_init entry points.
+.mpo_init will be invoked once a policy is successfully registered with the module framework but prior to any other entry points becoming active.
+This permits the policy to perform any policy-specific allocation and initialization, such as initialization of any data or locks.
+.mpo_destroy will be invoked when a policy module is unloaded to permit releasing of any allocated memory and destruction of locks.
+Currently, these two entry points are invoked with the MAC policy list mutex held to prevent any other entry points from being invoked: this will be changed, but in the mean time, policies should be careful about what kernel primitives they invoke so as to avoid lock ordering or sleeping problems.
-The policy declaration's module name field exists so that the module may be uniquely identified for the purposes of module dependencies. An appropriate string should be selected. The full string name of the policy is displayed to the user via the kernel log during load and unload events, and also exported when providing status information to userland processes.
+The policy declaration's module name field exists so that the module may be uniquely identified for the purposes of module dependencies.
+An appropriate string should be selected.
+The full string name of the policy is displayed to the user via the kernel log during load and unload events, and also exported when providing status information to userland processes.
[[mac-policy-flags]]
=== Policy Flags
-The policy declaration flags field permits the module to provide the framework with information about its capabilities at the time the module is loaded. Currently, three flags are defined:
+The policy declaration flags field permits the module to provide the framework with information about its capabilities at the time the module is loaded.
+Currently, three flags are defined:
MPC_LOADTIME_FLAG_UNLOADOK::
-This flag indicates that the policy module may be unloaded. If this flag is not provided, then the policy framework will reject requests to unload the module. This flag might be used by modules that allocate label state and are unable to free that state at runtime.
+This flag indicates that the policy module may be unloaded.
+If this flag is not provided, then the policy framework will reject requests to unload the module.
+This flag might be used by modules that allocate label state and are unable to free that state at runtime.
MPC_LOADTIME_FLAG_NOTLATE::
-This flag indicates that the policy module must be loaded and initialized early in the boot process. If the flag is specified, attempts to register the module following boot will be rejected. The flag may be used by policies that require pervasive labeling of all system objects, and cannot handle objects that have not been properly initialized by the policy.
+This flag indicates that the policy module must be loaded and initialized early in the boot process.
+If the flag is specified, attempts to register the module following boot will be rejected.
+The flag may be used by policies that require pervasive labeling of all system objects, and cannot handle objects that have not been properly initialized by the policy.
MPC_LOADTIME_FLAG_LABELMBUFS::
-This flag indicates that the policy module requires labeling of Mbufs, and that memory should always be allocated for the storage of Mbuf labels. By default, the MAC Framework will not allocate label storage for Mbufs unless at least one loaded policy has this flag set. This measurably improves network performance when policies do not require Mbuf labeling. A kernel option, `MAC_ALWAYS_LABEL_MBUF`, exists to force the MAC Framework to allocate Mbuf label storage regardless of the setting of this flag, and may be useful in some environments.
+This flag indicates that the policy module requires labeling of Mbufs, and that memory should always be allocated for the storage of Mbuf labels.
+By default, the MAC Framework will not allocate label storage for Mbufs unless at least one loaded policy has this flag set.
+This measurably improves network performance when policies do not require Mbuf labeling.
+A kernel option, `MAC_ALWAYS_LABEL_MBUF`, exists to force the MAC Framework to allocate Mbuf label storage regardless of the setting of this flag, and may be useful in some environments.
[NOTE]
====
-Policies using the `MPC_LOADTIME_FLAG_LABELMBUFS` without the `MPC_LOADTIME_FLAG_NOTLATE` flag set must be able to correctly handle `NULL` Mbuf label pointers passed into entry points. This is necessary as in-flight Mbufs without label storage may persist after a policy enabling Mbuf labeling has been loaded. If a policy 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.
+Policies using the `MPC_LOADTIME_FLAG_LABELMBUFS` without the `MPC_LOADTIME_FLAG_NOTLATE` flag set must be able to correctly handle `NULL` Mbuf label pointers passed into entry points.
+This is necessary as in-flight Mbufs without label storage may persist after a policy enabling Mbuf labeling has been loaded.
+If a policy 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.
====
[[mac-policy-entry-points]]
=== Policy Entry Points
-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 `mac_syscall()` entry point is provided so that policies may extend the kernel interface without registering new system calls.
+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 `mac_syscall()` entry point is provided so that policies may extend the kernel interface without registering new system calls.
-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.
+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.
-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.
+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.
[[mac-entry-point-reference]]
== MAC Policy Entry Point Reference
@@ -272,7 +362,7 @@ Policy entry points will pass a reference to the object label along with the obj
[source,c]
----
-void mpo_init( conf);
+void mpo_init( conf);
struct mac_policy_conf *conf;
----
@@ -288,14 +378,16 @@ struct mac_policy_conf *conf;
|
|===
-Policy load event. The policy list mutex is held, so sleep operations cannot be performed, and calls out to other kernel subsystems must be made with caution. If potentially sleeping memory allocations are required during policy initialization, they should be made using a separate module SYSINIT().
+Policy load event.
+The policy list mutex is held, so sleep operations cannot be performed, and calls out to other kernel subsystems must be made with caution.
+If potentially sleeping memory allocations are required during policy initialization, they should be made using a separate module SYSINIT().
[[mpo-destroy]]
==== `mpo_destroy`
[source,c]
----
-void mpo_destroy( conf);
+void mpo_destroy( conf);
struct mac_policy_conf *conf;
----
@@ -311,16 +403,17 @@ struct mac_policy_conf *conf;
|
|===
-Policy load event. The policy list mutex is held, so caution should be applied.
+Policy load event.
+The policy list mutex is held, so caution should be applied.
[[mac-mpo-syscall]]
==== `mpo_syscall`
[source,c]
----
-int mpo_syscall( td,
- call,
- arg);
+int mpo_syscall( td,
+ call,
+ arg);
struct thread *td;
int call;
void *arg;
@@ -346,7 +439,10 @@ void *arg;
|
|===
-This entry point provides a policy-multiplexed system call so that policies may provide additional services to user processes without registering specific system calls. The policy name provided during registration is used to demux calls from userland, and the arguments will be forwarded to this entry point. When implementing new services, security modules should be sure to invoke appropriate access control checks from the MAC framework as needed. For example, if a policy implements an augmented signal functionality, it should call the necessary signal access control checks to invoke the MAC framework and other registered policies.
+This entry point provides a policy-multiplexed system call so that policies may provide additional services to user processes without registering specific system calls.
+The policy name provided during registration is used to demultiplexer calls from userland, and the arguments will be forwarded to this entry point.
+When implementing new services, security modules should be sure to invoke appropriate access control checks from the MAC framework as needed.
+For example, if a policy implements an augmented signal functionality, it should call the necessary signal access control checks to invoke the MAC framework and other registered policies.
[NOTE]
====
@@ -358,7 +454,7 @@ Modules must currently perform the `copyin()` of the syscall data on their own.
[source,c]
----
-void mpo_thread_userret( td);
+void mpo_thread_userret( td);
struct thread *td;
----
@@ -374,7 +470,11 @@ struct thread *td;
|
|===
-This entry point permits policy modules to perform MAC-related events when a thread returns to user space, via a system call return, trap return, or otherwise. This is required for policies that have floating process labels, as it is not always possible to acquire the process lock at arbitrary points in the stack during system call processing; process labels might represent traditional authentication data, process history information, or other data. To employ this mechanism, intended changes to the process credential label may be stored in the `p_label` protected by a per-policy spin lock, and then set the per-thread `TDF_ASTPENDING` flag and per-process `PS_MACPENDM` flag to schedule a call to the userret entry point. From this entry point, the policy may create a replacement credential with less concern about the locking context. Policy writers are cautioned that event ordering relating to scheduling an AST and the AST being performed may be complex and interlaced in multithreaded
applications.
+This entry point permits policy modules to perform MAC-related events when a thread returns to user space, via a system call return, trap return, or otherwise.
+This is required for policies that have floating process labels, as it is not always possible to acquire the process lock at arbitrary points in the stack during system call processing; process labels might represent traditional authentication data, process history information, or other data.
+To employ this mechanism, intended changes to the process credential label may be stored in the `p_label` protected by a per-policy spin lock, and then set the per-thread `TDF_ASTPENDING` flag and per-process `PS_MACPENDM` flag to schedule a call to the `userret` entry point.
+From this entry point, the policy may create a replacement credential with less concern about the locking context.
+Policy writers are cautioned that event ordering relating to scheduling an AST and the AST being performed may be complex and interlaced in multithreaded applications.
[[mac-label-ops]]
=== Label Operations
@@ -384,7 +484,7 @@ This entry point permits policy modules to perform MAC-related events when a thr
[source,c]
----
-void mpo_init_bpfdesc_label( label);
+void mpo_init_bpfdesc_label( label);
struct label *label;
----
@@ -400,14 +500,15 @@ struct label *label;
|
|===
-Initialize the label on a newly instantiated bpfdesc (BPF descriptor). Sleeping is permitted.
+Initialize the label on a newly instantiated bpfdesc (BPF descriptor).
+Sleeping is permitted.
[[mac-mpo-init-cred-label]]
==== `mpo_init_cred_label`
[source,c]
----
-void mpo_init_cred_label( label);
+void mpo_init_cred_label( label);
struct label *label;
----
@@ -423,14 +524,15 @@ struct label *label;
|
|===
-Initialize the label for a newly instantiated user credential. Sleeping is permitted.
+Initialize the label for a newly instantiated user credential.
+Sleeping is permitted.
[[mac-mpo-init-devfsdirent]]
==== `mpo_init_devfsdirent_label`
[source,c]
----
-void mpo_init_devfsdirent_label( label);
+void mpo_init_devfsdirent_label( label);
struct label *label;
----
@@ -446,14 +548,15 @@ struct label *label;
|
|===
-Initialize the label on a newly instantiated devfs entry. Sleeping is permitted.
+Initialize the label on a newly instantiated devfs entry.
+Sleeping is permitted.
[[mac-mpo-init-ifnet]]
==== `mpo_init_ifnet_label`
[source,c]
----
-void mpo_init_ifnet_label( label);
+void mpo_init_ifnet_label( label);
struct label *label;
----
@@ -469,15 +572,16 @@ struct label *label;
|
|===
-Initialize the label on a newly instantiated network interface. Sleeping is permitted.
+Initialize the label on a newly instantiated network interface.
+Sleeping is permitted.
[[mac-mpo-init-ipq]]
==== `mpo_init_ipq_label`
[source,c]
----
-void mpo_init_ipq_label( label,
- flag);
+void mpo_init_ipq_label( label,
+ flag);
struct label *label;
int flag;
----
@@ -498,15 +602,18 @@ int flag;
|
|===
-Initialize the label on a newly instantiated IP fragment reassembly queue. The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. IP fragment reassembly queue allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations. This entry point is permitted to fail resulting in the failure to allocate the IP fragment reassembly queue.
+Initialize the label on a newly instantiated IP fragment reassembly queue.
+The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call.
+IP fragment reassembly queue allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations.
+This entry point is permitted to fail resulting in the failure to allocate the IP fragment reassembly queue.
[[mac-mpo-init-mbuf]]
==== `mpo_init_mbuf_label`
[source,c]
----
-void mpo_init_mbuf_label( flag,
- label);
+void mpo_init_mbuf_label( flag,
+ label);
int flag;
struct label *label;
----
@@ -527,15 +634,18 @@ struct label *label;
|
|===
-Initialize the label on a newly instantiated mbuf packet header (`mbuf`). The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. Mbuf allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations. This entry point is permitted to fail resulting in the failure to allocate the mbuf header.
+Initialize the label on a newly instantiated mbuf packet header (`mbuf`).
+The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call.
+Mbuf allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations.
+This entry point is permitted to fail resulting in the failure to allocate the mbuf header.
[[mac-mpo-init-mount]]
==== `mpo_init_mount_label`
[source,c]
----
-void mpo_init_mount_label( mntlabel,
- fslabel);
+void mpo_init_mount_label( mntlabel,
+ fslabel);
struct label *mntlabel;
struct label *fslabel;
----
@@ -556,14 +666,15 @@ struct label *fslabel;
|
|===
-Initialize the labels on a newly instantiated mount point. Sleeping is permitted.
+Initialize the labels on a newly instantiated mount point.
+Sleeping is permitted.
[[mac-mpo-init-mount-fs-label]]
==== `mpo_init_mount_fs_label`
[source,c]
----
-void mpo_init_mount_fs_label( label);
+void mpo_init_mount_fs_label( label);
struct label *label;
----
@@ -579,14 +690,15 @@ struct label *label;
|
|===
-Initialize the label on a newly mounted file system. Sleeping is permitted
+Initialize the label on a newly mounted file system.
+Sleeping is permitted
[[mac-mpo-init-pipe-label]]
==== `mpo_init_pipe_label`
[source,c]
----
-void mpo_init_pipe_label( label);
+void mpo_init_pipe_label( label);
struct label*label;
----
@@ -602,15 +714,16 @@ struct label*label;
|
|===
-Initialize a label for a newly instantiated pipe. Sleeping is permitted.
+Initialize a label for a newly instantiated pipe.
+Sleeping is permitted.
[[mac-mpo-init-socket]]
==== `mpo_init_socket_label`
[source,c]
----
-void mpo_init_socket_label( label,
- flag);
+void mpo_init_socket_label( label,
+ flag);
struct label *label;
int flag;
----
@@ -631,15 +744,16 @@ int flag;
|
|===
-Initialize a label for a newly instantiated socket. The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call.
+Initialize a label for a newly instantiated socket.
+The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call.
[[mac-mpo-init-socket-peer-label]]
==== `mpo_init_socket_peer_label`
[source,c]
----
-void mpo_init_socket_peer_label( label,
- flag);
+void mpo_init_socket_peer_label( label,
+ flag);
struct label *label;
int flag;
----
@@ -660,14 +774,15 @@ int flag;
|
|===
-Initialize the peer label for a newly instantiated socket. The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call.
+Initialize the peer label for a newly instantiated socket.
+The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call.
[[mac-mpo-init-proc-label]]
==== `mpo_init_proc_label`
[source,c]
----
-void mpo_init_proc_label( label);
+void mpo_init_proc_label( label);
struct label *label;
----
@@ -683,14 +798,15 @@ struct label *label;
|
|===
-Initialize the label for a newly instantiated process. Sleeping is permitted.
+Initialize the label for a newly instantiated process.
+Sleeping is permitted.
[[mac-mpo-init-vnode]]
==== `mpo_init_vnode_label`
[source,c]
----
-void mpo_init_vnode_label( label);
+void mpo_init_vnode_label( label);
struct label *label;
----
@@ -706,14 +822,15 @@ struct label *label;
|
|===
-Initialize the label on a newly instantiated vnode. Sleeping is permitted.
+Initialize the label on a newly instantiated vnode.
+Sleeping is permitted.
[[mac-mpo-destroy-bpfdesc]]
==== `mpo_destroy_bpfdesc_label`
[source,c]
----
-void mpo_destroy_bpfdesc_label( label);
+void mpo_destroy_bpfdesc_label( label);
struct label *label;
----
@@ -729,14 +846,15 @@ struct label *label;
|
|===
-Destroy the label on a BPF descriptor. In this entry point a policy should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the label on a BPF descriptor.
+In this entry point a policy should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-cred]]
==== `mpo_destroy_cred_label`
[source,c]
----
-void mpo_destroy_cred_label( label);
+void mpo_destroy_cred_label( label);
struct label *label;
----
@@ -752,14 +870,15 @@ struct label *label;
|
|===
-Destroy the label on a credential. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the label on a credential.
+In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-devfsdirent]]
==== `mpo_destroy_devfsdirent_label`
[source,c]
----
-void mpo_destroy_devfsdirent_label( label);
+void mpo_destroy_devfsdirent_label( label);
struct label *label;
----
@@ -775,14 +894,15 @@ struct label *label;
|
|===
-Destroy the label on a devfs entry. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the label on a devfs entry.
+In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-ifnet-label]]
==== `mpo_destroy_ifnet_label`
[source,c]
----
-void mpo_destroy_ifnet_label( label);
+void mpo_destroy_ifnet_label( label);
struct label *label;
----
@@ -798,14 +918,15 @@ struct label *label;
|
|===
-Destroy the label on a removed interface. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the label on a removed interface.
+In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-ipq-label]]
==== `mpo_destroy_ipq_label`
[source,c]
----
-void mpo_destroy_ipq_label( label);
+void mpo_destroy_ipq_label( label);
struct label *label;
----
@@ -821,14 +942,15 @@ struct label *label;
|
|===
-Destroy the label on an IP fragment queue. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the label on an IP fragment queue.
+In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-mbuf-label]]
==== `mpo_destroy_mbuf_label`
[source,c]
----
-void mpo_destroy_mbuf_label( label);
+void mpo_destroy_mbuf_label( label);
struct label *label;
----
@@ -844,14 +966,15 @@ struct label *label;
|
|===
-Destroy the label on an mbuf header. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the label on an mbuf header.
+In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-mount-label]]
==== `mpo_destroy_mount_label`
[source,c]
----
-void mpo_destroy_mount_label( label);
+void mpo_destroy_mount_label( label);
struct label *label;
----
@@ -867,15 +990,16 @@ struct label *label;
|
|===
-Destroy the labels on a mount point. In this entry point, a policy module should free the internal storage associated with `mntlabel` so that they may be destroyed.
+Destroy the labels on a mount point.
+In this entry point, a policy module should free the internal storage associated with `mntlabel` so that they may be destroyed.
[[mac-mpo-destroy-mount]]
==== `mpo_destroy_mount_label`
[source,c]
----
-void mpo_destroy_mount_label( mntlabel,
- fslabel);
+void mpo_destroy_mount_label( mntlabel,
+ fslabel);
struct label *mntlabel;
struct label *fslabel;
----
@@ -896,14 +1020,15 @@ struct label *fslabel;
|
|===
-Destroy the labels on a mount point. In this entry point, a policy module should free the internal storage associated with `mntlabel` and `fslabel` so that they may be destroyed.
+Destroy the labels on a mount point.
+In this entry point, a policy module should free the internal storage associated with `mntlabel` and `fslabel` so that they may be destroyed.
[[mac-mpo-destroy-socket]]
==== `mpo_destroy_socket_label`
[source,c]
----
-void mpo_destroy_socket_label( label);
+void mpo_destroy_socket_label( label);
struct label *label;
----
@@ -919,14 +1044,15 @@ struct label *label;
|
|===
-Destroy the label on a socket. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the label on a socket.
+In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-socket-peer-label]]
==== `mpo_destroy_socket_peer_label`
[source,c]
----
-void mpo_destroy_socket_peer_label( peerlabel);
+void mpo_destroy_socket_peer_label( peerlabel);
struct label *peerlabel;
----
@@ -942,14 +1068,15 @@ struct label *peerlabel;
|
|===
-Destroy the peer label on a socket. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
+Destroy the peer label on a socket.
+In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
[[mac-mpo-destroy-pipe-label]]
==== `mpo_destroy_pipe_label`
[source,c]
----
-void mpo_destroy_pipe_label( label);
+void mpo_destroy_pipe_label( label);
struct label *label;
----
@@ -965,14 +1092,15 @@ struct label *label;
|
|===
-Destroy the label on a pipe. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed.
*** 2579 LINES SKIPPED ***