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-30 10:13:53 +00:00
|
|
|
* Copyright (c) 1999-2002, 2007-2008 Robert N. M. Watson
|
2005-04-22 18:49:30 +00:00
|
|
|
* Copyright (c) 2001-2005 Networks Associates Technology, Inc.
|
2007-07-05 13:16:04 +00:00
|
|
|
* Copyright (c) 2005 Tom Rhodes
|
2007-10-24 19:04:04 +00:00
|
|
|
* Copyright (c) 2006 SPARTA, 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-04-22 18:49:30 +00:00
|
|
|
* It was later enhanced by Tom Rhodes for the TrustedBSD Project.
|
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-11-04 01:53:12 +00:00
|
|
|
* This software was developed for the FreeBSD Project in part by Network
|
|
|
|
* Associates Laboratories, the Security Research Division of Network
|
|
|
|
* Associates, 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").
|
|
|
|
*
|
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$
|
|
|
|
*/
|
2004-10-22 11:15:47 +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
|
|
|
/*
|
|
|
|
* Developed by the TrustedBSD Project.
|
2007-07-05 13:16:04 +00:00
|
|
|
*
|
|
|
|
* "BSD Extended" MAC policy, allowing the administrator to impose mandatory
|
|
|
|
* firewall-like rules regarding users and file system objects.
|
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>
|
|
|
|
#include <sys/kernel.h>
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
#include <sys/jail.h>
|
2005-04-22 18:49:30 +00:00
|
|
|
#include <sys/lock.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/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>
|
2005-04-22 18:49:30 +00:00
|
|
|
#include <sys/mutex.h>
|
2007-06-13 22:42:43 +00:00
|
|
|
#include <sys/priv.h>
|
MFp4:
Bring in updated jail support from bz_jail branch.
This enhances the current jail implementation to permit multiple
addresses per jail. In addtion to IPv4, IPv6 is supported as well.
Due to updated checks it is even possible to have jails without
an IP address at all, which basically gives one a chroot with
restricted process view, no networking,..
SCTP support was updated and supports IPv6 in jails as well.
Cpuset support permits jails to be bound to specific processor
sets after creation.
Jails can have an unrestricted (no duplicate protection, etc.) name
in addition to the hostname. The jail name cannot be changed from
within a jail and is considered to be used for management purposes
or as audit-token in the future.
DDB 'show jails' command was added to aid debugging.
Proper compat support permits 32bit jail binaries to be used on 64bit
systems to manage jails. Also backward compatibility was preserved where
possible: for jail v1 syscalls, as well as with user space management
utilities.
Both jail as well as prison version were updated for the new features.
A gap was intentionally left as the intermediate versions had been
used by various patches floating around the last years.
Bump __FreeBSD_version for the afore mentioned and in kernel changes.
Special thanks to:
- Pawel Jakub Dawidek (pjd) for his multi-IPv4 patches
and Olivier Houchard (cognet) for initial single-IPv6 patches.
- Jeff Roberson (jeff) and Randall Stewart (rrs) for their
help, ideas and review on cpuset and SCTP support.
- Robert Watson (rwatson) for lots and lots of help, discussions,
suggestions and review of most of the patch at various stages.
- John Baldwin (jhb) for his help.
- Simon L. Nielsen (simon) as early adopter testing changes
on cluster machines as well as all the testers and people
who provided feedback the last months on freebsd-jail and
other channels.
- My employer, CK Software GmbH, for the support so I could work on this.
Reviewed by: (see above)
MFC after: 3 months (this is just so that I get the mail)
X-MFC Before: 7.2-RELEASE if possible
2008-11-29 14:32:14 +00:00
|
|
|
#include <sys/proc.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/systm.h>
|
|
|
|
#include <sys/vnode.h>
|
|
|
|
#include <sys/sysctl.h>
|
2004-08-21 20:19:19 +00:00
|
|
|
#include <sys/syslog.h>
|
2008-09-10 13:16:41 +00:00
|
|
|
#include <sys/stat.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
|
|
|
|
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
|
|
|
#include <security/mac_bsdextended/mac_bsdextended.h>
|
2008-10-27 12:09:15 +00:00
|
|
|
#include <security/mac_bsdextended/ugidfw_internal.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
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
static struct mtx ugidfw_mtx;
|
2005-04-22 18:49:30 +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
|
|
|
SYSCTL_DECL(_security_mac);
|
|
|
|
|
2011-11-07 15:43:11 +00:00
|
|
|
static SYSCTL_NODE(_security_mac, OID_AUTO, bsdextended, 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 extended BSD MAC policy controls");
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
static int ugidfw_enabled = 1;
|
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_INT(_security_mac_bsdextended, OID_AUTO, enabled, CTLFLAG_RW,
|
2007-10-25 11:31:11 +00:00
|
|
|
&ugidfw_enabled, 0, "Enforce extended BSD policy");
|
|
|
|
TUNABLE_INT("security.mac.bsdextended.enabled", &ugidfw_enabled);
|
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-11-07 06:44:47 +00:00
|
|
|
static MALLOC_DEFINE(M_MACBSDEXTENDED, "mac_bsdextended",
|
|
|
|
"BSD Extended MAC rule");
|
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
|
|
|
|
|
|
|
#define MAC_BSDEXTENDED_MAXRULES 250
|
|
|
|
static struct mac_bsdextended_rule *rules[MAC_BSDEXTENDED_MAXRULES];
|
|
|
|
static int rule_count = 0;
|
|
|
|
static int rule_slots = 0;
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
static int rule_version = MB_VERSION;
|
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_INT(_security_mac_bsdextended, OID_AUTO, rule_count, CTLFLAG_RD,
|
|
|
|
&rule_count, 0, "Number of defined rules\n");
|
|
|
|
SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, rule_slots, CTLFLAG_RD,
|
|
|
|
&rule_slots, 0, "Number of used rule slots\n");
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, rule_version, CTLFLAG_RD,
|
|
|
|
&rule_version, 0, "Version number for API\n");
|
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
|
|
|
|
2004-08-21 20:19:19 +00:00
|
|
|
/*
|
2007-07-05 13:16:04 +00:00
|
|
|
* This is just used for logging purposes, eventually we would like to log
|
|
|
|
* much more then failed requests.
|
2004-08-21 20:19:19 +00:00
|
|
|
*/
|
2007-10-25 11:31:11 +00:00
|
|
|
static int ugidfw_logging;
|
2004-08-21 20:19:19 +00:00
|
|
|
SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, logging, CTLFLAG_RW,
|
2007-10-25 11:31:11 +00:00
|
|
|
&ugidfw_logging, 0, "Log failed authorization requests");
|
2004-08-21 20:19:19 +00:00
|
|
|
|
2004-08-21 20:15:08 +00:00
|
|
|
/*
|
2007-07-05 13:16:04 +00:00
|
|
|
* This tunable is here for compatibility. It will allow the user to switch
|
|
|
|
* between the new mode (first rule matches) and the old functionality (all
|
|
|
|
* rules match).
|
2004-08-21 20:15:08 +00:00
|
|
|
*/
|
2007-10-25 11:31:11 +00:00
|
|
|
static int ugidfw_firstmatch_enabled;
|
2004-08-21 20:15:08 +00:00
|
|
|
SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, firstmatch_enabled,
|
2007-10-25 11:31:11 +00:00
|
|
|
CTLFLAG_RW, &ugidfw_firstmatch_enabled, 1,
|
2007-07-05 13:16:04 +00:00
|
|
|
"Disable/enable match first rule functionality");
|
2004-08-21 20:15:08 +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
|
2007-10-25 11:31:11 +00:00
|
|
|
ugidfw_rule_valid(struct mac_bsdextended_rule *rule)
|
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
|
|
|
{
|
|
|
|
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if ((rule->mbr_subject.mbs_flags | MBS_ALL_FLAGS) != MBS_ALL_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
|
|
|
return (EINVAL);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if ((rule->mbr_subject.mbs_neg | MBS_ALL_FLAGS) != MBS_ALL_FLAGS)
|
|
|
|
return (EINVAL);
|
|
|
|
if ((rule->mbr_object.mbo_flags | MBO_ALL_FLAGS) != MBO_ALL_FLAGS)
|
|
|
|
return (EINVAL);
|
|
|
|
if ((rule->mbr_object.mbo_neg | MBO_ALL_FLAGS) != MBO_ALL_FLAGS)
|
|
|
|
return (EINVAL);
|
|
|
|
if ((rule->mbr_object.mbo_neg | MBO_TYPE_DEFINED) &&
|
|
|
|
(rule->mbr_object.mbo_type | MBO_ALL_TYPE) != MBO_ALL_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
|
|
|
return (EINVAL);
|
2004-10-21 11:19:02 +00:00
|
|
|
if ((rule->mbr_mode | MBI_ALLPERM) != MBI_ALLPERM)
|
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 (EINVAL);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
sysctl_rule(SYSCTL_HANDLER_ARGS)
|
|
|
|
{
|
|
|
|
struct mac_bsdextended_rule temprule, *ruleptr;
|
|
|
|
u_int namelen;
|
|
|
|
int error, index, *name;
|
|
|
|
|
2005-04-22 18:49:30 +00:00
|
|
|
error = 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
|
|
|
name = (int *)arg1;
|
|
|
|
namelen = arg2;
|
|
|
|
if (namelen != 1)
|
|
|
|
return (EINVAL);
|
|
|
|
index = name[0];
|
2006-01-15 01:02:20 +00:00
|
|
|
if (index >= MAC_BSDEXTENDED_MAXRULES)
|
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 (ENOENT);
|
|
|
|
|
2005-04-22 18:49:30 +00:00
|
|
|
ruleptr = NULL;
|
|
|
|
if (req->newptr && req->newlen != 0) {
|
|
|
|
error = SYSCTL_IN(req, &temprule, sizeof(temprule));
|
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
|
|
|
if (error)
|
|
|
|
return (error);
|
2008-10-23 20:26:15 +00:00
|
|
|
ruleptr = malloc(sizeof(*ruleptr), M_MACBSDEXTENDED,
|
|
|
|
M_WAITOK | M_ZERO);
|
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
|
|
|
mtx_lock(&ugidfw_mtx);
|
2005-04-22 18:49:30 +00:00
|
|
|
if (req->oldptr) {
|
|
|
|
if (index < 0 || index > rule_slots + 1) {
|
|
|
|
error = ENOENT;
|
|
|
|
goto out;
|
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
|
|
|
}
|
2005-04-22 18:49:30 +00:00
|
|
|
if (rules[index] == NULL) {
|
|
|
|
error = ENOENT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
temprule = *rules[index];
|
|
|
|
}
|
|
|
|
if (req->newptr && req->newlen == 0) {
|
|
|
|
KASSERT(ruleptr == NULL, ("sysctl_rule: ruleptr != NULL"));
|
|
|
|
ruleptr = rules[index];
|
|
|
|
if (ruleptr == NULL) {
|
|
|
|
error = ENOENT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
rule_count--;
|
|
|
|
rules[index] = NULL;
|
|
|
|
} else if (req->newptr) {
|
2007-10-25 11:31:11 +00:00
|
|
|
error = ugidfw_rule_valid(&temprule);
|
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
|
|
|
if (error)
|
2005-04-22 18:49:30 +00:00
|
|
|
goto out;
|
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
|
|
|
if (rules[index] == NULL) {
|
|
|
|
*ruleptr = temprule;
|
|
|
|
rules[index] = ruleptr;
|
2005-04-22 18:49:30 +00:00
|
|
|
ruleptr = NULL;
|
|
|
|
if (index + 1 > rule_slots)
|
|
|
|
rule_slots = index + 1;
|
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
|
|
|
rule_count++;
|
2007-07-05 13:16:04 +00:00
|
|
|
} else
|
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
|
|
|
*rules[index] = temprule;
|
|
|
|
}
|
2005-04-22 18:49:30 +00:00
|
|
|
out:
|
2007-10-25 11:31:11 +00:00
|
|
|
mtx_unlock(&ugidfw_mtx);
|
2005-04-22 18:49:30 +00:00
|
|
|
if (ruleptr != NULL)
|
2008-10-23 15:53:51 +00:00
|
|
|
free(ruleptr, M_MACBSDEXTENDED);
|
2005-07-28 13:55:12 +00:00
|
|
|
if (req->oldptr && error == 0)
|
2005-04-22 18:49:30 +00:00
|
|
|
error = SYSCTL_OUT(req, &temprule, sizeof(temprule));
|
2005-07-28 13:55:12 +00:00
|
|
|
return (error);
|
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-11-07 15:43:11 +00:00
|
|
|
static SYSCTL_NODE(_security_mac_bsdextended, OID_AUTO, rules,
|
2009-03-09 17:42:18 +00:00
|
|
|
CTLFLAG_MPSAFE | CTLFLAG_RW, sysctl_rule, "BSD extended MAC rules");
|
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
|
|
|
ugidfw_init(struct mac_policy_conf *mpc)
|
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
|
|
|
mtx_init(&ugidfw_mtx, "mac_bsdextended lock", NULL, MTX_DEF);
|
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
|
|
|
ugidfw_destroy(struct mac_policy_conf *mpc)
|
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-27 18:08:12 +00:00
|
|
|
int i;
|
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-27 18:08:12 +00:00
|
|
|
for (i = 0; i < MAC_BSDEXTENDED_MAXRULES; i++) {
|
|
|
|
if (rules[i] != NULL)
|
|
|
|
free(rules[i], M_MACBSDEXTENDED);
|
|
|
|
}
|
2007-10-25 11:31:11 +00:00
|
|
|
mtx_destroy(&ugidfw_mtx);
|
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
|
|
|
ugidfw_rulecheck(struct mac_bsdextended_rule *rule,
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
struct ucred *cred, struct vnode *vp, struct vattr *vap, int acc_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
|
|
|
{
|
2008-09-17 15:49:44 +00:00
|
|
|
int mac_granted, match, priv_granted;
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
int i;
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Is there a subject match?
|
|
|
|
*/
|
2007-10-25 11:31:11 +00:00
|
|
|
mtx_assert(&ugidfw_mtx, MA_OWNED);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_subject.mbs_flags & MBS_UID_DEFINED) {
|
|
|
|
match = ((cred->cr_uid <= rule->mbr_subject.mbs_uid_max &&
|
|
|
|
cred->cr_uid >= rule->mbr_subject.mbs_uid_min) ||
|
|
|
|
(cred->cr_ruid <= rule->mbr_subject.mbs_uid_max &&
|
|
|
|
cred->cr_ruid >= rule->mbr_subject.mbs_uid_min) ||
|
|
|
|
(cred->cr_svuid <= rule->mbr_subject.mbs_uid_max &&
|
|
|
|
cred->cr_svuid >= rule->mbr_subject.mbs_uid_min));
|
|
|
|
if (rule->mbr_subject.mbs_neg & MBS_UID_DEFINED)
|
|
|
|
match = !match;
|
|
|
|
if (!match)
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rule->mbr_subject.mbs_flags & MBS_GID_DEFINED) {
|
|
|
|
match = ((cred->cr_rgid <= rule->mbr_subject.mbs_gid_max &&
|
|
|
|
cred->cr_rgid >= rule->mbr_subject.mbs_gid_min) ||
|
|
|
|
(cred->cr_svgid <= rule->mbr_subject.mbs_gid_max &&
|
|
|
|
cred->cr_svgid >= rule->mbr_subject.mbs_gid_min));
|
|
|
|
if (!match) {
|
2007-07-05 13:16:04 +00:00
|
|
|
for (i = 0; i < cred->cr_ngroups; i++) {
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (cred->cr_groups[i]
|
|
|
|
<= rule->mbr_subject.mbs_gid_max &&
|
|
|
|
cred->cr_groups[i]
|
|
|
|
>= rule->mbr_subject.mbs_gid_min) {
|
|
|
|
match = 1;
|
|
|
|
break;
|
|
|
|
}
|
2007-07-05 13:16:04 +00:00
|
|
|
}
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
}
|
|
|
|
if (rule->mbr_subject.mbs_neg & MBS_GID_DEFINED)
|
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
|
|
|
match = !match;
|
|
|
|
if (!match)
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_subject.mbs_flags & MBS_PRISON_DEFINED) {
|
2009-05-27 14:11:23 +00:00
|
|
|
match =
|
|
|
|
(cred->cr_prison->pr_id == rule->mbr_subject.mbs_prison);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_subject.mbs_neg & MBS_PRISON_DEFINED)
|
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
|
|
|
match = !match;
|
|
|
|
if (!match)
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is there an object match?
|
|
|
|
*/
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_object.mbo_flags & MBO_UID_DEFINED) {
|
|
|
|
match = (vap->va_uid <= rule->mbr_object.mbo_uid_max &&
|
|
|
|
vap->va_uid >= rule->mbr_object.mbo_uid_min);
|
|
|
|
if (rule->mbr_object.mbo_neg & MBO_UID_DEFINED)
|
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
|
|
|
match = !match;
|
|
|
|
if (!match)
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_object.mbo_flags & MBO_GID_DEFINED) {
|
|
|
|
match = (vap->va_gid <= rule->mbr_object.mbo_gid_max &&
|
|
|
|
vap->va_gid >= rule->mbr_object.mbo_gid_min);
|
|
|
|
if (rule->mbr_object.mbo_neg & MBO_GID_DEFINED)
|
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
|
|
|
match = !match;
|
|
|
|
if (!match)
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_object.mbo_flags & MBO_FSID_DEFINED) {
|
|
|
|
match = (bcmp(&(vp->v_mount->mnt_stat.f_fsid),
|
|
|
|
&(rule->mbr_object.mbo_fsid),
|
|
|
|
sizeof(rule->mbr_object.mbo_fsid)) == 0);
|
|
|
|
if (rule->mbr_object.mbo_neg & MBO_FSID_DEFINED)
|
|
|
|
match = !match;
|
|
|
|
if (!match)
|
2007-07-05 13:16:04 +00:00
|
|
|
return (0);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (rule->mbr_object.mbo_flags & MBO_SUID) {
|
2008-09-10 13:16:41 +00:00
|
|
|
match = (vap->va_mode & S_ISUID);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_object.mbo_neg & MBO_SUID)
|
|
|
|
match = !match;
|
|
|
|
if (!match)
|
2007-07-05 13:16:04 +00:00
|
|
|
return (0);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (rule->mbr_object.mbo_flags & MBO_SGID) {
|
2008-09-10 13:16:41 +00:00
|
|
|
match = (vap->va_mode & S_ISGID);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
if (rule->mbr_object.mbo_neg & MBO_SGID)
|
|
|
|
match = !match;
|
|
|
|
if (!match)
|
2007-07-05 13:16:04 +00:00
|
|
|
return (0);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (rule->mbr_object.mbo_flags & MBO_UID_SUBJECT) {
|
|
|
|
match = (vap->va_uid == cred->cr_uid ||
|
|
|
|
vap->va_uid == cred->cr_ruid ||
|
|
|
|
vap->va_uid == cred->cr_svuid);
|
|
|
|
if (rule->mbr_object.mbo_neg & MBO_UID_SUBJECT)
|
|
|
|
match = !match;
|
|
|
|
if (!match)
|
2007-07-05 13:16:04 +00:00
|
|
|
return (0);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (rule->mbr_object.mbo_flags & MBO_GID_SUBJECT) {
|
|
|
|
match = (groupmember(vap->va_gid, cred) ||
|
|
|
|
vap->va_gid == cred->cr_rgid ||
|
|
|
|
vap->va_gid == cred->cr_svgid);
|
|
|
|
if (rule->mbr_object.mbo_neg & MBO_GID_SUBJECT)
|
|
|
|
match = !match;
|
|
|
|
if (!match)
|
2007-07-05 13:16:04 +00:00
|
|
|
return (0);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (rule->mbr_object.mbo_flags & MBO_TYPE_DEFINED) {
|
|
|
|
switch (vap->va_type) {
|
|
|
|
case VREG:
|
|
|
|
match = (rule->mbr_object.mbo_type & MBO_TYPE_REG);
|
|
|
|
break;
|
|
|
|
case VDIR:
|
|
|
|
match = (rule->mbr_object.mbo_type & MBO_TYPE_DIR);
|
|
|
|
break;
|
|
|
|
case VBLK:
|
|
|
|
match = (rule->mbr_object.mbo_type & MBO_TYPE_BLK);
|
|
|
|
break;
|
|
|
|
case VCHR:
|
|
|
|
match = (rule->mbr_object.mbo_type & MBO_TYPE_CHR);
|
|
|
|
break;
|
|
|
|
case VLNK:
|
|
|
|
match = (rule->mbr_object.mbo_type & MBO_TYPE_LNK);
|
|
|
|
break;
|
|
|
|
case VSOCK:
|
|
|
|
match = (rule->mbr_object.mbo_type & MBO_TYPE_SOCK);
|
|
|
|
break;
|
|
|
|
case VFIFO:
|
|
|
|
match = (rule->mbr_object.mbo_type & MBO_TYPE_FIFO);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
match = 0;
|
|
|
|
}
|
|
|
|
if (rule->mbr_object.mbo_neg & MBO_TYPE_DEFINED)
|
|
|
|
match = !match;
|
|
|
|
if (!match)
|
2007-07-05 13:16:04 +00:00
|
|
|
return (0);
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
}
|
|
|
|
|
2008-09-17 15:49:44 +00:00
|
|
|
/*
|
|
|
|
* MBI_APPEND should not be here as it should get converted to
|
|
|
|
* MBI_WRITE.
|
|
|
|
*/
|
|
|
|
priv_granted = 0;
|
|
|
|
mac_granted = rule->mbr_mode;
|
|
|
|
if ((acc_mode & MBI_ADMIN) && (mac_granted & MBI_ADMIN) == 0 &&
|
|
|
|
priv_check_cred(cred, PRIV_VFS_ADMIN, 0) == 0)
|
|
|
|
priv_granted |= MBI_ADMIN;
|
|
|
|
if ((acc_mode & MBI_EXEC) && (mac_granted & MBI_EXEC) == 0 &&
|
|
|
|
priv_check_cred(cred, (vap->va_type == VDIR) ? PRIV_VFS_LOOKUP :
|
|
|
|
PRIV_VFS_EXEC, 0) == 0)
|
|
|
|
priv_granted |= MBI_EXEC;
|
|
|
|
if ((acc_mode & MBI_READ) && (mac_granted & MBI_READ) == 0 &&
|
|
|
|
priv_check_cred(cred, PRIV_VFS_READ, 0) == 0)
|
|
|
|
priv_granted |= MBI_READ;
|
|
|
|
if ((acc_mode & MBI_STAT) && (mac_granted & MBI_STAT) == 0 &&
|
|
|
|
priv_check_cred(cred, PRIV_VFS_STAT, 0) == 0)
|
|
|
|
priv_granted |= MBI_STAT;
|
|
|
|
if ((acc_mode & MBI_WRITE) && (mac_granted & MBI_WRITE) == 0 &&
|
|
|
|
priv_check_cred(cred, PRIV_VFS_WRITE, 0) == 0)
|
|
|
|
priv_granted |= MBI_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
|
|
|
/*
|
|
|
|
* Is the access permitted?
|
|
|
|
*/
|
2008-09-17 15:49:44 +00:00
|
|
|
if (((mac_granted | priv_granted) & acc_mode) != acc_mode) {
|
2007-10-25 11:31:11 +00:00
|
|
|
if (ugidfw_logging)
|
2004-08-21 20:19:19 +00:00
|
|
|
log(LOG_AUTHPRIV, "mac_bsdextended: %d:%d request %d"
|
|
|
|
" on %d:%d failed. \n", cred->cr_ruid,
|
2007-07-05 13:16:04 +00:00
|
|
|
cred->cr_rgid, acc_mode, vap->va_uid,
|
|
|
|
vap->va_gid);
|
|
|
|
return (EACCES);
|
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
|
|
|
}
|
2005-04-22 18:49:30 +00:00
|
|
|
|
2004-08-21 20:15:08 +00:00
|
|
|
/*
|
2005-04-22 18:49:30 +00:00
|
|
|
* If the rule matched, permits access, and first match is enabled,
|
|
|
|
* return success.
|
2004-08-21 20:15:08 +00:00
|
|
|
*/
|
2007-10-25 11:31:11 +00:00
|
|
|
if (ugidfw_firstmatch_enabled)
|
2004-08-21 20:15:08 +00:00
|
|
|
return (EJUSTRETURN);
|
|
|
|
else
|
2007-07-05 13:16:04 +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
|
|
|
}
|
|
|
|
|
2008-10-27 12:09:15 +00:00
|
|
|
int
|
2007-10-25 11:31:11 +00:00
|
|
|
ugidfw_check(struct ucred *cred, struct vnode *vp, struct vattr *vap,
|
2002-10-30 17:56:57 +00:00
|
|
|
int acc_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
|
|
|
{
|
|
|
|
int error, i;
|
|
|
|
|
2007-02-20 10:21:27 +00:00
|
|
|
/*
|
|
|
|
* Since we do not separately handle append, map append to write.
|
|
|
|
*/
|
|
|
|
if (acc_mode & MBI_APPEND) {
|
|
|
|
acc_mode &= ~MBI_APPEND;
|
|
|
|
acc_mode |= MBI_WRITE;
|
|
|
|
}
|
2007-10-25 11:31:11 +00:00
|
|
|
mtx_lock(&ugidfw_mtx);
|
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
|
|
|
for (i = 0; i < rule_slots; i++) {
|
|
|
|
if (rules[i] == NULL)
|
|
|
|
continue;
|
2007-10-25 11:31:11 +00:00
|
|
|
error = ugidfw_rulecheck(rules[i], cred,
|
Add some new options to mac_bsdestended. We can now match on:
subject: ranges of uid, ranges of gid, jail id
objects: ranges of uid, ranges of gid, filesystem,
object is suid, object is sgid, object matches subject uid/gid
object type
We can also negate individual conditions. The ruleset language is
a superset of the previous language, so old rules should continue
to work.
These changes require a change to the API between libugidfw and the
mac_bsdextended module. Add a version number, so we can tell if
we're running mismatched versions.
Update man pages to reflect changes, add extra test cases to
test_ugidfw.c and add a shell script that checks that the the
module seems to do what we expect.
Suggestions from: rwatson, trhodes
Reviewed by: trhodes
MFC after: 2 months
2006-04-23 17:06:18 +00:00
|
|
|
vp, vap, acc_mode);
|
2004-08-21 20:15:08 +00:00
|
|
|
if (error == EJUSTRETURN)
|
|
|
|
break;
|
2005-04-22 18:49:30 +00:00
|
|
|
if (error) {
|
2007-10-25 11:31:11 +00:00
|
|
|
mtx_unlock(&ugidfw_mtx);
|
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 (error);
|
2005-04-22 18:49:30 +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
|
|
|
}
|
2007-10-25 11:31:11 +00:00
|
|
|
mtx_unlock(&ugidfw_mtx);
|
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);
|
|
|
|
}
|
|
|
|
|
2008-10-27 12:09:15 +00:00
|
|
|
int
|
2007-10-25 11:31:11 +00:00
|
|
|
ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode)
|
2003-03-25 01:14:03 +00:00
|
|
|
{
|
|
|
|
int error;
|
2006-03-04 20:47:19 +00:00
|
|
|
struct vattr vap;
|
2003-03-25 01:14:03 +00:00
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
if (!ugidfw_enabled)
|
2003-03-25 01:14:03 +00:00
|
|
|
return (0);
|
2008-08-28 15:23:18 +00:00
|
|
|
error = VOP_GETATTR(vp, &vap, cred);
|
2003-03-25 01:14:03 +00:00
|
|
|
if (error)
|
|
|
|
return (error);
|
2007-10-25 11:31:11 +00:00
|
|
|
return (ugidfw_check(cred, vp, &vap, acc_mode));
|
2006-03-04 20:47:19 +00:00
|
|
|
}
|
|
|
|
|
2008-10-30 10:13:53 +00:00
|
|
|
int
|
|
|
|
ugidfw_accmode2mbi(accmode_t accmode)
|
|
|
|
{
|
|
|
|
int mbi;
|
|
|
|
|
|
|
|
mbi = 0;
|
|
|
|
if (accmode & VEXEC)
|
|
|
|
mbi |= MBI_EXEC;
|
|
|
|
if (accmode & VWRITE)
|
|
|
|
mbi |= MBI_WRITE;
|
|
|
|
if (accmode & VREAD)
|
|
|
|
mbi |= MBI_READ;
|
2009-03-29 17:45:48 +00:00
|
|
|
if (accmode & VADMIN_PERMS)
|
2008-10-30 10:13:53 +00:00
|
|
|
mbi |= MBI_ADMIN;
|
2009-03-29 17:45:48 +00:00
|
|
|
if (accmode & VSTAT_PERMS)
|
2008-10-30 10:13:53 +00:00
|
|
|
mbi |= MBI_STAT;
|
|
|
|
if (accmode & VAPPEND)
|
|
|
|
mbi |= MBI_APPEND;
|
|
|
|
return (mbi);
|
|
|
|
}
|
|
|
|
|
2007-10-25 11:31:11 +00:00
|
|
|
static struct mac_policy_ops ugidfw_ops =
|
|
|
|
{
|
|
|
|
.mpo_destroy = ugidfw_destroy,
|
|
|
|
.mpo_init = ugidfw_init,
|
|
|
|
.mpo_system_check_acct = ugidfw_system_check_acct,
|
|
|
|
.mpo_system_check_auditctl = ugidfw_system_check_auditctl,
|
|
|
|
.mpo_system_check_swapon = ugidfw_system_check_swapon,
|
|
|
|
.mpo_vnode_check_access = ugidfw_vnode_check_access,
|
|
|
|
.mpo_vnode_check_chdir = ugidfw_vnode_check_chdir,
|
|
|
|
.mpo_vnode_check_chroot = ugidfw_vnode_check_chroot,
|
|
|
|
.mpo_vnode_check_create = ugidfw_check_create_vnode,
|
|
|
|
.mpo_vnode_check_deleteacl = ugidfw_vnode_check_deleteacl,
|
|
|
|
.mpo_vnode_check_deleteextattr = ugidfw_vnode_check_deleteextattr,
|
|
|
|
.mpo_vnode_check_exec = ugidfw_vnode_check_exec,
|
|
|
|
.mpo_vnode_check_getacl = ugidfw_vnode_check_getacl,
|
|
|
|
.mpo_vnode_check_getextattr = ugidfw_vnode_check_getextattr,
|
|
|
|
.mpo_vnode_check_link = ugidfw_vnode_check_link,
|
|
|
|
.mpo_vnode_check_listextattr = ugidfw_vnode_check_listextattr,
|
|
|
|
.mpo_vnode_check_lookup = ugidfw_vnode_check_lookup,
|
|
|
|
.mpo_vnode_check_open = ugidfw_vnode_check_open,
|
|
|
|
.mpo_vnode_check_readdir = ugidfw_vnode_check_readdir,
|
|
|
|
.mpo_vnode_check_readlink = ugidfw_vnode_check_readdlink,
|
|
|
|
.mpo_vnode_check_rename_from = ugidfw_vnode_check_rename_from,
|
|
|
|
.mpo_vnode_check_rename_to = ugidfw_vnode_check_rename_to,
|
|
|
|
.mpo_vnode_check_revoke = ugidfw_vnode_check_revoke,
|
|
|
|
.mpo_vnode_check_setacl = ugidfw_check_setacl_vnode,
|
|
|
|
.mpo_vnode_check_setextattr = ugidfw_vnode_check_setextattr,
|
|
|
|
.mpo_vnode_check_setflags = ugidfw_vnode_check_setflags,
|
|
|
|
.mpo_vnode_check_setmode = ugidfw_vnode_check_setmode,
|
|
|
|
.mpo_vnode_check_setowner = ugidfw_vnode_check_setowner,
|
|
|
|
.mpo_vnode_check_setutimes = ugidfw_vnode_check_setutimes,
|
|
|
|
.mpo_vnode_check_stat = ugidfw_vnode_check_stat,
|
|
|
|
.mpo_vnode_check_unlink = ugidfw_vnode_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-25 11:31:11 +00:00
|
|
|
MAC_POLICY_SET(&ugidfw_ops, mac_bsdextended, "TrustedBSD MAC/BSD Extended",
|
2009-01-10 10:58:41 +00:00
|
|
|
MPC_LOADTIME_FLAG_UNLOADOK, NULL);
|