the MAC label referenced from 'struct socket' in the IPv4 and
IPv6-based protocols. This permits MAC labels to be checked during
network delivery operations without dereferencing inp->inp_socket
to get to so->so_label, which will eventually avoid our having to
grab the socket lock during delivery at the network layer.
This change introduces 'struct inpcb' as a labeled object to the
MAC Framework, along with the normal circus of entry points:
initialization, creation from socket, destruction, as well as a
delivery access control check.
For most policies, the inpcb label will simply be a cache of the
socket label, so a new protocol switch method is introduced,
pr_sosetlabel() to notify protocols that the socket layer label
has been updated so that the cache can be updated while holding
appropriate locks. Most protocols implement this using
pru_sosetlabel_null(), but IPv4/IPv6 protocols using inpcbs use
the the worker function in_pcbsosetlabel(), which calls into the
MAC Framework to perform a cache update.
Biba, LOMAC, and MLS implement these entry points, as do the stub
policy, and test policy.
Reviewed by: sam, bms
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
the vendor is only included in the long name currently, reducing
verbosity when modules are registered and unregistered.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
structure definition, rather than using an operation vector
we translate into the structure. Originally, we used a vector
for two reasons:
(1) We wanted to define the structure sparsely, which wasn't
supported by the C compiler for structures. For a policy
with five entry points, you don't want to have to stick in
a few hundred NULL function pointers.
(2) We thought it would improve ABI compatibility allowing modules
to work with kernels that had a superset of the entry points
defined in the module, even if the kernel had changed its
entry point set.
Both of these no longer apply:
(1) C99 gives us a way to sparsely define a static structure.
(2) The ABI problems existed anyway, due to enumeration numbers,
argument changes, and semantic mismatches. Since the going
rule for FreeBSD is that you really need your modules to
pretty closely match your kernel, it's not worth the
complexity.
This submit eliminates the operation vector, dynamic allocation
of the operation structure, copying of the vector to the
structure, and redoes the vectors in each policy to direct
structure definitions. One enourmous benefit of this change
is that we now get decent type checking on policy entry point
implementation arguments.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
we can use the names _receive() and _send() for the receive() and send()
checks. Rename related constants, policy implementations, etc.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
kernel access control.
Provide implementations of some sample operating system security
policy extensions. These are not yet hooked up to the build as
other infrastructure is still being committed. Most of these
work fairly well and are in daily use in our development and (limited)
production environments. Some are not yet in their final form,
and a number of the labeled policies waste a lot of kernel memory
and will be fixed over the next month or so to be more conservative.
They do give good examples of the flexibility of the MAC framework
for implementing a variety of security policies.
mac_biba: Implementation of fixed-label Biba integrity policy,
similar to those found in a number of commercial
trusted operating systems. All subjects and objects
are assigned integrity levels, and information flow
is controlled based on a read-up, write-down
policy. Currently, purely hierarchal.
mac_bsdextended: Implementation of a "file system firewall",
which allows the administrator to specify a series
of rules limiting access by users and groups to
objects owned by other users and groups. This
policy is unlabeled, relying on existing system
security labeling (file permissions/ownership,
process credentials).
mac_ifoff: Secure interface silencing. Special-purpose module
to limit inappropriate out-going network traffic
for silent monitoring scenarios. Prevents the
various network stacks from generating any output
despite an interface being live for reception.
mac_mls: Implementation of fixed-label Multi-Level Security
confidentiality policy, similar to those found in
a number of commercial trusted operating systems.
All subjects and objects are assigned confidentiality
levels, and information flow is controlled based on
a write-up, read-down policy. Currently, purely
hiearchal, although non-hierarchal support is in the
works.
mac_none: Policy module implementing all MAC policy entry
points with empty stubs. A good place to start if
you want all the prototypes types in for you, and
don't mind a bit of pruning. Can be loaded, but
has no access control impact. Useful also for
performance measurements.
mac_seeotheruids: Policy module implementing a security service
similar to security.bsd.seeotheruids, only a slightly
more detailed policy involving exceptions for members
of specific groups, etc. This policy is unlabeled,
relying on existing system security labeling
(process credentials).
mac_test: Policy module implementing basic sanity tests for
label handling. Attempts to ensure that labels are
not freed multiple times, etc, etc.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
