Spellcheck.
This commit is contained in:
parent
96eb481cbd
commit
8c1173c2f6
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=16627
2 changed files with 32 additions and 32 deletions
en_US.ISO8859-1/books
|
@ -136,7 +136,7 @@
|
|||
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 infratructure
|
||||
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.</para>
|
||||
|
@ -188,7 +188,7 @@
|
|||
|
||||
<itemizedlist>
|
||||
<listitem><para>Framework management interfaces</para></listitem>
|
||||
<listitem><para>Concurrency and synchronizatoin management
|
||||
<listitem><para>Concurrency and synchronization management
|
||||
primitives.</para></listitem>
|
||||
<listitem><para>Policy registration and management</para></listitem>
|
||||
<listitem><para>Extensible security label for kernel
|
||||
|
@ -217,13 +217,13 @@
|
|||
<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
|
||||
security-relevant 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
|
||||
through relatively non-invasive 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
|
||||
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
|
||||
|
@ -292,7 +292,7 @@
|
|||
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
|
||||
<listitem><para>Declaration of policy identity, module entry
|
||||
points, and policy properties.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
@ -1081,7 +1081,7 @@
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Destroy the label on a bpf descriptor. In this entry
|
||||
<para>Destroy the label on a BPF descriptor. In this entry
|
||||
point a policy should free any internal storage associated
|
||||
with <parameter>label</parameter> so that it may be
|
||||
destroyed.</para>
|
||||
|
@ -1876,11 +1876,11 @@ Label destruction o</programlisting>
|
|||
<para>Label initialization permits policies to allocate memory
|
||||
and set initial values for labels without context for the use
|
||||
of the object. The label slot allocated to a policy will be
|
||||
zero'd by default, so some policies may not need to perform
|
||||
zeroed by default, so some policies may not need to perform
|
||||
initialization.</para>
|
||||
|
||||
<para>Label creation occurs when the kernel structure is
|
||||
associated with an actual kernel object. For example, mbufs
|
||||
associated with an actual kernel object. For example, Mbufs
|
||||
may be allocated and remain unused in a pool until they are
|
||||
required. mbuf allocation causes label initialization on the
|
||||
mbuf to take place, but mbuf creation occurs when the mbuf is
|
||||
|
@ -5725,7 +5725,7 @@ Label destruction o</programlisting>
|
|||
|
||||
<para>Determine whether the subject credential can execute the
|
||||
passed vnode. Determination of execute privilege is made
|
||||
seperately from decisions about any transitioning event.
|
||||
separately from decisions about any transitioning event.
|
||||
Return <returnvalue>0</returnvalue> for success, or an
|
||||
<varname>errno</varname> value for failure. Suggested
|
||||
failure: <errorcode>EACCES</errorcode> for label mismatch,
|
||||
|
@ -5781,7 +5781,7 @@ Label destruction o</programlisting>
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Determine whether the subject credentical can retrieve
|
||||
<para>Determine whether the subject credential can retrieve
|
||||
the ACL of passed type from the passed vnode. Return
|
||||
<returnvalue>0</returnvalue> for success, or an
|
||||
<varname>errno</varname> value for failure. Suggested
|
||||
|
@ -6183,7 +6183,7 @@ Label destruction o</programlisting>
|
|||
|
||||
<row>
|
||||
<entry><parameter>label</parameter></entry>
|
||||
<entry>Policy label asociated with
|
||||
<entry>Policy label associated with
|
||||
<parameter>vp</parameter></entry>
|
||||
</row>
|
||||
|
||||
|
@ -6720,7 +6720,7 @@ Label destruction o</programlisting>
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Determine whether the subject credentical can set the
|
||||
<para>Determine whether the subject credential can set the
|
||||
extended attribute of passed name and passed namespace on
|
||||
the passed vnode. Policies implementing security labels
|
||||
backed into extended attributes may want to provide
|
||||
|
@ -6840,7 +6840,7 @@ Label destruction o</programlisting>
|
|||
</informaltable>
|
||||
|
||||
<para>Determine whether the subject credential can set the
|
||||
pased mode on the passed vnode. Return
|
||||
passed mode on the passed vnode. Return
|
||||
<returnvalue>0</returnvalue> for success, or an
|
||||
<varname>errno</varname> value for failure. Suggested
|
||||
failure: <errorcode>EACCES</errorcode> for label mismatch,
|
||||
|
@ -7566,7 +7566,7 @@ Label destruction o</programlisting>
|
|||
that the label on an object be modified. A two-phase update
|
||||
occurs: first, an access control check will be performed to
|
||||
determine if the update is both valid and permitted, and then
|
||||
the update itself is performed via a seperate entry point.
|
||||
the update itself is performed via a separate entry point.
|
||||
Relabel entry points typically accept the object, object label
|
||||
reference, and an update label submitted by the process.
|
||||
Memory allocation during relabel is discouraged, as relabel
|
||||
|
@ -7593,7 +7593,7 @@ Label destruction o</programlisting>
|
|||
|
||||
<para>The TrustedBSD MAC Framework provides a number of
|
||||
library and system calls permitting applications to
|
||||
manage MAC labels on objects using a poloicy-agnostic
|
||||
manage MAC labels on objects using a policy-agnostic
|
||||
interface. This permits applications to manipulate
|
||||
labels for a variety of policies without being
|
||||
written to support specific policies. These interfaces
|
||||
|
|
|
@ -136,7 +136,7 @@
|
|||
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 infratructure
|
||||
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.</para>
|
||||
|
@ -188,7 +188,7 @@
|
|||
|
||||
<itemizedlist>
|
||||
<listitem><para>Framework management interfaces</para></listitem>
|
||||
<listitem><para>Concurrency and synchronizatoin management
|
||||
<listitem><para>Concurrency and synchronization management
|
||||
primitives.</para></listitem>
|
||||
<listitem><para>Policy registration and management</para></listitem>
|
||||
<listitem><para>Extensible security label for kernel
|
||||
|
@ -217,13 +217,13 @@
|
|||
<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
|
||||
security-relevant 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
|
||||
through relatively non-invasive 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
|
||||
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
|
||||
|
@ -292,7 +292,7 @@
|
|||
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
|
||||
<listitem><para>Declaration of policy identity, module entry
|
||||
points, and policy properties.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
@ -1081,7 +1081,7 @@
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Destroy the label on a bpf descriptor. In this entry
|
||||
<para>Destroy the label on a BPF descriptor. In this entry
|
||||
point a policy should free any internal storage associated
|
||||
with <parameter>label</parameter> so that it may be
|
||||
destroyed.</para>
|
||||
|
@ -1876,11 +1876,11 @@ Label destruction o</programlisting>
|
|||
<para>Label initialization permits policies to allocate memory
|
||||
and set initial values for labels without context for the use
|
||||
of the object. The label slot allocated to a policy will be
|
||||
zero'd by default, so some policies may not need to perform
|
||||
zeroed by default, so some policies may not need to perform
|
||||
initialization.</para>
|
||||
|
||||
<para>Label creation occurs when the kernel structure is
|
||||
associated with an actual kernel object. For example, mbufs
|
||||
associated with an actual kernel object. For example, Mbufs
|
||||
may be allocated and remain unused in a pool until they are
|
||||
required. mbuf allocation causes label initialization on the
|
||||
mbuf to take place, but mbuf creation occurs when the mbuf is
|
||||
|
@ -5725,7 +5725,7 @@ Label destruction o</programlisting>
|
|||
|
||||
<para>Determine whether the subject credential can execute the
|
||||
passed vnode. Determination of execute privilege is made
|
||||
seperately from decisions about any transitioning event.
|
||||
separately from decisions about any transitioning event.
|
||||
Return <returnvalue>0</returnvalue> for success, or an
|
||||
<varname>errno</varname> value for failure. Suggested
|
||||
failure: <errorcode>EACCES</errorcode> for label mismatch,
|
||||
|
@ -5781,7 +5781,7 @@ Label destruction o</programlisting>
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Determine whether the subject credentical can retrieve
|
||||
<para>Determine whether the subject credential can retrieve
|
||||
the ACL of passed type from the passed vnode. Return
|
||||
<returnvalue>0</returnvalue> for success, or an
|
||||
<varname>errno</varname> value for failure. Suggested
|
||||
|
@ -6183,7 +6183,7 @@ Label destruction o</programlisting>
|
|||
|
||||
<row>
|
||||
<entry><parameter>label</parameter></entry>
|
||||
<entry>Policy label asociated with
|
||||
<entry>Policy label associated with
|
||||
<parameter>vp</parameter></entry>
|
||||
</row>
|
||||
|
||||
|
@ -6720,7 +6720,7 @@ Label destruction o</programlisting>
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Determine whether the subject credentical can set the
|
||||
<para>Determine whether the subject credential can set the
|
||||
extended attribute of passed name and passed namespace on
|
||||
the passed vnode. Policies implementing security labels
|
||||
backed into extended attributes may want to provide
|
||||
|
@ -6840,7 +6840,7 @@ Label destruction o</programlisting>
|
|||
</informaltable>
|
||||
|
||||
<para>Determine whether the subject credential can set the
|
||||
pased mode on the passed vnode. Return
|
||||
passed mode on the passed vnode. Return
|
||||
<returnvalue>0</returnvalue> for success, or an
|
||||
<varname>errno</varname> value for failure. Suggested
|
||||
failure: <errorcode>EACCES</errorcode> for label mismatch,
|
||||
|
@ -7566,7 +7566,7 @@ Label destruction o</programlisting>
|
|||
that the label on an object be modified. A two-phase update
|
||||
occurs: first, an access control check will be performed to
|
||||
determine if the update is both valid and permitted, and then
|
||||
the update itself is performed via a seperate entry point.
|
||||
the update itself is performed via a separate entry point.
|
||||
Relabel entry points typically accept the object, object label
|
||||
reference, and an update label submitted by the process.
|
||||
Memory allocation during relabel is discouraged, as relabel
|
||||
|
@ -7593,7 +7593,7 @@ Label destruction o</programlisting>
|
|||
|
||||
<para>The TrustedBSD MAC Framework provides a number of
|
||||
library and system calls permitting applications to
|
||||
manage MAC labels on objects using a poloicy-agnostic
|
||||
manage MAC labels on objects using a policy-agnostic
|
||||
interface. This permits applications to manipulate
|
||||
labels for a variety of policies without being
|
||||
written to support specific policies. These interfaces
|
||||
|
|
Loading…
Reference in a new issue