Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
/*-
|
2011-09-02 17:40:39 +00:00
|
|
|
* Copyright (c) 1999-2002, 2007-2011 Robert N. M. Watson
|
2005-02-13 13:59:34 +00:00
|
|
|
* Copyright (c) 2001-2005 McAfee, Inc.
|
2007-10-24 19:04:04 +00:00
|
|
|
* Copyright (c) 2006 SPARTA, Inc.
|
Introduce two related changes to the TrustedBSD MAC Framework:
(1) Abstract interpreter vnode labeling in execve(2) and mac_execve(2)
so that the general exec code isn't aware of the details of
allocating, copying, and freeing labels, rather, simply passes in
a void pointer to start and stop functions that will be used by
the framework. This change will be MFC'd.
(2) Introduce a new flags field to the MAC_POLICY_SET(9) interface
allowing policies to declare which types of objects require label
allocation, initialization, and destruction, and define a set of
flags covering various supported object types (MPC_OBJECT_PROC,
MPC_OBJECT_VNODE, MPC_OBJECT_INPCB, ...). This change reduces the
overhead of compiling the MAC Framework into the kernel if policies
aren't loaded, or if policies require labels on only a small number
or even no object types. Each time a policy is loaded or unloaded,
we recalculate a mask of labeled object types across all policies
present in the system. Eliminate MAC_ALWAYS_LABEL_MBUF option as it
is no longer required.
MFC after: 1 week ((1) only)
Reviewed by: csjp
Obtained from: TrustedBSD Project
Sponsored by: Apple, Inc.
2008-08-23 15:26:36 +00:00
|
|
|
* Copyright (c) 2008 Apple Inc.
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This software was developed by Robert Watson for the TrustedBSD Project.
|
|
|
|
*
|
2005-02-13 13:59:34 +00:00
|
|
|
* This software was developed for the FreeBSD Project in part by McAfee
|
|
|
|
* Research, the Security Research Division of McAfee, Inc. under
|
|
|
|
* DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"), as part of the DARPA
|
|
|
|
* CHATS research program.
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
*
|
2007-10-24 19:04:04 +00:00
|
|
|
* This software was enhanced by SPARTA ISSO under SPAWAR contract
|
|
|
|
* N66001-04-C-6019 ("SEFOS").
|
|
|
|
*
|
2009-03-08 10:58:37 +00:00
|
|
|
* This software was developed at the University of Cambridge Computer
|
|
|
|
* Laboratory with support from a grant from Google, Inc.
|
|
|
|
*
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``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 THE AUTHOR OR CONTRIBUTORS 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 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* $FreeBSD$
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Developed by the TrustedBSD Project.
|
2007-04-22 11:35:15 +00:00
|
|
|
*
|
|
|
|
* MAC Test policy - tests MAC Framework labeling by assigning object class
|
|
|
|
* magic numbers to each label and validates that each time an object label
|
|
|
|
* is passed into the policy, it has a consistent object type, catching
|
|
|
|
* incorrectly passed labels, labels passed after free, etc.
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/acl.h>
|
2004-07-10 21:47:53 +00:00
|
|
|
#include <sys/kdb.h>
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
#include <sys/kernel.h>
|
2006-11-11 16:26:58 +00:00
|
|
|
#include <sys/ksem.h>
|
2003-04-15 21:20:34 +00:00
|
|
|
#include <sys/malloc.h>
|
2007-02-23 14:39:04 +00:00
|
|
|
#include <sys/module.h>
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
#include <sys/mount.h>
|
2007-02-23 14:39:04 +00:00
|
|
|
#include <sys/msg.h>
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
#include <sys/proc.h>
|
|
|
|
#include <sys/vnode.h>
|
2007-02-23 14:39:04 +00:00
|
|
|
#include <sys/sem.h>
|
|
|
|
#include <sys/shm.h>
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
#include <sys/socket.h>
|
|
|
|
#include <sys/socketvar.h>
|
2005-09-19 18:52:51 +00:00
|
|
|
#include <sys/sx.h>
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
#include <sys/sysctl.h>
|
|
|
|
|
|
|
|
#include <fs/devfs/devfs.h>
|
|
|
|
|
|
|
|
#include <net/bpfdesc.h>
|
|
|
|
#include <net/if.h>
|
|
|
|
#include <net/if_types.h>
|
|
|
|
#include <net/if_var.h>
|
|
|
|
|
2006-12-22 23:34:47 +00:00
|
|
|
#include <security/mac/mac_policy.h>
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
|
|
|
SYSCTL_DECL(_security_mac);
|
|
|
|
|
2011-11-07 15:43:11 +00:00
|
|
|
static SYSCTL_NODE(_security_mac, OID_AUTO, test, CTLFLAG_RW, 0,
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
"TrustedBSD mac_test policy controls");
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
#define MAGIC_BPF 0xfe1ad1b6
|
|
|
|
#define MAGIC_DEVFS 0x9ee79c32
|
|
|
|
#define MAGIC_IFNET 0xc218b120
|
|
|
|
#define MAGIC_INPCB 0x4440f7bb
|
2008-10-26 22:46:37 +00:00
|
|
|
#define MAGIC_IP6Q 0x0870e1b7
|
2007-04-22 11:35:15 +00:00
|
|
|
#define MAGIC_IPQ 0x206188ef
|
|
|
|
#define MAGIC_MBUF 0xbbefa5bb
|
|
|
|
#define MAGIC_MOUNT 0xc7c46e47
|
|
|
|
#define MAGIC_SOCKET 0x9199c6cd
|
2007-10-28 18:33:31 +00:00
|
|
|
#define MAGIC_SYNCACHE 0x7fb838a8
|
2007-04-22 13:29:37 +00:00
|
|
|
#define MAGIC_SYSV_MSG 0x8bbba61e
|
|
|
|
#define MAGIC_SYSV_MSQ 0xea672391
|
|
|
|
#define MAGIC_SYSV_SEM 0x896e8a0b
|
|
|
|
#define MAGIC_SYSV_SHM 0x76119ab0
|
2007-04-22 11:35:15 +00:00
|
|
|
#define MAGIC_PIPE 0xdc6c9919
|
2007-04-22 13:29:37 +00:00
|
|
|
#define MAGIC_POSIX_SEM 0x78ae980c
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
#define MAGIC_POSIX_SHM 0x4e853fc9
|
2007-04-22 11:35:15 +00:00
|
|
|
#define MAGIC_PROC 0x3b4be98f
|
|
|
|
#define MAGIC_CRED 0x9a5a4987
|
|
|
|
#define MAGIC_VNODE 0x1a67a45c
|
|
|
|
#define MAGIC_FREE 0x849ba1fd
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
2007-02-06 14:19:25 +00:00
|
|
|
#define SLOT(x) mac_label_get((x), test_slot)
|
|
|
|
#define SLOT_SET(x, v) mac_label_set((x), test_slot, (v))
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int test_slot;
|
|
|
|
SYSCTL_INT(_security_mac_test, OID_AUTO, slot, CTLFLAG_RD,
|
|
|
|
&test_slot, 0, "Slot allocated by framework");
|
|
|
|
|
2011-11-07 15:43:11 +00:00
|
|
|
static SYSCTL_NODE(_security_mac_test, OID_AUTO, counter, CTLFLAG_RW, 0,
|
2007-04-22 11:35:15 +00:00
|
|
|
"TrustedBSD mac_test counters controls");
|
|
|
|
|
|
|
|
#define COUNTER_DECL(variable) \
|
|
|
|
static int counter_##variable; \
|
|
|
|
SYSCTL_INT(_security_mac_test_counter, OID_AUTO, variable, \
|
|
|
|
CTLFLAG_RD, &counter_##variable, 0, #variable)
|
|
|
|
|
|
|
|
#define COUNTER_INC(variable) atomic_add_int(&counter_##variable, 1)
|
|
|
|
|
2004-10-22 11:24:50 +00:00
|
|
|
#ifdef KDB
|
2007-12-25 17:52:02 +00:00
|
|
|
#define DEBUGGER(func, string) kdb_enter(KDB_WHY_MAC, (string))
|
2004-10-22 11:24:50 +00:00
|
|
|
#else
|
2007-04-22 11:35:15 +00:00
|
|
|
#define DEBUGGER(func, string) printf("mac_test: %s: %s\n", (func), (string))
|
2004-10-22 11:24:50 +00:00
|
|
|
#endif
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
#define LABEL_CHECK(label, magic) do { \
|
|
|
|
if (label != NULL) { \
|
|
|
|
KASSERT(SLOT(label) == magic || SLOT(label) == 0, \
|
|
|
|
("%s: bad %s label", __func__, #magic)); \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
2007-04-22 13:29:37 +00:00
|
|
|
#define LABEL_DESTROY(label, magic) do { \
|
2007-04-22 11:35:15 +00:00
|
|
|
if (SLOT(label) == magic || SLOT(label) == 0) { \
|
|
|
|
SLOT_SET(label, MAGIC_FREE); \
|
|
|
|
} else if (SLOT(label) == MAGIC_FREE) { \
|
|
|
|
DEBUGGER("%s: dup destroy", __func__); \
|
|
|
|
} else { \
|
|
|
|
DEBUGGER("%s: corrupted label", __func__); \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
2007-04-22 13:29:37 +00:00
|
|
|
#define LABEL_INIT(label, magic) do { \
|
|
|
|
SLOT_SET(label, magic); \
|
|
|
|
} while (0)
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
#define LABEL_NOTFREE(label) do { \
|
|
|
|
KASSERT(SLOT(label) != MAGIC_FREE, \
|
|
|
|
("%s: destroyed label", __func__)); \
|
|
|
|
} while (0)
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
/*
|
|
|
|
* Object-specific entry point implementations are sorted alphabetically by
|
|
|
|
* object type name and then by operation.
|
|
|
|
*/
|
|
|
|
COUNTER_DECL(bpfdesc_check_receive);
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
static int
|
2007-10-29 15:30:47 +00:00
|
|
|
test_bpfdesc_check_receive(struct bpf_d *d, struct label *dlabel,
|
2007-10-29 13:33:06 +00:00
|
|
|
struct ifnet *ifp, struct label *ifplabel)
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(dlabel, MAGIC_BPF);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(bpfdesc_check_receive);
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(bpfdesc_create);
|
2005-01-22 20:31:29 +00:00
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_bpfdesc_create(struct ucred *cred, struct bpf_d *d,
|
|
|
|
struct label *dlabel)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
2007-10-29 13:33:06 +00:00
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(dlabel, MAGIC_BPF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(bpfdesc_create);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(bpfdesc_create_mbuf);
|
2005-01-22 20:31:29 +00:00
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_bpfdesc_create_mbuf(struct bpf_d *d, struct label *dlabel,
|
|
|
|
struct mbuf *m, struct label *mlabel)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
2007-10-29 13:33:06 +00:00
|
|
|
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(dlabel, MAGIC_BPF);
|
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(bpfdesc_create_mbuf);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(bpfdesc_destroy_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_bpfdesc_destroy_label(struct label *label)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
2007-10-29 13:33:06 +00:00
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_BPF);
|
|
|
|
COUNTER_INC(bpfdesc_destroy_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(bpfdesc_init_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_bpfdesc_init_label(struct label *label)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
2007-10-29 13:33:06 +00:00
|
|
|
|
|
|
|
LABEL_INIT(label, MAGIC_BPF);
|
|
|
|
COUNTER_INC(bpfdesc_init_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(cred_check_relabel);
|
2003-03-26 15:12:03 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_cred_check_relabel(struct ucred *cred, struct label *newlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(newlabel, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_relabel);
|
2003-04-15 21:20:34 +00:00
|
|
|
|
2003-03-26 15:12:03 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2009-03-08 10:58:37 +00:00
|
|
|
COUNTER_DECL(cred_check_setaudit);
|
|
|
|
static int
|
|
|
|
test_cred_check_setaudit(struct ucred *cred, struct auditinfo *ai)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setaudit);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setaudit_addr);
|
|
|
|
static int
|
|
|
|
test_cred_check_setaudit_addr(struct ucred *cred,
|
|
|
|
struct auditinfo_addr *aia)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setaudit_addr);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setauid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setauid(struct ucred *cred, uid_t auid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setauid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setegid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setegid(struct ucred *cred, gid_t egid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setegid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(proc_check_euid);
|
|
|
|
static int
|
|
|
|
test_cred_check_seteuid(struct ucred *cred, uid_t euid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(proc_check_euid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setregid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setregid(struct ucred *cred, gid_t rgid, gid_t egid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setregid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setreuid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setreuid(struct ucred *cred, uid_t ruid, uid_t euid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setreuid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setgid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setgid(struct ucred *cred, gid_t gid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setgid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setgroups);
|
|
|
|
static int
|
|
|
|
test_cred_check_setgroups(struct ucred *cred, int ngroups,
|
|
|
|
gid_t *gidset)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setgroups);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setresgid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setresgid(struct ucred *cred, gid_t rgid, gid_t egid,
|
|
|
|
gid_t sgid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setresgid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setresuid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setresuid(struct ucred *cred, uid_t ruid, uid_t euid,
|
|
|
|
uid_t suid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setresuid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_check_setuid);
|
|
|
|
static int
|
|
|
|
test_cred_check_setuid(struct ucred *cred, uid_t uid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_setuid);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(cred_check_visible);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_cred_check_visible(struct ucred *u1, struct ucred *u2)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(u1->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(u2->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_check_visible);
|
2003-04-15 21:20:34 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(cred_copy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_cred_copy_label(struct label *src, struct label *dest)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(src, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(dest, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_copy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2008-10-28 11:33:06 +00:00
|
|
|
COUNTER_DECL(cred_create_init);
|
|
|
|
static void
|
|
|
|
test_cred_create_init(struct ucred *cred)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_create_init);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(cred_create_swapper);
|
|
|
|
static void
|
|
|
|
test_cred_create_swapper(struct ucred *cred)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_create_swapper);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(cred_destroy_label);
|
|
|
|
static void
|
|
|
|
test_cred_destroy_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(cred_externalize_label);
|
2002-10-05 21:23:47 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_cred_externalize_label(struct label *label, char *element_name,
|
|
|
|
struct sbuf *sb, int *claimed)
|
Begin another merge from the TrustedBSD MAC branch:
- Change mpo_init_foo(obj, label) and mpo_destroy_foo(obj, label) policy
entry points to mpo_init_foo_label(label) and
mpo_destroy_foo_label(label). This will permit the use of the same
entry points for holding temporary type-specific label during
internalization and externalization, as well as for caching purposes.
- Because of this, break out mpo_{init,destroy}_socket() and
mpo_{init,destroy}_mount() into seperate entry points for socket
main/peer labels and mount main/fs labels.
- Since the prototype for label initialization is the same across almost
all entry points, implement these entry points using common
implementations for Biba, MLS, and Test, reducing the number of
almost identical looking functions.
This simplifies policy implementation, as well as preparing us for the
merge of the new flexible userland API for managing labels on objects.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 15:10:00 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_externalize_label);
|
2003-04-15 21:20:34 +00:00
|
|
|
|
2002-10-05 21:23:47 +00:00
|
|
|
return (0);
|
Begin another merge from the TrustedBSD MAC branch:
- Change mpo_init_foo(obj, label) and mpo_destroy_foo(obj, label) policy
entry points to mpo_init_foo_label(label) and
mpo_destroy_foo_label(label). This will permit the use of the same
entry points for holding temporary type-specific label during
internalization and externalization, as well as for caching purposes.
- Because of this, break out mpo_{init,destroy}_socket() and
mpo_{init,destroy}_mount() into seperate entry points for socket
main/peer labels and mount main/fs labels.
- Since the prototype for label initialization is the same across almost
all entry points, implement these entry points using common
implementations for Biba, MLS, and Test, reducing the number of
almost identical looking functions.
This simplifies policy implementation, as well as preparing us for the
merge of the new flexible userland API for managing labels on objects.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 15:10:00 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(cred_init_label);
|
2005-05-04 10:39:15 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_cred_init_label(struct label *label)
|
2005-05-04 10:39:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_init_label);
|
2005-05-04 10:39:15 +00:00
|
|
|
}
|
|
|
|
|
2007-10-30 00:01:28 +00:00
|
|
|
COUNTER_DECL(cred_internalize_label);
|
|
|
|
static int
|
|
|
|
test_cred_internalize_label(struct label *label, char *element_name,
|
|
|
|
char *element_data, int *claimed)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_internalize_label);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(cred_relabel);
|
2003-03-25 01:20:56 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_cred_relabel(struct ucred *cred, struct label *newlabel)
|
2007-10-28 18:33:31 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(newlabel, MAGIC_CRED);
|
|
|
|
COUNTER_INC(cred_relabel);
|
2007-10-28 18:33:31 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(devfs_create_device);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_devfs_create_device(struct ucred *cred, struct mount *mp,
|
|
|
|
struct cdev *dev, struct devfs_dirent *de, struct label *delabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
if (cred != NULL)
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(delabel, MAGIC_DEVFS);
|
|
|
|
COUNTER_INC(devfs_create_device);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(devfs_create_directory);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_devfs_create_directory(struct mount *mp, char *dirname,
|
|
|
|
int dirnamelen, struct devfs_dirent *de, struct label *delabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(delabel, MAGIC_DEVFS);
|
|
|
|
COUNTER_INC(devfs_create_directory);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(devfs_create_symlink);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_devfs_create_symlink(struct ucred *cred, struct mount *mp,
|
|
|
|
struct devfs_dirent *dd, struct label *ddlabel, struct devfs_dirent *de,
|
|
|
|
struct label *delabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(ddlabel, MAGIC_DEVFS);
|
|
|
|
LABEL_CHECK(delabel, MAGIC_DEVFS);
|
|
|
|
COUNTER_INC(devfs_create_symlink);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(devfs_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-25 11:31:11 +00:00
|
|
|
test_devfs_destroy_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 13:29:37 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_DEVFS);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(devfs_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(devfs_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_devfs_init_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_DEVFS);
|
|
|
|
COUNTER_INC(devfs_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(devfs_update);
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_devfs_update(struct mount *mp, struct devfs_dirent *devfs_dirent,
|
|
|
|
struct label *direntlabel, struct vnode *vp, struct label *vplabel)
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(direntlabel, MAGIC_DEVFS);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(devfs_update);
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(devfs_vnode_associate);
|
2007-10-28 18:33:31 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_devfs_vnode_associate(struct mount *mp, struct label *mplabel,
|
|
|
|
struct devfs_dirent *de, struct label *delabel, struct vnode *vp,
|
|
|
|
struct label *vplabel)
|
2007-10-28 18:33:31 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(mplabel, MAGIC_MOUNT);
|
|
|
|
LABEL_CHECK(delabel, MAGIC_DEVFS);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(devfs_vnode_associate);
|
2007-10-28 18:33:31 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_check_relabel);
|
|
|
|
static int
|
|
|
|
test_ifnet_check_relabel(struct ucred *cred, struct ifnet *ifp,
|
|
|
|
struct label *ifplabel, struct label *newlabel)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
|
|
|
LABEL_CHECK(newlabel, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_check_relabel);
|
2005-01-22 20:31:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_check_transmit);
|
|
|
|
static int
|
|
|
|
test_ifnet_check_transmit(struct ifnet *ifp, struct label *ifplabel,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct mbuf *m, struct label *mlabel)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(ifnet_check_transmit);
|
2005-01-22 20:31:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_copy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ifnet_copy_label(struct label *src, struct label *dest)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(src, MAGIC_IFNET);
|
|
|
|
LABEL_CHECK(dest, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_copy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ifnet_create(struct ifnet *ifp, struct label *ifplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_create_mbuf);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ifnet_create_mbuf(struct ifnet *ifp, struct label *ifplabel,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct mbuf *m, struct label *mlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(ifnet_create_mbuf);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_destroy_label);
|
Begin another merge from the TrustedBSD MAC branch:
- Change mpo_init_foo(obj, label) and mpo_destroy_foo(obj, label) policy
entry points to mpo_init_foo_label(label) and
mpo_destroy_foo_label(label). This will permit the use of the same
entry points for holding temporary type-specific label during
internalization and externalization, as well as for caching purposes.
- Because of this, break out mpo_{init,destroy}_socket() and
mpo_{init,destroy}_mount() into seperate entry points for socket
main/peer labels and mount main/fs labels.
- Since the prototype for label initialization is the same across almost
all entry points, implement these entry points using common
implementations for Biba, MLS, and Test, reducing the number of
almost identical looking functions.
This simplifies policy implementation, as well as preparing us for the
merge of the new flexible userland API for managing labels on objects.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 15:10:00 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ifnet_destroy_label(struct label *label)
|
Begin another merge from the TrustedBSD MAC branch:
- Change mpo_init_foo(obj, label) and mpo_destroy_foo(obj, label) policy
entry points to mpo_init_foo_label(label) and
mpo_destroy_foo_label(label). This will permit the use of the same
entry points for holding temporary type-specific label during
internalization and externalization, as well as for caching purposes.
- Because of this, break out mpo_{init,destroy}_socket() and
mpo_{init,destroy}_mount() into seperate entry points for socket
main/peer labels and mount main/fs labels.
- Since the prototype for label initialization is the same across almost
all entry points, implement these entry points using common
implementations for Biba, MLS, and Test, reducing the number of
almost identical looking functions.
This simplifies policy implementation, as well as preparing us for the
merge of the new flexible userland API for managing labels on objects.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 15:10:00 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
Begin another merge from the TrustedBSD MAC branch:
- Change mpo_init_foo(obj, label) and mpo_destroy_foo(obj, label) policy
entry points to mpo_init_foo_label(label) and
mpo_destroy_foo_label(label). This will permit the use of the same
entry points for holding temporary type-specific label during
internalization and externalization, as well as for caching purposes.
- Because of this, break out mpo_{init,destroy}_socket() and
mpo_{init,destroy}_mount() into seperate entry points for socket
main/peer labels and mount main/fs labels.
- Since the prototype for label initialization is the same across almost
all entry points, implement these entry points using common
implementations for Biba, MLS, and Test, reducing the number of
almost identical looking functions.
This simplifies policy implementation, as well as preparing us for the
merge of the new flexible userland API for managing labels on objects.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 15:10:00 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_externalize_label);
|
|
|
|
static int
|
|
|
|
test_ifnet_externalize_label(struct label *label, char *element_name,
|
|
|
|
struct sbuf *sb, int *claimed)
|
Begin another merge from the TrustedBSD MAC branch:
- Change mpo_init_foo(obj, label) and mpo_destroy_foo(obj, label) policy
entry points to mpo_init_foo_label(label) and
mpo_destroy_foo_label(label). This will permit the use of the same
entry points for holding temporary type-specific label during
internalization and externalization, as well as for caching purposes.
- Because of this, break out mpo_{init,destroy}_socket() and
mpo_{init,destroy}_mount() into seperate entry points for socket
main/peer labels and mount main/fs labels.
- Since the prototype for label initialization is the same across almost
all entry points, implement these entry points using common
implementations for Biba, MLS, and Test, reducing the number of
almost identical looking functions.
This simplifies policy implementation, as well as preparing us for the
merge of the new flexible userland API for managing labels on objects.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 15:10:00 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(label, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_externalize_label);
|
|
|
|
|
|
|
|
return (0);
|
Begin another merge from the TrustedBSD MAC branch:
- Change mpo_init_foo(obj, label) and mpo_destroy_foo(obj, label) policy
entry points to mpo_init_foo_label(label) and
mpo_destroy_foo_label(label). This will permit the use of the same
entry points for holding temporary type-specific label during
internalization and externalization, as well as for caching purposes.
- Because of this, break out mpo_{init,destroy}_socket() and
mpo_{init,destroy}_mount() into seperate entry points for socket
main/peer labels and mount main/fs labels.
- Since the prototype for label initialization is the same across almost
all entry points, implement these entry points using common
implementations for Biba, MLS, and Test, reducing the number of
almost identical looking functions.
This simplifies policy implementation, as well as preparing us for the
merge of the new flexible userland API for managing labels on objects.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 15:10:00 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ifnet_init_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-30 00:01:28 +00:00
|
|
|
COUNTER_DECL(ifnet_internalize_label);
|
|
|
|
static int
|
|
|
|
test_ifnet_internalize_label(struct label *label, char *element_name,
|
|
|
|
char *element_data, int *claimed)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(label, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_internalize_label);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ifnet_relabel);
|
2005-05-04 10:39:15 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ifnet_relabel(struct ucred *cred, struct ifnet *ifp,
|
|
|
|
struct label *ifplabel, struct label *newlabel)
|
2005-05-04 10:39:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
|
|
|
LABEL_CHECK(newlabel, MAGIC_IFNET);
|
|
|
|
COUNTER_INC(ifnet_relabel);
|
2005-05-04 10:39:15 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(inpcb_check_deliver);
|
|
|
|
static int
|
|
|
|
test_inpcb_check_deliver(struct inpcb *inp, struct label *inplabel,
|
|
|
|
struct mbuf *m, struct label *mlabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(inplabel, MAGIC_INPCB);
|
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(inpcb_check_deliver);
|
|
|
|
|
|
|
|
return (0);
|
2003-03-25 01:20:56 +00:00
|
|
|
}
|
|
|
|
|
2008-10-17 15:11:12 +00:00
|
|
|
COUNTER_DECL(inpcb_check_visible);
|
|
|
|
static int
|
|
|
|
test_inpcb_check_visible(struct ucred *cred, struct inpcb *inp,
|
|
|
|
struct label *inplabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(inplabel, MAGIC_INPCB);
|
|
|
|
COUNTER_INC(inpcb_check_visible);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(inpcb_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_inpcb_create(struct socket *so, struct label *solabel,
|
|
|
|
struct inpcb *inp, struct label *inplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(inplabel, MAGIC_INPCB);
|
|
|
|
COUNTER_INC(inpcb_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(inpcb_create_mbuf);
|
2003-12-06 21:48:03 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_inpcb_create_mbuf(struct inpcb *inp, struct label *inplabel,
|
|
|
|
struct mbuf *m, struct label *mlabel)
|
2003-12-06 21:48:03 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(inplabel, MAGIC_INPCB);
|
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(inpcb_create_mbuf);
|
2003-12-06 21:48:03 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(inpcb_destroy_label);
|
2004-06-24 03:34:46 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_inpcb_destroy_label(struct label *label)
|
2004-06-24 03:34:46 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_INPCB);
|
|
|
|
COUNTER_INC(inpcb_destroy_label);
|
2004-06-24 03:34:46 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(inpcb_init_label);
|
|
|
|
static int
|
|
|
|
test_inpcb_init_label(struct label *label, int flag)
|
2003-11-16 18:28:58 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
if (flag & M_WAITOK)
|
|
|
|
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
|
|
|
|
"test_inpcb_init_label() at %s:%d", __FILE__,
|
|
|
|
__LINE__);
|
|
|
|
|
|
|
|
LABEL_INIT(label, MAGIC_INPCB);
|
|
|
|
COUNTER_INC(inpcb_init_label);
|
|
|
|
return (0);
|
2003-11-16 18:28:58 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(inpcb_sosetlabel);
|
2003-11-16 18:28:58 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_inpcb_sosetlabel(struct socket *so, struct label *solabel,
|
|
|
|
struct inpcb *inp, struct label *inplabel)
|
2003-11-16 18:28:58 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK_ASSERT(so);
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
|
|
|
LABEL_CHECK(inplabel, MAGIC_INPCB);
|
|
|
|
COUNTER_INC(inpcb_sosetlabel);
|
2003-11-16 18:28:58 +00:00
|
|
|
}
|
|
|
|
|
2008-10-26 22:46:37 +00:00
|
|
|
COUNTER_DECL(ip6q_create);
|
|
|
|
static void
|
|
|
|
test_ip6q_create(struct mbuf *fragment, struct label *fragmentlabel,
|
|
|
|
struct ip6q *q6, struct label *q6label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(fragmentlabel, MAGIC_MBUF);
|
|
|
|
LABEL_CHECK(q6label, MAGIC_IP6Q);
|
|
|
|
COUNTER_INC(ip6q_create);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(ip6q_destroy_label);
|
|
|
|
static void
|
|
|
|
test_ip6q_destroy_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_IP6Q);
|
|
|
|
COUNTER_INC(ip6q_destroy_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(ip6q_init_label);
|
|
|
|
static int
|
|
|
|
test_ip6q_init_label(struct label *label, int flag)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (flag & M_WAITOK)
|
|
|
|
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
|
|
|
|
"test_ip6q_init_label() at %s:%d", __FILE__,
|
|
|
|
__LINE__);
|
|
|
|
|
|
|
|
LABEL_INIT(label, MAGIC_IP6Q);
|
|
|
|
COUNTER_INC(ip6q_init_label);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(ip6q_match);
|
|
|
|
static int
|
|
|
|
test_ip6q_match(struct mbuf *fragment, struct label *fragmentlabel,
|
|
|
|
struct ip6q *q6, struct label *q6label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(fragmentlabel, MAGIC_MBUF);
|
|
|
|
LABEL_CHECK(q6label, MAGIC_IP6Q);
|
|
|
|
COUNTER_INC(ip6q_match);
|
|
|
|
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(ip6q_reassemble);
|
|
|
|
static void
|
|
|
|
test_ip6q_reassemble(struct ip6q *q6, struct label *q6label, struct mbuf *m,
|
|
|
|
struct label *mlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(q6label, MAGIC_IP6Q);
|
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(ip6q_reassemble);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(ip6q_update);
|
|
|
|
static void
|
|
|
|
test_ip6q_update(struct mbuf *m, struct label *mlabel, struct ip6q *q6,
|
|
|
|
struct label *q6label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
LABEL_CHECK(q6label, MAGIC_IP6Q);
|
|
|
|
COUNTER_INC(ip6q_update);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ipq_create);
|
Implement sockets support for __mac_get_fd() and __mac_set_fd()
system calls, and prefer these calls over getsockopt()/setsockopt()
for ABI reasons. When addressing UNIX domain sockets, these calls
retrieve and modify the socket label, not the label of the
rendezvous vnode.
- Create mac_copy_socket_label() entry point based on
mac_copy_pipe_label() entry point, intended to copy the socket
label into temporary storage that doesn't require a socket lock
to be held (currently Giant).
- Implement mac_copy_socket_label() for various policies.
- Expose socket label allocation, free, internalize, externalize
entry points as non-static from mac_net.c.
- Use mac_socket_label_set() in __mac_set_fd().
MAC-aware applications may now use mac_get_fd(), mac_set_fd(), and
mac_get_peer() to retrieve and set various socket labels without
directly invoking the getsockopt() interface.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2003-11-16 23:31:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ipq_create(struct mbuf *fragment, struct label *fragmentlabel,
|
2008-06-13 22:14:15 +00:00
|
|
|
struct ipq *q, struct label *qlabel)
|
Implement sockets support for __mac_get_fd() and __mac_set_fd()
system calls, and prefer these calls over getsockopt()/setsockopt()
for ABI reasons. When addressing UNIX domain sockets, these calls
retrieve and modify the socket label, not the label of the
rendezvous vnode.
- Create mac_copy_socket_label() entry point based on
mac_copy_pipe_label() entry point, intended to copy the socket
label into temporary storage that doesn't require a socket lock
to be held (currently Giant).
- Implement mac_copy_socket_label() for various policies.
- Expose socket label allocation, free, internalize, externalize
entry points as non-static from mac_net.c.
- Use mac_socket_label_set() in __mac_set_fd().
MAC-aware applications may now use mac_get_fd(), mac_set_fd(), and
mac_get_peer() to retrieve and set various socket labels without
directly invoking the getsockopt() interface.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2003-11-16 23:31:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(fragmentlabel, MAGIC_MBUF);
|
2008-06-13 22:14:15 +00:00
|
|
|
LABEL_CHECK(qlabel, MAGIC_IPQ);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(ipq_create);
|
Implement sockets support for __mac_get_fd() and __mac_set_fd()
system calls, and prefer these calls over getsockopt()/setsockopt()
for ABI reasons. When addressing UNIX domain sockets, these calls
retrieve and modify the socket label, not the label of the
rendezvous vnode.
- Create mac_copy_socket_label() entry point based on
mac_copy_pipe_label() entry point, intended to copy the socket
label into temporary storage that doesn't require a socket lock
to be held (currently Giant).
- Implement mac_copy_socket_label() for various policies.
- Expose socket label allocation, free, internalize, externalize
entry points as non-static from mac_net.c.
- Use mac_socket_label_set() in __mac_set_fd().
MAC-aware applications may now use mac_get_fd(), mac_set_fd(), and
mac_get_peer() to retrieve and set various socket labels without
directly invoking the getsockopt() interface.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2003-11-16 23:31:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ipq_destroy_label);
|
2003-11-16 18:28:58 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ipq_destroy_label(struct label *label)
|
2003-11-16 18:28:58 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_IPQ);
|
|
|
|
COUNTER_INC(ipq_destroy_label);
|
2003-11-16 18:28:58 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ipq_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ipq_init_label(struct label *label, int flag)
|
2002-10-22 14:31:34 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
if (flag & M_WAITOK)
|
|
|
|
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
|
|
|
|
"test_ipq_init_label() at %s:%d", __FILE__,
|
|
|
|
__LINE__);
|
2007-10-28 14:28:33 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_IPQ);
|
|
|
|
COUNTER_INC(ipq_init_label);
|
2007-10-28 14:28:33 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ipq_match);
|
2007-10-28 14:28:33 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_ipq_match(struct mbuf *fragment, struct label *fragmentlabel,
|
2008-06-13 22:14:15 +00:00
|
|
|
struct ipq *q, struct label *qlabel)
|
2007-10-28 14:28:33 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(fragmentlabel, MAGIC_MBUF);
|
2008-06-13 22:14:15 +00:00
|
|
|
LABEL_CHECK(qlabel, MAGIC_IPQ);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(ipq_match);
|
2007-10-28 14:28:33 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (1);
|
2007-10-28 14:28:33 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ipq_reassemble);
|
|
|
|
static void
|
2008-06-13 22:14:15 +00:00
|
|
|
test_ipq_reassemble(struct ipq *q, struct label *qlabel, struct mbuf *m,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *mlabel)
|
2007-10-28 14:28:33 +00:00
|
|
|
{
|
|
|
|
|
2008-06-13 22:14:15 +00:00
|
|
|
LABEL_CHECK(qlabel, MAGIC_IPQ);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(ipq_reassemble);
|
2007-10-28 14:28:33 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(ipq_update);
|
|
|
|
static void
|
2008-06-13 22:14:15 +00:00
|
|
|
test_ipq_update(struct mbuf *m, struct label *mlabel, struct ipq *q,
|
|
|
|
struct label *qlabel)
|
2007-10-28 14:28:33 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2008-06-13 22:14:15 +00:00
|
|
|
LABEL_CHECK(qlabel, MAGIC_IPQ);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(ipq_update);
|
2007-10-28 14:28:33 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(kenv_check_dump);
|
2007-10-28 14:28:33 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_kenv_check_dump(struct ucred *cred)
|
2007-10-28 14:28:33 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(kenv_check_dump);
|
2007-10-28 14:28:33 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(kenv_check_get);
|
2007-10-28 14:28:33 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_kenv_check_get(struct ucred *cred, char *name)
|
2007-10-28 14:28:33 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(kenv_check_get);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-10-22 14:31:34 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(kenv_check_set);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_kenv_check_set(struct ucred *cred, char *name, char *value)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(kenv_check_set);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(kenv_check_unset);
|
|
|
|
static int
|
|
|
|
test_kenv_check_unset(struct ucred *cred, char *name)
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(kenv_check_unset);
|
|
|
|
|
|
|
|
return (0);
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(kld_check_load);
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_kld_check_load(struct ucred *cred, struct vnode *vp,
|
|
|
|
struct label *label)
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(label, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(kld_check_load);
|
2007-04-22 13:29:37 +00:00
|
|
|
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(kld_check_stat);
|
|
|
|
static int
|
|
|
|
test_kld_check_stat(struct ucred *cred)
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(kld_check_stat);
|
|
|
|
|
|
|
|
return (0);
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(mbuf_copy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_mbuf_copy_label(struct label *src, struct label *dest)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(src, MAGIC_MBUF);
|
|
|
|
LABEL_CHECK(dest, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(mbuf_copy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(mbuf_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_mbuf_destroy_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
/*
|
|
|
|
* If we're loaded dynamically, there may be mbufs in flight that
|
|
|
|
* didn't have label storage allocated for them. Handle this
|
|
|
|
* gracefully.
|
|
|
|
*/
|
|
|
|
if (label == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(mbuf_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(mbuf_init_label);
|
|
|
|
static int
|
|
|
|
test_mbuf_init_label(struct label *label, int flag)
|
2002-10-05 18:56:25 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
if (flag & M_WAITOK)
|
|
|
|
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
|
|
|
|
"test_mbuf_init_label() at %s:%d", __FILE__,
|
|
|
|
__LINE__);
|
|
|
|
|
|
|
|
LABEL_INIT(label, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(mbuf_init_label);
|
|
|
|
return (0);
|
2002-10-05 18:56:25 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(mount_check_stat);
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_mount_check_stat(struct ucred *cred, struct mount *mp,
|
|
|
|
struct label *mplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(mplabel, MAGIC_MOUNT);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(mount_check_stat);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Slightly change the semantics of vnode labels for MAC: rather than
"refreshing" the label on the vnode before use, just get the label
right from inception. For single-label file systems, set the label
in the generic VFS getnewvnode() code; for multi-label file systems,
leave the labeling up to the file system. With UFS1/2, this means
reading the extended attribute during vfs_vget() as the inode is
pulled off disk, rather than hitting the extended attributes
frequently during operations later, improving performance. This
also corrects sematics for shared vnode locks, which were not
previously present in the system. This chances the cache
coherrency properties WRT out-of-band access to label data, but in
an acceptable form. With UFS1, there is a small race condition
during automatic extended attribute start -- this is not present
with UFS2, and occurs because EAs aren't available at vnode
inception. We'll introduce a work around for this shortly.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
2002-10-26 14:38:24 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(mount_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-25 11:31:11 +00:00
|
|
|
test_mount_create(struct ucred *cred, struct mount *mp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *mplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(mplabel, MAGIC_MOUNT);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(mount_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(mount_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_mount_destroy_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_MOUNT);
|
|
|
|
COUNTER_INC(mount_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(mount_init_label);
|
|
|
|
static void
|
|
|
|
test_mount_init_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_MOUNT);
|
|
|
|
COUNTER_INC(mount_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(netinet_arp_send);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_netinet_arp_send(struct ifnet *ifp, struct label *ifplabel,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct mbuf *m, struct label *mlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(netinet_arp_send);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(netinet_fragment);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_netinet_fragment(struct mbuf *m, struct label *mlabel,
|
|
|
|
struct mbuf *frag, struct label *fraglabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
LABEL_CHECK(fraglabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(netinet_fragment);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(netinet_icmp_reply);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_netinet_icmp_reply(struct mbuf *mrecv, struct label *mrecvlabel,
|
|
|
|
struct mbuf *msend, struct label *msendlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(mrecvlabel, MAGIC_MBUF);
|
|
|
|
LABEL_CHECK(msendlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(netinet_icmp_reply);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(netinet_icmp_replyinplace);
|
2005-05-04 10:39:15 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_netinet_icmp_replyinplace(struct mbuf *m, struct label *mlabel)
|
2005-05-04 10:39:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(netinet_icmp_replyinplace);
|
2005-05-04 10:39:15 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(netinet_igmp_send);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_netinet_igmp_send(struct ifnet *ifp, struct label *ifplabel,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct mbuf *m, struct label *mlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(netinet_igmp_send);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(netinet_tcp_reply);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_netinet_tcp_reply(struct mbuf *m, struct label *mlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(netinet_tcp_reply);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(netinet6_nd6_send);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_netinet6_nd6_send(struct ifnet *ifp, struct label *ifplabel,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct mbuf *m, struct label *mlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(ifplabel, MAGIC_IFNET);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(netinet6_nd6_send);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_check_ioctl);
|
|
|
|
static int
|
|
|
|
test_pipe_check_ioctl(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel, unsigned long cmd, void /* caddr_t */ *data)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(pipe_check_ioctl);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_check_poll);
|
|
|
|
static int
|
|
|
|
test_pipe_check_poll(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(pipe_check_poll);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_check_read);
|
|
|
|
static int
|
|
|
|
test_pipe_check_read(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel)
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(pipe_check_read);
|
2007-10-28 18:33:31 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2007-10-28 18:33:31 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_check_relabel);
|
|
|
|
static int
|
|
|
|
test_pipe_check_relabel(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel, struct label *newlabel)
|
2007-10-28 18:33:31 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(newlabel, MAGIC_PIPE);
|
|
|
|
COUNTER_INC(pipe_check_relabel);
|
2005-01-22 20:31:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_check_stat);
|
|
|
|
static int
|
|
|
|
test_pipe_check_stat(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(pipe_check_stat);
|
2005-01-22 20:31:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_check_write);
|
|
|
|
static int
|
|
|
|
test_pipe_check_write(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(pipe_check_write);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_copy_label);
|
2003-12-17 14:55:11 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_pipe_copy_label(struct label *src, struct label *dest)
|
2003-12-17 14:55:11 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(src, MAGIC_PIPE);
|
|
|
|
LABEL_CHECK(dest, MAGIC_PIPE);
|
|
|
|
COUNTER_INC(pipe_copy_label);
|
2003-12-17 14:55:11 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_pipe_create(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(pipe_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_pipe_destroy_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_PIPE);
|
|
|
|
COUNTER_INC(pipe_destroy_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_externalize_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_pipe_externalize_label(struct label *label, char *element_name,
|
|
|
|
struct sbuf *sb, int *claimed)
|
2007-10-28 15:55:23 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(label, MAGIC_PIPE);
|
|
|
|
COUNTER_INC(pipe_externalize_label);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2003-08-21 17:28:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_init_label);
|
2007-10-28 17:12:48 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_pipe_init_label(struct label *label)
|
2007-10-28 17:12:48 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_PIPE);
|
|
|
|
COUNTER_INC(pipe_init_label);
|
2007-10-28 17:12:48 +00:00
|
|
|
}
|
|
|
|
|
2007-10-30 00:01:28 +00:00
|
|
|
COUNTER_DECL(pipe_internalize_label);
|
|
|
|
static int
|
|
|
|
test_pipe_internalize_label(struct label *label, char *element_name,
|
|
|
|
char *element_data, int *claimed)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(label, MAGIC_PIPE);
|
|
|
|
COUNTER_INC(pipe_internalize_label);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(pipe_relabel);
|
2007-10-28 15:55:23 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_pipe_relabel(struct ucred *cred, struct pipepair *pp,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct label *pplabel, struct label *newlabel)
|
2007-10-28 15:55:23 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(pplabel, MAGIC_PIPE);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(newlabel, MAGIC_PIPE);
|
|
|
|
COUNTER_INC(pipe_relabel);
|
2007-10-28 15:55:23 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_check_getvalue);
|
|
|
|
static int
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
test_posixsem_check_getvalue(struct ucred *active_cred, struct ucred *file_cred,
|
|
|
|
struct ksem *ks, struct label *kslabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_check_getvalue);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_check_open);
|
|
|
|
static int
|
|
|
|
test_posixsem_check_open(struct ucred *cred, struct ksem *ks,
|
|
|
|
struct label *kslabel)
|
Introduce a MAC label reference in 'struct inpcb', which caches
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
2003-11-18 00:39:07 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_check_open);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_check_post);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
test_posixsem_check_post(struct ucred *active_cred, struct ucred *file_cred,
|
|
|
|
struct ksem *ks, struct label *kslabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_check_post);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2011-08-16 20:07:47 +00:00
|
|
|
COUNTER_DECL(posixsem_check_setmode);
|
|
|
|
static int
|
|
|
|
test_posixsem_check_setmode(struct ucred *cred, struct ksem *ks,
|
|
|
|
struct label *kslabel, mode_t mode)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixsem_check_setmode);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(posixsem_check_setowner);
|
|
|
|
static int
|
|
|
|
test_posixsem_check_setowner(struct ucred *cred, struct ksem *ks,
|
|
|
|
struct label *kslabel, uid_t uid, gid_t gid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixsem_check_setowner);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
COUNTER_DECL(posixsem_check_stat);
|
|
|
|
static int
|
|
|
|
test_posixsem_check_stat(struct ucred *active_cred,
|
|
|
|
struct ucred *file_cred, struct ksem *ks, struct label *kslabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_check_stat);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_check_unlink);
|
|
|
|
static int
|
|
|
|
test_posixsem_check_unlink(struct ucred *cred, struct ksem *ks,
|
|
|
|
struct label *kslabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_check_unlink);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_check_wait);
|
|
|
|
static int
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
test_posixsem_check_wait(struct ucred *active_cred, struct ucred *file_cred,
|
|
|
|
struct ksem *ks, struct label *kslabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_check_wait);
|
2005-01-22 20:31:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_create);
|
2005-01-22 20:31:29 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_posixsem_create(struct ucred *cred, struct ksem *ks,
|
|
|
|
struct label *kslabel)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(kslabel, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_create);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_destroy_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_posixsem_destroy_label(struct label *label)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_destroy_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(posixsem_init_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
static void
|
2007-10-29 13:33:06 +00:00
|
|
|
test_posixsem_init_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_POSIX_SEM);
|
|
|
|
COUNTER_INC(posixsem_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2011-09-02 17:40:39 +00:00
|
|
|
COUNTER_DECL(posixshm_check_create);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_create(struct ucred *cred, const char *path)
|
|
|
|
{
|
|
|
|
|
|
|
|
COUNTER_INC(posixshm_check_create);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
COUNTER_DECL(posixshm_check_mmap);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_mmap(struct ucred *cred, struct shmfd *shmfd,
|
|
|
|
struct label *shmfdlabel, int prot, int flags)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
2008-06-26 13:49:32 +00:00
|
|
|
COUNTER_INC(posixshm_check_mmap);
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(posixshm_check_open);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_open(struct ucred *cred, struct shmfd *shmfd,
|
2011-09-02 17:40:39 +00:00
|
|
|
struct label *shmfdlabel, accmode_t accmode)
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
2008-06-26 13:49:32 +00:00
|
|
|
COUNTER_INC(posixshm_check_open);
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2013-08-21 17:45:00 +00:00
|
|
|
COUNTER_DECL(posixshm_check_read);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_read(struct ucred *active_cred,
|
|
|
|
struct ucred *file_cred, struct shmfd *shm, struct label *shmlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
if (file_cred != NULL)
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmlabel, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixshm_check_read);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2011-08-16 20:07:47 +00:00
|
|
|
COUNTER_DECL(posixshm_check_setmode);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_setmode(struct ucred *cred, struct shmfd *shmfd,
|
|
|
|
struct label *shmfdlabel, mode_t mode)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixshm_check_setmode);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(posixshm_check_setowner);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_setowner(struct ucred *cred, struct shmfd *shmfd,
|
|
|
|
struct label *shmfdlabel, uid_t uid, gid_t gid)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixshm_check_setowner);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
COUNTER_DECL(posixshm_check_stat);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_stat(struct ucred *active_cred,
|
|
|
|
struct ucred *file_cred, struct shmfd *shmfd, struct label *shmfdlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
2008-06-26 13:49:32 +00:00
|
|
|
COUNTER_INC(posixshm_check_stat);
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(posixshm_check_truncate);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_truncate(struct ucred *active_cred,
|
|
|
|
struct ucred *file_cred, struct shmfd *shmfd, struct label *shmfdlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
2008-06-26 13:49:32 +00:00
|
|
|
COUNTER_INC(posixshm_check_truncate);
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(posixshm_check_unlink);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_unlink(struct ucred *cred, struct shmfd *shmfd,
|
|
|
|
struct label *shmfdlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
2008-06-26 13:49:32 +00:00
|
|
|
COUNTER_INC(posixshm_check_unlink);
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2013-08-21 17:45:00 +00:00
|
|
|
COUNTER_DECL(posixshm_check_write);
|
|
|
|
static int
|
|
|
|
test_posixshm_check_write(struct ucred *active_cred,
|
|
|
|
struct ucred *file_cred, struct shmfd *shm, struct label *shmlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
if (file_cred != NULL)
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmlabel, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixshm_check_write);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
COUNTER_DECL(posixshm_create);
|
|
|
|
static void
|
|
|
|
test_posixshm_create(struct ucred *cred, struct shmfd *shmfd,
|
|
|
|
struct label *shmfdlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(shmfdlabel, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixshm_create);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(posixshm_destroy_label);
|
|
|
|
static void
|
|
|
|
test_posixshm_destroy_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixshm_destroy_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(posixshm_init_label);
|
|
|
|
static void
|
|
|
|
test_posixshm_init_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_INIT(label, MAGIC_POSIX_SHM);
|
|
|
|
COUNTER_INC(posixshm_init_label);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(proc_check_debug);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_proc_check_debug(struct ucred *cred, struct proc *p)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(p->p_ucred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(proc_check_debug);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(proc_check_sched);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_proc_check_sched(struct ucred *cred, struct proc *p)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(p->p_ucred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(proc_check_sched);
|
2007-04-22 13:29:37 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(proc_check_signal);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_proc_check_signal(struct ucred *cred, struct proc *p, int signum)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(p->p_ucred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(proc_check_signal);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(proc_check_wait);
|
2005-01-22 20:31:29 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_proc_check_wait(struct ucred *cred, struct proc *p)
|
2005-01-22 20:31:29 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(p->p_ucred->cr_label, MAGIC_CRED);
|
|
|
|
COUNTER_INC(proc_check_wait);
|
2005-01-22 20:31:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(proc_destroy_label);
|
|
|
|
static void
|
|
|
|
test_proc_destroy_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_PROC);
|
|
|
|
COUNTER_INC(proc_destroy_label);
|
2005-01-22 20:31:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(proc_init_label);
|
|
|
|
static void
|
|
|
|
test_proc_init_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_INIT(label, MAGIC_PROC);
|
|
|
|
COUNTER_INC(proc_init_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(socket_check_accept);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_accept(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_accept);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2003-03-25 01:20:56 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_bind);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_bind(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel, struct sockaddr *sa)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_bind);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2003-03-25 01:20:56 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_connect);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_connect(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel, struct sockaddr *sa)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_connect);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2003-03-25 01:20:56 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_deliver);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_deliver(struct socket *so, struct label *solabel,
|
|
|
|
struct mbuf *m, struct label *mlabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(socket_check_deliver);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2003-03-25 01:20:56 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_listen);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_listen(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_listen);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2003-03-25 01:20:56 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_poll);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_poll(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_poll);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2003-03-25 01:20:56 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_receive);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_receive(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_receive);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_relabel);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_relabel(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel, struct label *newlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK_ASSERT(so);
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
|
|
|
LABEL_CHECK(newlabel, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socket_check_relabel);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_send);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_send(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
2002-08-19 16:59:37 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_send);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-08-19 16:59:37 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_stat);
|
2002-08-19 16:59:37 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_stat(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_stat);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_check_visible);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_check_visible(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_check_visible);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_copy_label);
|
|
|
|
static void
|
|
|
|
test_socket_copy_label(struct label *src, struct label *dest)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(src, MAGIC_SOCKET);
|
|
|
|
LABEL_CHECK(dest, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socket_copy_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(socket_create);
|
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_socket_create(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel)
|
2002-08-19 16:59:37 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_create);
|
|
|
|
}
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_create_mbuf);
|
|
|
|
static void
|
2009-06-03 18:46:28 +00:00
|
|
|
test_socket_create_mbuf(struct socket *so, struct label *solabel,
|
2007-10-29 15:30:47 +00:00
|
|
|
struct mbuf *m, struct label *mlabel)
|
2007-10-29 13:33:06 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_create_mbuf);
|
2002-08-19 16:59:37 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_destroy_label);
|
|
|
|
static void
|
|
|
|
test_socket_destroy_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socket_destroy_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(socket_externalize_label);
|
2002-08-19 16:59:37 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_externalize_label(struct label *label, char *element_name,
|
|
|
|
struct sbuf *sb, int *claimed)
|
2002-08-19 16:59:37 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(label, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socket_externalize_label);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-08-19 16:59:37 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_init_label);
|
2005-05-04 10:39:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socket_init_label(struct label *label, int flag)
|
2005-05-04 10:39:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
if (flag & M_WAITOK)
|
|
|
|
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
|
|
|
|
"test_socket_init_label() at %s:%d", __FILE__,
|
|
|
|
__LINE__);
|
2007-10-27 10:38:57 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socket_init_label);
|
2007-10-27 10:38:57 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-30 00:01:28 +00:00
|
|
|
COUNTER_DECL(socket_internalize_label);
|
|
|
|
static int
|
|
|
|
test_socket_internalize_label(struct label *label, char *element_name,
|
|
|
|
char *element_data, int *claimed)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(label, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socket_internalize_label);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socket_newconn);
|
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_socket_newconn(struct socket *oldso, struct label *oldsolabel,
|
|
|
|
struct socket *newso, struct label *newsolabel)
|
2007-10-29 13:33:06 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(oldso);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(oldsolabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(oldso);
|
|
|
|
SOCK_LOCK(newso);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(newsolabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(newso);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socket_newconn);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(socket_relabel);
|
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_socket_relabel(struct ucred *cred, struct socket *so,
|
|
|
|
struct label *solabel, struct label *newlabel)
|
2007-10-27 10:38:57 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK_ASSERT(so);
|
|
|
|
|
2007-10-27 10:38:57 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(solabel, MAGIC_SOCKET);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(newlabel, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socket_relabel);
|
|
|
|
}
|
2007-10-27 10:38:57 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socketpeer_destroy_label);
|
|
|
|
static void
|
|
|
|
test_socketpeer_destroy_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socketpeer_destroy_label);
|
2007-10-27 10:38:57 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socketpeer_externalize_label);
|
2007-10-27 10:38:57 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socketpeer_externalize_label(struct label *label, char *element_name,
|
|
|
|
struct sbuf *sb, int *claimed)
|
2007-10-27 10:38:57 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(label, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socketpeer_externalize_label);
|
2007-10-27 10:38:57 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socketpeer_init_label);
|
2007-10-27 10:38:57 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_socketpeer_init_label(struct label *label, int flag)
|
2007-10-27 10:38:57 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
if (flag & M_WAITOK)
|
|
|
|
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
|
|
|
|
"test_socketpeer_init_label() at %s:%d", __FILE__,
|
|
|
|
__LINE__);
|
2007-10-27 10:38:57 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_SOCKET);
|
|
|
|
COUNTER_INC(socketpeer_init_label);
|
2007-10-27 10:38:57 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socketpeer_set_from_mbuf);
|
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_socketpeer_set_from_mbuf(struct mbuf *m, struct label *mlabel,
|
2009-06-03 18:46:28 +00:00
|
|
|
struct socket *so, struct label *sopeerlabel)
|
2007-10-27 10:38:57 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(so);
|
|
|
|
LABEL_CHECK(sopeerlabel, MAGIC_SOCKET);
|
|
|
|
SOCK_UNLOCK(so);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socketpeer_set_from_mbuf);
|
|
|
|
}
|
2007-10-27 10:38:57 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(socketpeer_set_from_socket);
|
|
|
|
static void
|
2007-10-29 15:30:47 +00:00
|
|
|
test_socketpeer_set_from_socket(struct socket *oldso,
|
|
|
|
struct label *oldsolabel, struct socket *newso,
|
|
|
|
struct label *newsopeerlabel)
|
2007-10-29 13:33:06 +00:00
|
|
|
{
|
|
|
|
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_LOCK(oldso);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(oldsolabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(oldso);
|
|
|
|
SOCK_LOCK(newso);
|
2007-10-29 15:30:47 +00:00
|
|
|
LABEL_CHECK(newsopeerlabel, MAGIC_SOCKET);
|
2009-06-03 18:46:28 +00:00
|
|
|
SOCK_UNLOCK(newso);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(socketpeer_set_from_socket);
|
2007-10-27 10:38:57 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(syncache_create);
|
|
|
|
static void
|
|
|
|
test_syncache_create(struct label *label, struct inpcb *inp)
|
2007-10-27 10:38:57 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(label, MAGIC_SYNCACHE);
|
|
|
|
COUNTER_INC(syncache_create);
|
|
|
|
}
|
2005-05-04 10:39:15 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(syncache_create_mbuf);
|
|
|
|
static void
|
|
|
|
test_syncache_create_mbuf(struct label *sc_label, struct mbuf *m,
|
|
|
|
struct label *mlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(sc_label, MAGIC_SYNCACHE);
|
|
|
|
LABEL_CHECK(mlabel, MAGIC_MBUF);
|
|
|
|
COUNTER_INC(syncache_create_mbuf);
|
2005-05-04 10:39:15 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(syncache_destroy_label);
|
|
|
|
static void
|
|
|
|
test_syncache_destroy_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_SYNCACHE);
|
|
|
|
COUNTER_INC(syncache_destroy_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(syncache_init_label);
|
|
|
|
static int
|
|
|
|
test_syncache_init_label(struct label *label, int flag)
|
|
|
|
{
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
if (flag & M_WAITOK)
|
|
|
|
WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
|
|
|
|
"test_syncache_init_label() at %s:%d", __FILE__,
|
|
|
|
__LINE__);
|
|
|
|
LABEL_INIT(label, MAGIC_SYNCACHE);
|
|
|
|
COUNTER_INC(syncache_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_acct);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_acct(struct ucred *cred, struct vnode *vp,
|
|
|
|
struct label *vplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(system_check_acct);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_audit);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_audit(struct ucred *cred, void *record, int length)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(system_check_audit);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_auditctl);
|
2007-04-21 22:08:48 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_auditctl(struct ucred *cred, struct vnode *vp,
|
|
|
|
struct label *vplabel)
|
2007-04-21 22:08:48 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(system_check_auditctl);
|
2007-04-21 22:08:48 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_auditon);
|
2007-06-26 14:14:01 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_auditon(struct ucred *cred, int cmd)
|
2007-06-26 14:14:01 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(system_check_auditon);
|
2007-06-26 14:14:01 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_reboot);
|
2007-04-21 22:08:48 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_reboot(struct ucred *cred, int how)
|
2007-04-21 22:08:48 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(system_check_reboot);
|
2007-04-21 22:08:48 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_swapoff);
|
2005-04-16 13:29:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_swapoff(struct ucred *cred, struct vnode *vp,
|
|
|
|
struct label *vplabel)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(system_check_swapoff);
|
2005-04-16 13:29:15 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_swapon);
|
2005-04-16 13:29:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_swapon(struct ucred *cred, struct vnode *vp,
|
|
|
|
struct label *vplabel)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(system_check_swapon);
|
2005-04-16 13:29:15 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(system_check_sysctl);
|
2005-04-16 13:29:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_system_check_sysctl(struct ucred *cred, struct sysctl_oid *oidp,
|
|
|
|
void *arg1, int arg2, struct sysctl_req *req)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(system_check_sysctl);
|
2005-04-16 13:29:15 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsg_cleanup);
|
|
|
|
static void
|
|
|
|
test_sysvmsg_cleanup(struct label *msglabel)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msglabel, MAGIC_SYSV_MSG);
|
|
|
|
COUNTER_INC(sysvmsg_cleanup);
|
|
|
|
}
|
2005-04-16 13:29:15 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsg_create);
|
|
|
|
static void
|
|
|
|
test_sysvmsg_create(struct ucred *cred, struct msqid_kernel *msqkptr,
|
|
|
|
struct label *msqlabel, struct msg *msgptr, struct label *msglabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(msglabel, MAGIC_SYSV_MSG);
|
|
|
|
LABEL_CHECK(msqlabel, MAGIC_SYSV_MSQ);
|
|
|
|
COUNTER_INC(sysvmsg_create);
|
2005-04-16 13:29:15 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsg_destroy_label);
|
|
|
|
static void
|
|
|
|
test_sysvmsg_destroy_label(struct label *label)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_SYSV_MSG);
|
|
|
|
COUNTER_INC(sysvmsg_destroy_label);
|
|
|
|
}
|
2005-04-16 13:29:15 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsg_init_label);
|
|
|
|
static void
|
|
|
|
test_sysvmsg_init_label(struct label *label)
|
|
|
|
{
|
|
|
|
LABEL_INIT(label, MAGIC_SYSV_MSG);
|
|
|
|
COUNTER_INC(sysvmsg_init_label);
|
2005-04-16 13:29:15 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_check_msgmsq);
|
2005-04-16 13:29:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvmsq_check_msgmsq(struct ucred *cred, struct msg *msgptr,
|
|
|
|
struct label *msglabel, struct msqid_kernel *msqkptr,
|
|
|
|
struct label *msqklabel)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msqklabel, MAGIC_SYSV_MSQ);
|
|
|
|
LABEL_CHECK(msglabel, MAGIC_SYSV_MSG);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(sysvmsq_check_msgmsq);
|
2005-04-16 13:29:15 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-04-16 13:29:15 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_check_msgrcv);
|
2005-04-16 13:29:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvmsq_check_msgrcv(struct ucred *cred, struct msg *msgptr,
|
|
|
|
struct label *msglabel)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msglabel, MAGIC_SYSV_MSG);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(sysvmsq_check_msgrcv);
|
2005-04-16 13:29:15 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_check_msgrmid);
|
2005-04-16 13:29:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvmsq_check_msgrmid(struct ucred *cred, struct msg *msgptr,
|
|
|
|
struct label *msglabel)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msglabel, MAGIC_SYSV_MSG);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(sysvmsq_check_msgrmid);
|
2005-04-16 13:29:15 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_check_msqget);
|
2005-04-16 13:29:15 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvmsq_check_msqget(struct ucred *cred,
|
|
|
|
struct msqid_kernel *msqkptr, struct label *msqklabel)
|
2005-04-16 13:29:15 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msqklabel, MAGIC_SYSV_MSQ);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(sysvmsq_check_msqget);
|
2005-04-16 13:29:15 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_check_msqsnd);
|
2005-04-18 13:36:57 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvmsq_check_msqsnd(struct ucred *cred,
|
|
|
|
struct msqid_kernel *msqkptr, struct label *msqklabel)
|
2005-04-18 13:36:57 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msqklabel, MAGIC_SYSV_MSQ);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(sysvmsq_check_msqsnd);
|
2005-04-18 13:36:57 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_check_msqrcv);
|
2005-04-16 18:46:29 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvmsq_check_msqrcv(struct ucred *cred,
|
|
|
|
struct msqid_kernel *msqkptr, struct label *msqklabel)
|
2005-04-16 18:46:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msqklabel, MAGIC_SYSV_MSQ);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(sysvmsq_check_msqrcv);
|
2005-04-16 18:46:29 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_check_msqctl);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvmsq_check_msqctl(struct ucred *cred,
|
|
|
|
struct msqid_kernel *msqkptr, struct label *msqklabel, int cmd)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msqklabel, MAGIC_SYSV_MSQ);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(sysvmsq_check_msqctl);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_cleanup);
|
|
|
|
static void
|
|
|
|
test_sysvmsq_cleanup(struct label *msqlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(msqlabel, MAGIC_SYSV_MSQ);
|
|
|
|
COUNTER_INC(sysvmsq_cleanup);
|
|
|
|
}
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_create);
|
|
|
|
static void
|
|
|
|
test_sysvmsq_create(struct ucred *cred,
|
|
|
|
struct msqid_kernel *msqkptr, struct label *msqlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(msqlabel, MAGIC_SYSV_MSQ);
|
|
|
|
COUNTER_INC(sysvmsq_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_destroy_label);
|
|
|
|
static void
|
|
|
|
test_sysvmsq_destroy_label(struct label *label)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_SYSV_MSQ);
|
|
|
|
COUNTER_INC(sysvmsq_destroy_label);
|
|
|
|
}
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvmsq_init_label);
|
|
|
|
static void
|
|
|
|
test_sysvmsq_init_label(struct label *label)
|
|
|
|
{
|
|
|
|
LABEL_INIT(label, MAGIC_SYSV_MSQ);
|
|
|
|
COUNTER_INC(sysvmsq_init_label);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvsem_check_semctl);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvsem_check_semctl(struct ucred *cred,
|
|
|
|
struct semid_kernel *semakptr, struct label *semaklabel, int cmd)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(semaklabel, MAGIC_SYSV_SEM);
|
|
|
|
COUNTER_INC(sysvsem_check_semctl);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvsem_check_semget);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvsem_check_semget(struct ucred *cred,
|
|
|
|
struct semid_kernel *semakptr, struct label *semaklabel)
|
2005-04-16 18:46:29 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(semaklabel, MAGIC_SYSV_SEM);
|
|
|
|
COUNTER_INC(sysvsem_check_semget);
|
2005-04-16 18:46:29 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvsem_check_semop);
|
2005-04-16 18:46:29 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvsem_check_semop(struct ucred *cred,
|
|
|
|
struct semid_kernel *semakptr, struct label *semaklabel, size_t accesstype)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(semaklabel, MAGIC_SYSV_SEM);
|
|
|
|
COUNTER_INC(sysvsem_check_semop);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvsem_cleanup);
|
|
|
|
static void
|
|
|
|
test_sysvsem_cleanup(struct label *semalabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(semalabel, MAGIC_SYSV_SEM);
|
|
|
|
COUNTER_INC(sysvsem_cleanup);
|
|
|
|
}
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvsem_create);
|
|
|
|
static void
|
|
|
|
test_sysvsem_create(struct ucred *cred, struct semid_kernel *semakptr,
|
|
|
|
struct label *semalabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(semalabel, MAGIC_SYSV_SEM);
|
|
|
|
COUNTER_INC(sysvsem_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvsem_destroy_label);
|
|
|
|
static void
|
|
|
|
test_sysvsem_destroy_label(struct label *label)
|
2005-04-16 18:46:29 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_SYSV_SEM);
|
|
|
|
COUNTER_INC(sysvsem_destroy_label);
|
|
|
|
}
|
2005-04-16 18:46:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvsem_init_label);
|
|
|
|
static void
|
|
|
|
test_sysvsem_init_label(struct label *label)
|
|
|
|
{
|
|
|
|
LABEL_INIT(label, MAGIC_SYSV_SEM);
|
|
|
|
COUNTER_INC(sysvsem_init_label);
|
2005-04-16 18:46:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_check_shmat);
|
2005-04-16 18:46:29 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvshm_check_shmat(struct ucred *cred,
|
|
|
|
struct shmid_kernel *shmsegptr, struct label *shmseglabel, int shmflg)
|
2005-04-16 18:46:29 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(shmseglabel, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_check_shmat);
|
2005-04-16 18:46:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-04-16 18:46:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_check_shmctl);
|
2005-04-16 18:46:29 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvshm_check_shmctl(struct ucred *cred,
|
|
|
|
struct shmid_kernel *shmsegptr, struct label *shmseglabel, int cmd)
|
2005-04-16 18:46:29 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(shmseglabel, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_check_shmctl);
|
2005-04-16 18:46:29 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
return (0);
|
2005-04-16 18:46:29 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_check_shmdt);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvshm_check_shmdt(struct ucred *cred,
|
|
|
|
struct shmid_kernel *shmsegptr, struct label *shmseglabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(shmseglabel, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_check_shmdt);
|
2007-04-21 22:08:48 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_check_shmget);
|
2007-04-21 22:08:48 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_sysvshm_check_shmget(struct ucred *cred,
|
|
|
|
struct shmid_kernel *shmsegptr, struct label *shmseglabel, int shmflg)
|
2007-04-21 22:08:48 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(shmseglabel, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_check_shmget);
|
2007-04-21 22:08:48 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_cleanup);
|
|
|
|
static void
|
|
|
|
test_sysvshm_cleanup(struct label *shmlabel)
|
2007-04-21 22:08:48 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(shmlabel, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_cleanup);
|
2007-04-21 22:08:48 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_create);
|
|
|
|
static void
|
|
|
|
test_sysvshm_create(struct ucred *cred, struct shmid_kernel *shmsegptr,
|
|
|
|
struct label *shmlabel)
|
2007-04-21 22:08:48 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(shmlabel, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_create);
|
2003-03-25 01:20:56 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_destroy_label);
|
|
|
|
static void
|
|
|
|
test_sysvshm_destroy_label(struct label *label)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_DESTROY(label, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_destroy_label);
|
2003-03-25 01:20:56 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(sysvshm_init_label);
|
|
|
|
static void
|
|
|
|
test_sysvshm_init_label(struct label *label)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_INIT(label, MAGIC_SYSV_SHM);
|
|
|
|
COUNTER_INC(sysvshm_init_label);
|
|
|
|
}
|
2003-03-25 01:20:56 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(thread_userret);
|
|
|
|
static void
|
|
|
|
test_thread_userret(struct thread *td)
|
|
|
|
{
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(thread_userret);
|
2003-03-25 01:20:56 +00:00
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(vnode_associate_extattr);
|
2003-03-25 01:20:56 +00:00
|
|
|
static int
|
2007-10-29 13:33:06 +00:00
|
|
|
test_vnode_associate_extattr(struct mount *mp, struct label *mplabel,
|
|
|
|
struct vnode *vp, struct label *vplabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(mplabel, MAGIC_MOUNT);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_INC(vnode_associate_extattr);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2003-03-25 01:20:56 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(vnode_associate_singlelabel);
|
|
|
|
static void
|
|
|
|
test_vnode_associate_singlelabel(struct mount *mp, struct label *mplabel,
|
|
|
|
struct vnode *vp, struct label *vplabel)
|
2003-03-25 01:20:56 +00:00
|
|
|
{
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
LABEL_CHECK(mplabel, MAGIC_MOUNT);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_associate_singlelabel);
|
2003-03-25 01:20:56 +00:00
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_access);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_access(struct ucred *cred, struct vnode *vp,
|
2008-10-28 13:44:11 +00:00
|
|
|
struct label *vplabel, accmode_t accmode)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_access);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_chdir);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_chdir(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_chdir);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_chroot);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_chroot(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_chroot);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_create);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_create(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel, struct componentname *cnp, struct vattr *vap)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_create);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_deleteacl);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_deleteacl(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, acl_type_t type)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_deleteacl);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_deleteextattr);
|
2003-08-21 17:28:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_deleteextattr(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, int attrnamespace, const char *name)
|
2003-08-21 17:28:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_deleteextattr);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_exec);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_exec(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, struct image_params *imgp,
|
2002-11-08 18:04:36 +00:00
|
|
|
struct label *execlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(execlabel, MAGIC_CRED);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_exec);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_getacl);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_getacl(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, acl_type_t type)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_getacl);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_getextattr);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_getextattr(struct ucred *cred, struct vnode *vp,
|
2009-03-08 12:32:06 +00:00
|
|
|
struct label *vplabel, int attrnamespace, const char *name)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_getextattr);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_link);
|
2002-10-05 18:25:48 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_link(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel, struct vnode *vp, struct label *vplabel,
|
2002-10-05 18:25:48 +00:00
|
|
|
struct componentname *cnp)
|
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_link);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_listextattr);
|
2003-08-21 17:28:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_listextattr(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, int attrnamespace)
|
2003-08-21 17:28:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_listextattr);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-10-05 18:25:48 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_lookup);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_lookup(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel, struct componentname *cnp)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
2002-10-06 02:46:26 +00:00
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_lookup);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-10-06 02:46:26 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_mmap);
|
2002-10-06 02:46:26 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_mmap(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, int prot, int flags)
|
2002-10-06 02:46:26 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_mmap);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
2002-10-06 02:46:26 +00:00
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_open);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_open(struct ucred *cred, struct vnode *vp,
|
2008-10-28 13:44:11 +00:00
|
|
|
struct label *vplabel, accmode_t accmode)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_open);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_poll);
|
2002-08-19 16:43:25 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_poll(struct ucred *active_cred, struct ucred *file_cred,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct vnode *vp, struct label *vplabel)
|
2002-08-19 16:43:25 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
if (file_cred != NULL)
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_poll);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-08-19 16:43:25 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_read);
|
2002-08-19 16:43:25 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_read(struct ucred *active_cred, struct ucred *file_cred,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct vnode *vp, struct label *vplabel)
|
2002-08-19 16:43:25 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
if (file_cred != NULL)
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_read);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-08-19 16:43:25 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_readdir);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_readdir(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_readdir);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_readlink);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_readlink(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_readlink);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_relabel);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_relabel(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, struct label *newlabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(newlabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_relabel);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_rename_from);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_rename_from(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel, struct vnode *vp, struct label *vplabel,
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
struct componentname *cnp)
|
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_rename_from);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_rename_to);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_rename_to(struct ucred *cred, struct vnode *dvp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *dvplabel, struct vnode *vp, struct label *vplabel,
|
|
|
|
int samedir, struct componentname *cnp)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_rename_to);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_revoke);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_revoke(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_revoke);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_setacl);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_setacl(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, acl_type_t type, struct acl *acl)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_setacl);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_setextattr);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_setextattr(struct ucred *cred, struct vnode *vp,
|
2009-03-08 12:32:06 +00:00
|
|
|
struct label *vplabel, int attrnamespace, const char *name)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_setextattr);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_setflags);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_setflags(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, u_long flags)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_setflags);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_setmode);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_setmode(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, mode_t mode)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_setmode);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_setowner);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_setowner(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, uid_t uid, gid_t gid)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_setowner);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_setutimes);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_setutimes(struct ucred *cred, struct vnode *vp,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct label *vplabel, struct timespec atime, struct timespec mtime)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_setutimes);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_stat);
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_stat(struct ucred *active_cred, struct ucred *file_cred,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct vnode *vp, struct label *vplabel)
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
if (file_cred != NULL)
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_stat);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_unlink);
|
2007-09-10 00:00:18 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_unlink(struct ucred *cred, struct vnode *dvp,
|
2007-09-10 00:00:18 +00:00
|
|
|
struct label *dvplabel, struct vnode *vp, struct label *vplabel,
|
|
|
|
struct componentname *cnp)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_unlink);
|
2007-09-10 00:00:18 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_DECL(vnode_check_write);
|
2002-08-19 16:43:25 +00:00
|
|
|
static int
|
2007-10-25 11:31:11 +00:00
|
|
|
test_vnode_check_write(struct ucred *active_cred,
|
2007-04-23 13:15:23 +00:00
|
|
|
struct ucred *file_cred, struct vnode *vp, struct label *vplabel)
|
2002-08-19 16:43:25 +00:00
|
|
|
{
|
|
|
|
|
2007-04-22 11:35:15 +00:00
|
|
|
LABEL_CHECK(active_cred->cr_label, MAGIC_CRED);
|
|
|
|
if (file_cred != NULL)
|
|
|
|
LABEL_CHECK(file_cred->cr_label, MAGIC_CRED);
|
2007-04-23 13:15:23 +00:00
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
2007-10-24 19:04:04 +00:00
|
|
|
COUNTER_INC(vnode_check_write);
|
2003-08-21 17:28:45 +00:00
|
|
|
|
2002-08-19 16:43:25 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(vnode_copy_label);
|
|
|
|
static void
|
|
|
|
test_vnode_copy_label(struct label *src, struct label *dest)
|
2007-10-25 11:31:11 +00:00
|
|
|
{
|
2007-10-29 13:33:06 +00:00
|
|
|
|
|
|
|
LABEL_CHECK(src, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(dest, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_copy_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(vnode_create_extattr);
|
|
|
|
static int
|
|
|
|
test_vnode_create_extattr(struct ucred *cred, struct mount *mp,
|
|
|
|
struct label *mplabel, struct vnode *dvp, struct label *dvplabel,
|
|
|
|
struct vnode *vp, struct label *vplabel, struct componentname *cnp)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(mplabel, MAGIC_MOUNT);
|
|
|
|
LABEL_CHECK(dvplabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_create_extattr);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(vnode_destroy_label);
|
|
|
|
static void
|
|
|
|
test_vnode_destroy_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_DESTROY(label, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_destroy_label);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(vnode_execve_transition);
|
|
|
|
static void
|
|
|
|
test_vnode_execve_transition(struct ucred *old, struct ucred *new,
|
|
|
|
struct vnode *vp, struct label *filelabel,
|
|
|
|
struct label *interpvplabel, struct image_params *imgp,
|
|
|
|
struct label *execlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(old->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(new->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(filelabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(interpvplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(execlabel, MAGIC_CRED);
|
|
|
|
COUNTER_INC(vnode_execve_transition);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(vnode_execve_will_transition);
|
|
|
|
static int
|
|
|
|
test_vnode_execve_will_transition(struct ucred *old, struct vnode *vp,
|
|
|
|
struct label *filelabel, struct label *interpvplabel,
|
|
|
|
struct image_params *imgp, struct label *execlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(old->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(filelabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(interpvplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(execlabel, MAGIC_CRED);
|
|
|
|
COUNTER_INC(vnode_execve_will_transition);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(vnode_externalize_label);
|
|
|
|
static int
|
|
|
|
test_vnode_externalize_label(struct label *label, char *element_name,
|
|
|
|
struct sbuf *sb, int *claimed)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(label, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_externalize_label);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(vnode_init_label);
|
|
|
|
static void
|
|
|
|
test_vnode_init_label(struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_INIT(label, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_init_label);
|
|
|
|
}
|
|
|
|
|
2007-10-30 00:01:28 +00:00
|
|
|
COUNTER_DECL(vnode_internalize_label);
|
|
|
|
static int
|
|
|
|
test_vnode_internalize_label(struct label *label, char *element_name,
|
|
|
|
char *element_data, int *claimed)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(label, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_internalize_label);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
COUNTER_DECL(vnode_relabel);
|
|
|
|
static void
|
|
|
|
test_vnode_relabel(struct ucred *cred, struct vnode *vp,
|
|
|
|
struct label *vplabel, struct label *label)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(label, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_relabel);
|
|
|
|
}
|
|
|
|
|
|
|
|
COUNTER_DECL(vnode_setlabel_extattr);
|
|
|
|
static int
|
|
|
|
test_vnode_setlabel_extattr(struct ucred *cred, struct vnode *vp,
|
|
|
|
struct label *vplabel, struct label *intlabel)
|
|
|
|
{
|
|
|
|
|
|
|
|
LABEL_CHECK(cred->cr_label, MAGIC_CRED);
|
|
|
|
LABEL_CHECK(vplabel, MAGIC_VNODE);
|
|
|
|
LABEL_CHECK(intlabel, MAGIC_VNODE);
|
|
|
|
COUNTER_INC(vnode_setlabel_extattr);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct mac_policy_ops test_ops =
|
|
|
|
{
|
|
|
|
.mpo_bpfdesc_check_receive = test_bpfdesc_check_receive,
|
|
|
|
.mpo_bpfdesc_create = test_bpfdesc_create,
|
|
|
|
.mpo_bpfdesc_create_mbuf = test_bpfdesc_create_mbuf,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_bpfdesc_destroy_label = test_bpfdesc_destroy_label,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_bpfdesc_init_label = test_bpfdesc_init_label,
|
|
|
|
|
|
|
|
.mpo_cred_check_relabel = test_cred_check_relabel,
|
2009-03-08 10:58:37 +00:00
|
|
|
.mpo_cred_check_setaudit = test_cred_check_setaudit,
|
|
|
|
.mpo_cred_check_setaudit_addr = test_cred_check_setaudit_addr,
|
|
|
|
.mpo_cred_check_setauid = test_cred_check_setauid,
|
|
|
|
.mpo_cred_check_seteuid = test_cred_check_seteuid,
|
|
|
|
.mpo_cred_check_setegid = test_cred_check_setegid,
|
|
|
|
.mpo_cred_check_setgid = test_cred_check_setgid,
|
|
|
|
.mpo_cred_check_setgroups = test_cred_check_setgroups,
|
|
|
|
.mpo_cred_check_setregid = test_cred_check_setregid,
|
|
|
|
.mpo_cred_check_setresgid = test_cred_check_setresgid,
|
|
|
|
.mpo_cred_check_setresuid = test_cred_check_setresuid,
|
|
|
|
.mpo_cred_check_setreuid = test_cred_check_setreuid,
|
|
|
|
.mpo_cred_check_setuid = test_cred_check_setuid,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_cred_check_visible = test_cred_check_visible,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_cred_copy_label = test_cred_copy_label,
|
2008-10-28 11:33:06 +00:00
|
|
|
.mpo_cred_create_init = test_cred_create_init,
|
|
|
|
.mpo_cred_create_swapper = test_cred_create_swapper,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_cred_destroy_label = test_cred_destroy_label,
|
2007-10-28 14:28:33 +00:00
|
|
|
.mpo_cred_externalize_label = test_cred_externalize_label,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_cred_init_label = test_cred_init_label,
|
2007-10-30 00:01:28 +00:00
|
|
|
.mpo_cred_internalize_label = test_cred_internalize_label,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_cred_relabel = test_cred_relabel,
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_devfs_create_device = test_devfs_create_device,
|
|
|
|
.mpo_devfs_create_directory = test_devfs_create_directory,
|
|
|
|
.mpo_devfs_create_symlink = test_devfs_create_symlink,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_devfs_destroy_label = test_devfs_destroy_label,
|
|
|
|
.mpo_devfs_init_label = test_devfs_init_label,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_devfs_update = test_devfs_update,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_devfs_vnode_associate = test_devfs_vnode_associate,
|
|
|
|
|
|
|
|
.mpo_ifnet_check_relabel = test_ifnet_check_relabel,
|
|
|
|
.mpo_ifnet_check_transmit = test_ifnet_check_transmit,
|
|
|
|
.mpo_ifnet_copy_label = test_ifnet_copy_label,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_ifnet_create = test_ifnet_create,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_ifnet_create_mbuf = test_ifnet_create_mbuf,
|
|
|
|
.mpo_ifnet_destroy_label = test_ifnet_destroy_label,
|
|
|
|
.mpo_ifnet_externalize_label = test_ifnet_externalize_label,
|
|
|
|
.mpo_ifnet_init_label = test_ifnet_init_label,
|
2007-10-30 00:01:28 +00:00
|
|
|
.mpo_ifnet_internalize_label = test_ifnet_internalize_label,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_ifnet_relabel = test_ifnet_relabel,
|
|
|
|
|
|
|
|
.mpo_syncache_destroy_label = test_syncache_destroy_label,
|
|
|
|
.mpo_syncache_init_label = test_syncache_init_label,
|
|
|
|
|
|
|
|
.mpo_sysvmsg_destroy_label = test_sysvmsg_destroy_label,
|
|
|
|
.mpo_sysvmsg_init_label = test_sysvmsg_init_label,
|
|
|
|
|
|
|
|
.mpo_sysvmsq_destroy_label = test_sysvmsq_destroy_label,
|
|
|
|
.mpo_sysvmsq_init_label = test_sysvmsq_init_label,
|
|
|
|
|
|
|
|
.mpo_sysvsem_destroy_label = test_sysvsem_destroy_label,
|
|
|
|
.mpo_sysvsem_init_label = test_sysvsem_init_label,
|
|
|
|
|
|
|
|
.mpo_sysvshm_destroy_label = test_sysvshm_destroy_label,
|
|
|
|
.mpo_sysvshm_init_label = test_sysvshm_init_label,
|
|
|
|
|
|
|
|
.mpo_inpcb_check_deliver = test_inpcb_check_deliver,
|
2008-10-17 15:11:12 +00:00
|
|
|
.mpo_inpcb_check_visible = test_inpcb_check_visible,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_inpcb_create = test_inpcb_create,
|
|
|
|
.mpo_inpcb_create_mbuf = test_inpcb_create_mbuf,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_inpcb_destroy_label = test_inpcb_destroy_label,
|
|
|
|
.mpo_inpcb_init_label = test_inpcb_init_label,
|
|
|
|
.mpo_inpcb_sosetlabel = test_inpcb_sosetlabel,
|
|
|
|
|
2008-10-26 22:46:37 +00:00
|
|
|
.mpo_ip6q_create = test_ip6q_create,
|
|
|
|
.mpo_ip6q_destroy_label = test_ip6q_destroy_label,
|
|
|
|
.mpo_ip6q_init_label = test_ip6q_init_label,
|
|
|
|
.mpo_ip6q_match = test_ip6q_match,
|
|
|
|
.mpo_ip6q_reassemble = test_ip6q_reassemble,
|
|
|
|
.mpo_ip6q_update = test_ip6q_update,
|
|
|
|
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_ipq_create = test_ipq_create,
|
|
|
|
.mpo_ipq_destroy_label = test_ipq_destroy_label,
|
|
|
|
.mpo_ipq_init_label = test_ipq_init_label,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_ipq_match = test_ipq_match,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_ipq_reassemble = test_ipq_reassemble,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_ipq_update = test_ipq_update,
|
2007-10-29 13:33:06 +00:00
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_kenv_check_dump = test_kenv_check_dump,
|
|
|
|
.mpo_kenv_check_get = test_kenv_check_get,
|
|
|
|
.mpo_kenv_check_set = test_kenv_check_set,
|
|
|
|
.mpo_kenv_check_unset = test_kenv_check_unset,
|
2007-10-29 13:33:06 +00:00
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_kld_check_load = test_kld_check_load,
|
|
|
|
.mpo_kld_check_stat = test_kld_check_stat,
|
2007-10-29 13:33:06 +00:00
|
|
|
|
|
|
|
.mpo_mbuf_copy_label = test_mbuf_copy_label,
|
|
|
|
.mpo_mbuf_destroy_label = test_mbuf_destroy_label,
|
|
|
|
.mpo_mbuf_init_label = test_mbuf_init_label,
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_mount_check_stat = test_mount_check_stat,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_mount_create = test_mount_create,
|
|
|
|
.mpo_mount_destroy_label = test_mount_destroy_label,
|
|
|
|
.mpo_mount_init_label = test_mount_init_label,
|
|
|
|
|
|
|
|
.mpo_netinet_arp_send = test_netinet_arp_send,
|
|
|
|
.mpo_netinet_fragment = test_netinet_fragment,
|
|
|
|
.mpo_netinet_icmp_reply = test_netinet_icmp_reply,
|
|
|
|
.mpo_netinet_icmp_replyinplace = test_netinet_icmp_replyinplace,
|
|
|
|
.mpo_netinet_igmp_send = test_netinet_igmp_send,
|
|
|
|
.mpo_netinet_tcp_reply = test_netinet_tcp_reply,
|
|
|
|
|
|
|
|
.mpo_netinet6_nd6_send = test_netinet6_nd6_send,
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_pipe_check_ioctl = test_pipe_check_ioctl,
|
|
|
|
.mpo_pipe_check_poll = test_pipe_check_poll,
|
|
|
|
.mpo_pipe_check_read = test_pipe_check_read,
|
|
|
|
.mpo_pipe_check_relabel = test_pipe_check_relabel,
|
|
|
|
.mpo_pipe_check_stat = test_pipe_check_stat,
|
|
|
|
.mpo_pipe_check_write = test_pipe_check_write,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_pipe_copy_label = test_pipe_copy_label,
|
|
|
|
.mpo_pipe_create = test_pipe_create,
|
|
|
|
.mpo_pipe_destroy_label = test_pipe_destroy_label,
|
|
|
|
.mpo_pipe_externalize_label = test_pipe_externalize_label,
|
|
|
|
.mpo_pipe_init_label = test_pipe_init_label,
|
2007-10-30 00:01:28 +00:00
|
|
|
.mpo_pipe_internalize_label = test_pipe_internalize_label,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_pipe_relabel = test_pipe_relabel,
|
|
|
|
|
2007-10-27 10:38:57 +00:00
|
|
|
.mpo_posixsem_check_getvalue = test_posixsem_check_getvalue,
|
|
|
|
.mpo_posixsem_check_open = test_posixsem_check_open,
|
|
|
|
.mpo_posixsem_check_post = test_posixsem_check_post,
|
2011-08-16 20:07:47 +00:00
|
|
|
.mpo_posixsem_check_setmode = test_posixsem_check_setmode,
|
|
|
|
.mpo_posixsem_check_setowner = test_posixsem_check_setowner,
|
Rework the lifetime management of the kernel implementation of POSIX
semaphores. Specifically, semaphores are now represented as new file
descriptor type that is set to close on exec. This removes the need for
all of the manual process reference counting (and fork, exec, and exit
event handlers) as the normal file descriptor operations handle all of
that for us nicely. It is also suggested as one possible implementation
in the spec and at least one other OS (OS X) uses this approach.
Some bugs that were fixed as a result include:
- References to a named semaphore whose name is removed still work after
the sem_unlink() operation. Prior to this patch, if a semaphore's name
was removed, valid handles from sem_open() would get EINVAL errors from
sem_getvalue(), sem_post(), etc. This fixes that.
- Unnamed semaphores created with sem_init() were not cleaned up when a
process exited or exec'd. They were only cleaned up if the process
did an explicit sem_destroy(). This could result in a leak of semaphore
objects that could never be cleaned up.
- On the other hand, if another process guessed the id (kernel pointer to
'struct ksem' of an unnamed semaphore (created via sem_init)) and had
write access to the semaphore based on UID/GID checks, then that other
process could manipulate the semaphore via sem_destroy(), sem_post(),
sem_wait(), etc.
- As part of the permission check (UID/GID), the umask of the proces
creating the semaphore was not honored. Thus if your umask denied group
read/write access but the explicit mode in the sem_init() call allowed
it, the semaphore would be readable/writable by other users in the
same group, for example. This includes access via the previous bug.
- If the module refused to unload because there were active semaphores,
then it might have deregistered one or more of the semaphore system
calls before it noticed that there was a problem. I'm not sure if
this actually happened as the order that modules are discovered by the
kernel linker depends on how the actual .ko file is linked. One can
make the order deterministic by using a single module with a mod_event
handler that explicitly registers syscalls (and deregisters during
unload after any checks). This also fixes a race where even if the
sem_module unloaded first it would have destroyed locks that the
syscalls might be trying to access if they are still executing when
they are unloaded.
XXX: By the way, deregistering system calls doesn't do any blocking
to drain any threads from the calls.
- Some minor fixes to errno values on error. For example, sem_init()
isn't documented to return ENFILE or EMFILE if we run out of semaphores
the way that sem_open() can. Instead, it should return ENOSPC in that
case.
Other changes:
- Kernel semaphores now use a hash table to manage the namespace of
named semaphores nearly in a similar fashion to the POSIX shared memory
object file descriptors. Kernel semaphores can now also have names
longer than 14 chars (up to MAXPATHLEN) and can include subdirectories
in their pathname.
- The UID/GID permission checks for access to a named semaphore are now
done via vaccess() rather than a home-rolled set of checks.
- Now that kernel semaphores have an associated file object, the various
MAC checks for POSIX semaphores accept both a file credential and an
active credential. There is also a new posixsem_check_stat() since it
is possible to fstat() a semaphore file descriptor.
- A small set of regression tests (using the ksem API directly) is present
in src/tools/regression/posixsem.
Reported by: kris (1)
Tested by: kris
Reviewed by: rwatson (lightly)
MFC after: 1 month
2008-06-27 05:39:04 +00:00
|
|
|
.mpo_posixsem_check_stat = test_posixsem_check_stat,
|
2007-10-27 10:38:57 +00:00
|
|
|
.mpo_posixsem_check_unlink = test_posixsem_check_unlink,
|
|
|
|
.mpo_posixsem_check_wait = test_posixsem_check_wait,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_posixsem_create = test_posixsem_create,
|
|
|
|
.mpo_posixsem_destroy_label = test_posixsem_destroy_label,
|
|
|
|
.mpo_posixsem_init_label = test_posixsem_init_label,
|
|
|
|
|
2011-09-02 17:40:39 +00:00
|
|
|
.mpo_posixshm_check_create = test_posixshm_check_create,
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
.mpo_posixshm_check_mmap = test_posixshm_check_mmap,
|
|
|
|
.mpo_posixshm_check_open = test_posixshm_check_open,
|
2013-08-21 17:45:00 +00:00
|
|
|
.mpo_posixshm_check_read = test_posixshm_check_read,
|
2011-08-16 20:07:47 +00:00
|
|
|
.mpo_posixshm_check_setmode = test_posixshm_check_setmode,
|
|
|
|
.mpo_posixshm_check_setowner = test_posixshm_check_setowner,
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
.mpo_posixshm_check_stat = test_posixshm_check_stat,
|
|
|
|
.mpo_posixshm_check_truncate = test_posixshm_check_truncate,
|
|
|
|
.mpo_posixshm_check_unlink = test_posixshm_check_unlink,
|
2013-08-21 17:45:00 +00:00
|
|
|
.mpo_posixshm_check_write = test_posixshm_check_write,
|
Add a new file descriptor type for IPC shared memory objects and use it to
implement shm_open(2) and shm_unlink(2) in the kernel:
- Each shared memory file descriptor is associated with a swap-backed vm
object which provides the backing store. Each descriptor starts off with
a size of zero, but the size can be altered via ftruncate(2). The shared
memory file descriptors also support fstat(2). read(2), write(2),
ioctl(2), select(2), poll(2), and kevent(2) are not supported on shared
memory file descriptors.
- shm_open(2) and shm_unlink(2) are now implemented as system calls that
manage shared memory file descriptors. The virtual namespace that maps
pathnames to shared memory file descriptors is implemented as a hash
table where the hash key is generated via the 32-bit Fowler/Noll/Vo hash
of the pathname.
- As an extension, the constant 'SHM_ANON' may be specified in place of the
path argument to shm_open(2). In this case, an unnamed shared memory
file descriptor will be created similar to the IPC_PRIVATE key for
shmget(2). Note that the shared memory object can still be shared among
processes by sharing the file descriptor via fork(2) or sendmsg(2), but
it is unnamed. This effectively serves to implement the getmemfd() idea
bandied about the lists several times over the years.
- The backing store for shared memory file descriptors are garbage
collected when they are not referenced by any open file descriptors or
the shm_open(2) virtual namespace.
Submitted by: dillon, peter (previous versions)
Submitted by: rwatson (I based this on his version)
Reviewed by: alc (suggested converting getmemfd() to shm_open())
2008-01-08 21:58:16 +00:00
|
|
|
.mpo_posixshm_create = test_posixshm_create,
|
|
|
|
.mpo_posixshm_destroy_label = test_posixshm_destroy_label,
|
|
|
|
.mpo_posixshm_init_label = test_posixshm_init_label,
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_proc_check_debug = test_proc_check_debug,
|
|
|
|
.mpo_proc_check_sched = test_proc_check_sched,
|
|
|
|
.mpo_proc_check_signal = test_proc_check_signal,
|
|
|
|
.mpo_proc_check_wait = test_proc_check_wait,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_proc_destroy_label = test_proc_destroy_label,
|
|
|
|
.mpo_proc_init_label = test_proc_init_label,
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_socket_check_accept = test_socket_check_accept,
|
|
|
|
.mpo_socket_check_bind = test_socket_check_bind,
|
|
|
|
.mpo_socket_check_connect = test_socket_check_connect,
|
|
|
|
.mpo_socket_check_deliver = test_socket_check_deliver,
|
|
|
|
.mpo_socket_check_listen = test_socket_check_listen,
|
|
|
|
.mpo_socket_check_poll = test_socket_check_poll,
|
|
|
|
.mpo_socket_check_receive = test_socket_check_receive,
|
|
|
|
.mpo_socket_check_relabel = test_socket_check_relabel,
|
|
|
|
.mpo_socket_check_send = test_socket_check_send,
|
|
|
|
.mpo_socket_check_stat = test_socket_check_stat,
|
|
|
|
.mpo_socket_check_visible = test_socket_check_visible,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_socket_copy_label = test_socket_copy_label,
|
|
|
|
.mpo_socket_create = test_socket_create,
|
|
|
|
.mpo_socket_create_mbuf = test_socket_create_mbuf,
|
|
|
|
.mpo_socket_destroy_label = test_socket_destroy_label,
|
|
|
|
.mpo_socket_externalize_label = test_socket_externalize_label,
|
|
|
|
.mpo_socket_init_label = test_socket_init_label,
|
2007-10-30 00:01:28 +00:00
|
|
|
.mpo_socket_internalize_label = test_socket_internalize_label,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_socket_newconn = test_socket_newconn,
|
|
|
|
.mpo_socket_relabel = test_socket_relabel,
|
|
|
|
|
|
|
|
.mpo_socketpeer_destroy_label = test_socketpeer_destroy_label,
|
|
|
|
.mpo_socketpeer_externalize_label = test_socketpeer_externalize_label,
|
|
|
|
.mpo_socketpeer_init_label = test_socketpeer_init_label,
|
|
|
|
.mpo_socketpeer_set_from_mbuf = test_socketpeer_set_from_mbuf,
|
|
|
|
.mpo_socketpeer_set_from_socket = test_socketpeer_set_from_socket,
|
|
|
|
|
|
|
|
.mpo_syncache_create = test_syncache_create,
|
|
|
|
.mpo_syncache_create_mbuf = test_syncache_create_mbuf,
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_system_check_acct = test_system_check_acct,
|
|
|
|
.mpo_system_check_audit = test_system_check_audit,
|
|
|
|
.mpo_system_check_auditctl = test_system_check_auditctl,
|
|
|
|
.mpo_system_check_auditon = test_system_check_auditon,
|
|
|
|
.mpo_system_check_reboot = test_system_check_reboot,
|
|
|
|
.mpo_system_check_swapoff = test_system_check_swapoff,
|
|
|
|
.mpo_system_check_swapon = test_system_check_swapon,
|
|
|
|
.mpo_system_check_sysctl = test_system_check_sysctl,
|
2007-10-29 13:33:06 +00:00
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_vnode_check_access = test_vnode_check_access,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_sysvmsg_cleanup = test_sysvmsg_cleanup,
|
|
|
|
.mpo_sysvmsg_create = test_sysvmsg_create,
|
|
|
|
|
|
|
|
.mpo_sysvmsq_check_msgmsq = test_sysvmsq_check_msgmsq,
|
|
|
|
.mpo_sysvmsq_check_msgrcv = test_sysvmsq_check_msgrcv,
|
|
|
|
.mpo_sysvmsq_check_msgrmid = test_sysvmsq_check_msgrmid,
|
|
|
|
.mpo_sysvmsq_check_msqget = test_sysvmsq_check_msqget,
|
|
|
|
.mpo_sysvmsq_check_msqsnd = test_sysvmsq_check_msqsnd,
|
|
|
|
.mpo_sysvmsq_check_msqrcv = test_sysvmsq_check_msqrcv,
|
|
|
|
.mpo_sysvmsq_check_msqctl = test_sysvmsq_check_msqctl,
|
|
|
|
.mpo_sysvmsq_cleanup = test_sysvmsq_cleanup,
|
|
|
|
.mpo_sysvmsq_create = test_sysvmsq_create,
|
|
|
|
|
|
|
|
.mpo_sysvsem_check_semctl = test_sysvsem_check_semctl,
|
|
|
|
.mpo_sysvsem_check_semget = test_sysvsem_check_semget,
|
|
|
|
.mpo_sysvsem_check_semop = test_sysvsem_check_semop,
|
|
|
|
.mpo_sysvsem_cleanup = test_sysvsem_cleanup,
|
|
|
|
.mpo_sysvsem_create = test_sysvsem_create,
|
|
|
|
|
|
|
|
.mpo_sysvshm_check_shmat = test_sysvshm_check_shmat,
|
|
|
|
.mpo_sysvshm_check_shmctl = test_sysvshm_check_shmctl,
|
|
|
|
.mpo_sysvshm_check_shmdt = test_sysvshm_check_shmdt,
|
|
|
|
.mpo_sysvshm_check_shmget = test_sysvshm_check_shmget,
|
|
|
|
.mpo_sysvshm_cleanup = test_sysvshm_cleanup,
|
|
|
|
.mpo_sysvshm_create = test_sysvshm_create,
|
|
|
|
|
|
|
|
.mpo_thread_userret = test_thread_userret,
|
|
|
|
|
|
|
|
.mpo_vnode_associate_extattr = test_vnode_associate_extattr,
|
|
|
|
.mpo_vnode_associate_singlelabel = test_vnode_associate_singlelabel,
|
2007-10-25 11:31:11 +00:00
|
|
|
.mpo_vnode_check_chdir = test_vnode_check_chdir,
|
|
|
|
.mpo_vnode_check_chroot = test_vnode_check_chroot,
|
|
|
|
.mpo_vnode_check_create = test_vnode_check_create,
|
|
|
|
.mpo_vnode_check_deleteacl = test_vnode_check_deleteacl,
|
|
|
|
.mpo_vnode_check_deleteextattr = test_vnode_check_deleteextattr,
|
|
|
|
.mpo_vnode_check_exec = test_vnode_check_exec,
|
|
|
|
.mpo_vnode_check_getacl = test_vnode_check_getacl,
|
|
|
|
.mpo_vnode_check_getextattr = test_vnode_check_getextattr,
|
|
|
|
.mpo_vnode_check_link = test_vnode_check_link,
|
|
|
|
.mpo_vnode_check_listextattr = test_vnode_check_listextattr,
|
|
|
|
.mpo_vnode_check_lookup = test_vnode_check_lookup,
|
|
|
|
.mpo_vnode_check_mmap = test_vnode_check_mmap,
|
|
|
|
.mpo_vnode_check_open = test_vnode_check_open,
|
|
|
|
.mpo_vnode_check_poll = test_vnode_check_poll,
|
|
|
|
.mpo_vnode_check_read = test_vnode_check_read,
|
|
|
|
.mpo_vnode_check_readdir = test_vnode_check_readdir,
|
|
|
|
.mpo_vnode_check_readlink = test_vnode_check_readlink,
|
|
|
|
.mpo_vnode_check_relabel = test_vnode_check_relabel,
|
|
|
|
.mpo_vnode_check_rename_from = test_vnode_check_rename_from,
|
|
|
|
.mpo_vnode_check_rename_to = test_vnode_check_rename_to,
|
|
|
|
.mpo_vnode_check_revoke = test_vnode_check_revoke,
|
|
|
|
.mpo_vnode_check_setacl = test_vnode_check_setacl,
|
|
|
|
.mpo_vnode_check_setextattr = test_vnode_check_setextattr,
|
|
|
|
.mpo_vnode_check_setflags = test_vnode_check_setflags,
|
|
|
|
.mpo_vnode_check_setmode = test_vnode_check_setmode,
|
|
|
|
.mpo_vnode_check_setowner = test_vnode_check_setowner,
|
|
|
|
.mpo_vnode_check_setutimes = test_vnode_check_setutimes,
|
|
|
|
.mpo_vnode_check_stat = test_vnode_check_stat,
|
|
|
|
.mpo_vnode_check_unlink = test_vnode_check_unlink,
|
|
|
|
.mpo_vnode_check_write = test_vnode_check_write,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_vnode_copy_label = test_vnode_copy_label,
|
|
|
|
.mpo_vnode_create_extattr = test_vnode_create_extattr,
|
|
|
|
.mpo_vnode_destroy_label = test_vnode_destroy_label,
|
|
|
|
.mpo_vnode_execve_transition = test_vnode_execve_transition,
|
|
|
|
.mpo_vnode_execve_will_transition = test_vnode_execve_will_transition,
|
|
|
|
.mpo_vnode_externalize_label = test_vnode_externalize_label,
|
|
|
|
.mpo_vnode_init_label = test_vnode_init_label,
|
2007-10-30 00:01:28 +00:00
|
|
|
.mpo_vnode_internalize_label = test_vnode_internalize_label,
|
2007-10-29 13:33:06 +00:00
|
|
|
.mpo_vnode_relabel = test_vnode_relabel,
|
|
|
|
.mpo_vnode_setlabel_extattr = test_vnode_setlabel_extattr,
|
Introduce support for Mandatory Access Control and extensible
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
2002-07-31 18:07:45 +00:00
|
|
|
};
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
MAC_POLICY_SET(&test_ops, mac_test, "TrustedBSD MAC/Test",
|
2009-01-10 10:58:41 +00:00
|
|
|
MPC_LOADTIME_FLAG_UNLOADOK, &test_slot);
|