d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
5e85b65e97
freebsd-nq/sys/security/mac_bsdextended/mac_bsdextended.c

773 lines
20 KiB
C
Raw Normal View History

Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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 locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
* Copyright (c) 2005 Tom Rhodes
More unnecessary include reduction.
2007-02-23 14:39:04 +00:00
* Copyright (c) 1999-2002, 2007 Robert N. M. Watson
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
* Copyright (c) 2001-2005 Networks Associates Technology, 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.
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
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
*
License and wording updates: NAI has authorized the removal of clause three from their BSD-style license. Also, s/NAI Labs/Network Associates Laboratories/.
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
*
* 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$
*/
Minor white space synchronization and line wrapping.
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.
* "BSD Extended" MAC policy, allowing the administrator to impose
* mandatory rules regarding users and some system objects.
*/
#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>
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
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>
More unnecessary include reduction.
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>
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
#include <sys/mutex.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>
Allow mac_bsdextended(4) to log failed attempts to syslog's AUTHPRIV facility. This is disabled by default but may be turned on by using the mac_bsdextended_logging sysctl. Reviewed by: re (jhb) Approved by: re (jhb)
2004-08-21 20:19:19 +00:00
#include <sys/syslog.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
Move src/sys/sys/mac_policy.h, the kernel interface between the MAC Framework and security modules, to src/sys/security/mac/mac_policy.h, completing the removal of kernel-only MAC Framework include files from src/sys/sys. Update the MAC Framework and MAC policy modules. Delete the old mac_policy.h. Third party policy modules will need similar updating. Obtained from: TrustedBSD Project
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>
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
static struct mtx mac_bsdextended_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
SYSCTL_DECL(_security_mac);
SYSCTL_NODE(_security_mac, OID_AUTO, bsdextended, CTLFLAG_RW, 0,
"TrustedBSD extended BSD MAC policy controls");
static int mac_bsdextended_enabled = 1;
SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, enabled, CTLFLAG_RW,
&mac_bsdextended_enabled, 0, "Enforce extended BSD policy");
TUNABLE_INT("security.mac.bsdextended.enabled", &mac_bsdextended_enabled);
MALLOC_DEFINE(M_MACBSDEXTENDED, "mac_bsdextended", "BSD Extended MAC rule");
#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
Allow mac_bsdextended(4) to log failed attempts to syslog's AUTHPRIV facility. This is disabled by default but may be turned on by using the mac_bsdextended_logging sysctl. Reviewed by: re (jhb) Approved by: re (jhb)
2004-08-21 20:19:19 +00:00
/*
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
* This is just used for logging purposes, eventually we would like
Allow mac_bsdextended(4) to log failed attempts to syslog's AUTHPRIV facility. This is disabled by default but may be turned on by using the mac_bsdextended_logging sysctl. Reviewed by: re (jhb) Approved by: re (jhb)
2004-08-21 20:19:19 +00:00
* to log much more then failed requests.
*/
static int mac_bsdextended_logging;
SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, logging, CTLFLAG_RW,
&mac_bsdextended_logging, 0, "Log failed authorization requests");
Give the mac_bsdextended(4) policy the ability to match and apply on a first rule only in place of all rules match. This is similar to how ipfw(8) works. Provide a sysctl, mac_bsdextended_firstmatch_enabled, to enable this feature. Reviewed by: re (jhb) Aprroved by: re (jhb)
2004-08-21 20:15:08 +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).
*/
static int
mac_bsdextended_firstmatch_enabled;
SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, firstmatch_enabled,
Remove the debugging tunable, it was not being used. Enable first match by default.[1] We should: rwatson [1]
2004-09-10 15:14:50 +00:00
CTLFLAG_RW, &mac_bsdextended_firstmatch_enabled, 1,
Give the mac_bsdextended(4) policy the ability to match and apply on a first rule only in place of all rules match. This is similar to how ipfw(8) works. Provide a sysctl, mac_bsdextended_firstmatch_enabled, to enable this feature. Reviewed by: re (jhb) Aprroved by: re (jhb)
2004-08-21 20:15:08 +00:00
"Disable/enable match first rule functionality");
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_rule_valid(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
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);
Modify mac_bsdextended policy so that it defines its own vnode access right bits rather than piggy-backing on the V* rights defined in vnode.h. The mac_bsdextended bits are given the same values as the V* bits to make the new kernel module binary compatible with the old version of libugidfw that uses V* bits. This avoids leaking kernel API/ABI to user management tools, and in particular should remove the need for libugidfw to include vnode.h. Requested by: phk
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;
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
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;
/* printf("bsdextended sysctl handler (namelen %d)\n", namelen); */
if (namelen != 1)
return (EINVAL);
index = name[0];
Fix potential overrun of static stack allocated array which stores the rules. If an array is N elements large, we can only access elements 0..(N-1). MFC after: 1 week Found with: Coverity Prevent(tm)
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);
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
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);
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
MALLOC(ruleptr, struct mac_bsdextended_rule *,
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
}
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
mtx_lock(&mac_bsdextended_mtx);
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
}
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
if (rules[index] == NULL) {
error = ENOENT;
goto out;
}
temprule = *rules[index];
}
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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 locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
if (req->newptr && req->newlen == 0) {
/* printf("deletion\n"); */
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) {
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
error = mac_bsdextended_rule_valid(&temprule);
if (error)
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
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) {
/* printf("addition\n"); */
*ruleptr = temprule;
rules[index] = ruleptr;
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
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++;
} else {
/* printf("replacement\n"); */
*rules[index] = temprule;
}
}
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
out:
mtx_unlock(&mac_bsdextended_mtx);
if (ruleptr != NULL)
FREE(ruleptr, M_MACBSDEXTENDED);
If a "hole" opens up in the ruleset (i.e.: remove 5), do not return unknown error. Instead, just return error. Submitted by: avatar Tested by: trhodes
2005-07-28 13:55:12 +00:00
if (req->oldptr && error == 0)
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
error = SYSCTL_OUT(req, &temprule, sizeof(temprule));
If a "hole" opens up in the ruleset (i.e.: remove 5), do not return unknown error. Instead, just return error. Submitted by: avatar Tested by: trhodes
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
}
SYSCTL_NODE(_security_mac_bsdextended, OID_AUTO, rules,
CTLFLAG_RW, sysctl_rule, "BSD extended MAC rules");
static void
mac_bsdextended_init(struct mac_policy_conf *mpc)
{
/* Initialize ruleset lock. */
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
mtx_init(&mac_bsdextended_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
/* Register dynamic sysctl's for rules. */
}
static void
mac_bsdextended_destroy(struct mac_policy_conf *mpc)
{
/* Destroy ruleset lock. */
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
mtx_destroy(&mac_bsdextended_mtx);
/* Tear down sysctls. */
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_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
{
int 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
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?
*/
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
mtx_assert(&mac_bsdextended_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;
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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 (!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) {
for (i = 0; i < cred->cr_ngroups; i++)
if (cred->cr_groups[i]
<= rule->mbr_subject.mbs_gid_max &&
cred->cr_groups[i]
>= rule->mbr_subject.mbs_gid_min) {
match = 1;
break;
}
}
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) {
match = (cred->cr_prison != NULL &&
cred->cr_prison->pr_id == rule->mbr_subject.mbs_prison);
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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_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);
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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_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);
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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_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)
return 0;
}
if (rule->mbr_object.mbo_flags & MBO_SUID) {
match = (vap->va_mode & VSUID);
if (rule->mbr_object.mbo_neg & MBO_SUID)
match = !match;
if (!match)
return 0;
}
if (rule->mbr_object.mbo_flags & MBO_SGID) {
match = (vap->va_mode & VSGID);
if (rule->mbr_object.mbo_neg & MBO_SGID)
match = !match;
if (!match)
return 0;
}
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)
return 0;
}
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)
return 0;
}
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)
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
/*
* Is the access permitted?
*/
if ((rule->mbr_mode & acc_mode) != acc_mode) {
Allow mac_bsdextended(4) to log failed attempts to syslog's AUTHPRIV facility. This is disabled by default but may be turned on by using the mac_bsdextended_logging sysctl. Reviewed by: re (jhb) Approved by: re (jhb)
2004-08-21 20:19:19 +00:00
if (mac_bsdextended_logging)
log(LOG_AUTHPRIV, "mac_bsdextended: %d:%d request %d"
" on %d:%d failed. \n", cred->cr_ruid,
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
cred->cr_rgid, acc_mode, vap->va_uid, vap->va_gid);
Allow mac_bsdextended(4) to log failed attempts to syslog's AUTHPRIV facility. This is disabled by default but may be turned on by using the mac_bsdextended_logging sysctl. Reviewed by: re (jhb) Approved by: re (jhb)
2004-08-21 20:19:19 +00:00
return (EACCES); /* Matching rule denies access */
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
Give the mac_bsdextended(4) policy the ability to match and apply on a first rule only in place of all rules match. This is similar to how ipfw(8) works. Provide a sysctl, mac_bsdextended_firstmatch_enabled, to enable this feature. Reviewed by: re (jhb) Aprroved by: re (jhb)
2004-08-21 20:15:08 +00:00
/*
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
* If the rule matched, permits access, and first match is enabled,
* return success.
Give the mac_bsdextended(4) policy the ability to match and apply on a first rule only in place of all rules match. This is similar to how ipfw(8) works. Provide a sysctl, mac_bsdextended_firstmatch_enabled, to enable this feature. Reviewed by: re (jhb) Aprroved by: re (jhb)
2004-08-21 20:15:08 +00:00
*/
if (mac_bsdextended_firstmatch_enabled)
return (EJUSTRETURN);
else
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
}
static int
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
mac_bsdextended_check(struct ucred *cred, struct vnode *vp, struct vattr *vap,
While 'mode_t' seemed like a good idea for the access mode argument for MAC access() and open() checks, the argument actually has an int type where it becomes available. Switch to using 'int' for the mode argument throughout the MAC Framework and policy modules. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
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;
Sweep kernel replacing suser(9) calls with priv(9) calls, assigning specific privilege names to a broad range of privileges. These may require some future tweaking. Sponsored by: nCircle Network Security, Inc. Obtained from: TrustedBSD Project Discussed on: arch@ Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, Alex Lyashkov <umka at sevcity dot net>, Skip Ford <skip dot ford at verizon dot net>, Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:42:10 +00:00
/*
* XXXRW: More specific privilege selection needed?
*/
Allow an effective uid of root to bypass mac_bsdextended rules; the MAC Framework can restrict the root user, but this policy is not intended to support that. Stylish Swiss footwear provided for: trhodes
2004-07-23 01:53:28 +00:00
if (suser_cred(cred, 0) == 0)
return (0);
Move mapping of MBI_APPEND to MBI_WRITE from inside the rule loop in mac_bsdextended_check() to before the loop, as it needs to happen only once. MFC after: 1 week
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;
}
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
mtx_lock(&mac_bsdextended_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;
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
error = mac_bsdextended_rulecheck(rules[i], cred,
vp, vap, acc_mode);
Give the mac_bsdextended(4) policy the ability to match and apply on a first rule only in place of all rules match. This is similar to how ipfw(8) works. Provide a sysctl, mac_bsdextended_firstmatch_enabled, to enable this feature. Reviewed by: re (jhb) Aprroved by: re (jhb)
2004-08-21 20:15:08 +00:00
if (error == EJUSTRETURN)
break;
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
if (error) {
mtx_unlock(&mac_bsdextended_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);
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
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
}
Add locking support to mac_bsdextended: - Introduce a global mutex, mac_bsdextended_mtx, to protect the rule array and hold this mutex over use and modification of the rule array and rules. - Re-order and clean up sysctl_rule so that copyin/copyout/update happen in the right order (suggested by: jhb done by rwatson).
2005-04-22 18:49:30 +00:00
mtx_unlock(&mac_bsdextended_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);
}
Expand scope of the BSD extended "file system firewall" policy to include a new entry point available for enforcement: mac_bsdextended_check_system_swapon() - Apply extended access control checks to the file target of swap. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-03-25 01:14:03 +00:00
static int
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
mac_bsdextended_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode)
Expand scope of the BSD extended "file system firewall" policy to include a new entry point available for enforcement: mac_bsdextended_check_system_swapon() - Apply extended access control checks to the file target of swap. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-03-25 01:14:03 +00:00
{
int error;
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
struct vattr vap;
Expand scope of the BSD extended "file system firewall" policy to include a new entry point available for enforcement: mac_bsdextended_check_system_swapon() - Apply extended access control checks to the file target of swap. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-03-25 01:14:03 +00:00
if (!mac_bsdextended_enabled)
return (0);
error = VOP_GETATTR(vp, &vap, cred, curthread);
if (error)
return (error);
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +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
return (mac_bsdextended_check(cred, vp, &vap, acc_mode));
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
}
static int
mac_bsdextended_check_system_swapon(struct ucred *cred, struct vnode *vp,
struct label *label)
{
return (mac_bsdextended_check_vp(cred, vp, MBI_WRITE));
Expand scope of the BSD extended "file system firewall" policy to include a new entry point available for enforcement: mac_bsdextended_check_system_swapon() - Apply extended access control checks to the file target of swap. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-03-25 01:14:03 +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
mac_bsdextended_check_vnode_access(struct ucred *cred, struct vnode *vp,
While 'mode_t' seemed like a good idea for the access mode argument for MAC access() and open() checks, the argument actually has an int type where it becomes available. Switch to using 'int' for the mode argument throughout the MAC Framework and policy modules. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 17:56:57 +00:00
struct label *label, 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
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, 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
}
static int
mac_bsdextended_check_vnode_chdir(struct ucred *cred, struct vnode *dvp,
struct label *dlabel)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, dvp, MBI_EXEC));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
static int
mac_bsdextended_check_vnode_chroot(struct ucred *cred, struct vnode *dvp,
struct label *dlabel)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, dvp, MBI_EXEC));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
static int
mac_bsdextended_check_create_vnode(struct ucred *cred, struct vnode *dvp,
struct label *dlabel, struct componentname *cnp, struct vattr *vap)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, dvp, 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
}
static int
mac_bsdextended_check_vnode_delete(struct ucred *cred, struct vnode *dvp,
struct label *dlabel, struct vnode *vp, struct label *label,
struct componentname *cnp)
{
int error;
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
error = mac_bsdextended_check_vp(cred, dvp, 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
if (error)
return (error);
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, 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
}
static int
mac_bsdextended_check_vnode_deleteacl(struct ucred *cred, struct vnode *vp,
struct label *label, acl_type_t type)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_ADMIN));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
Implementations of mpo_check_vnode_deleteextattr() and mpo_check_vnode_listextattr() for Biba, MLS, and BSD Extended. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-08-21 14:34:54 +00:00
static int
mac_bsdextended_check_vnode_deleteextattr(struct ucred *cred, struct vnode *vp,
struct label *label, int attrnamespace, const char *name)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_WRITE));
Implementations of mpo_check_vnode_deleteextattr() and mpo_check_vnode_listextattr() for Biba, MLS, and BSD Extended. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-08-21 14:34:54 +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
mac_bsdextended_check_vnode_exec(struct ucred *cred, struct vnode *vp,
Update MAC modules for changes in arguments for exec MAC policy entry points to include an explicit execlabel. Approved by: re Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-11-08 18:04:36 +00:00
struct label *label, struct image_params *imgp,
struct label *execlabel)
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_READ|MBI_EXEC));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
static int
mac_bsdextended_check_vnode_getacl(struct ucred *cred, struct vnode *vp,
struct label *label, acl_type_t type)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_STAT));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
static int
mac_bsdextended_check_vnode_getextattr(struct ucred *cred, struct vnode *vp,
struct label *label, int attrnamespace, const char *name, struct uio *uio)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_READ));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
Merge implementation of mpo_check_vnode_link() for various appropriate file-system aware MAC policies. Sync to MAC tree. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 18:25:48 +00:00
static int
mac_bsdextended_check_vnode_link(struct ucred *cred, struct vnode *dvp,
struct label *dlabel, struct vnode *vp, struct label *label,
struct componentname *cnp)
{
int error;
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
error = mac_bsdextended_check_vp(cred, dvp, MBI_WRITE);
Various minor type, prototype tweaks -- clean up cruft due to lack of type checking on entry points (to be introduced shortly). Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 18:10:46 +00:00
if (error)
return (error);
Merge implementation of mpo_check_vnode_link() for various appropriate file-system aware MAC policies. Sync to MAC tree. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 18:25:48 +00:00
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
error = mac_bsdextended_check_vp(cred, vp, MBI_WRITE);
Merge implementation of mpo_check_vnode_link() for various appropriate file-system aware MAC policies. Sync to MAC tree. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-05 18:25:48 +00:00
if (error)
return (error);
return (0);
}
Implementations of mpo_check_vnode_deleteextattr() and mpo_check_vnode_listextattr() for Biba, MLS, and BSD Extended. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-08-21 14:34:54 +00:00
static int
mac_bsdextended_check_vnode_listextattr(struct ucred *cred, struct vnode *vp,
struct label *label, int attrnamespace)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_READ));
Implementations of mpo_check_vnode_deleteextattr() and mpo_check_vnode_listextattr() for Biba, MLS, and BSD Extended. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-08-21 14:34:54 +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
mac_bsdextended_check_vnode_lookup(struct ucred *cred, struct vnode *dvp,
struct label *dlabel, struct componentname *cnp)
{
Remove trailing whitespace.
2003-07-05 01:24:36 +00:00
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, dvp, MBI_EXEC));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
static int
mac_bsdextended_check_vnode_open(struct ucred *cred, struct vnode *vp,
While 'mode_t' seemed like a good idea for the access mode argument for MAC access() and open() checks, the argument actually has an int type where it becomes available. Switch to using 'int' for the mode argument throughout the MAC Framework and policy modules. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 17:56:57 +00:00
struct label *filelabel, 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
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, 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
}
static int
mac_bsdextended_check_vnode_readdir(struct ucred *cred, struct vnode *dvp,
struct label *dlabel)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, dvp, MBI_READ));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_check_vnode_readdlink(struct ucred *cred, struct vnode *vp,
struct label *label)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_READ));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_check_vnode_rename_from(struct ucred *cred, struct vnode *dvp,
struct label *dlabel, struct vnode *vp, struct label *label,
struct componentname *cnp)
{
int error;
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
error = mac_bsdextended_check_vp(cred, dvp, 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
if (error)
return (error);
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
error = mac_bsdextended_check_vp(cred, vp, 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
return (error);
}
static int
mac_bsdextended_check_vnode_rename_to(struct ucred *cred, struct vnode *dvp,
struct label *dlabel, struct vnode *vp, struct label *label, int samedir,
struct componentname *cnp)
{
int error;
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
error = mac_bsdextended_check_vp(cred, dvp, 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
if (error)
return (error);
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
if (vp != NULL)
error = mac_bsdextended_check_vp(cred, vp, 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
return (error);
}
static int
mac_bsdextended_check_vnode_revoke(struct ucred *cred, struct vnode *vp,
struct label *label)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_ADMIN));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_check_setacl_vnode(struct ucred *cred, struct vnode *vp,
struct label *label, acl_type_t type, struct acl *acl)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_ADMIN));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_check_vnode_setextattr(struct ucred *cred, struct vnode *vp,
struct label *label, int attrnamespace, const char *name, struct uio *uio)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, 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
}
static int
mac_bsdextended_check_vnode_setflags(struct ucred *cred, struct vnode *vp,
struct label *label, u_long flags)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_ADMIN));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_check_vnode_setmode(struct ucred *cred, struct vnode *vp,
struct label *label, mode_t mode)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_ADMIN));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_check_vnode_setowner(struct ucred *cred, struct vnode *vp,
struct label *label, uid_t uid, gid_t gid)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_ADMIN));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
mac_bsdextended_check_vnode_setutimes(struct ucred *cred, struct vnode *vp,
struct label *label, struct timespec atime, struct timespec utime)
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(cred, vp, MBI_ADMIN));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels 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
Pass active_cred and file_cred into the MAC framework explicitly for mac_check_vnode_{poll,read,stat,write}(). Pass in fp->f_cred when calling these checks with a struct file available. Otherwise, pass NOCRED. All currently MAC policies use active_cred, but could now offer the cached credential semantic used for the base system security model. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-08-19 19:04:53 +00:00
mac_bsdextended_check_vnode_stat(struct ucred *active_cred,
struct ucred *file_cred, struct vnode *vp, struct label *label)
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
{
Create a mac_bsdextended_check_vp function that takes a cred, a vnode and a mode and checks if a given access mode is permitted. This centralises the mac_bsdextended_enabled check and the GETATTR calls and makes the implementation of the mac policy methods simple. This should make it easier for us to match vnodes on more complex attributes than just uid and gid in the future, but for now there should be no functional change. Approved/Reviewed by: rwatson, trhodes MFC after: 1 month
2006-03-04 20:47:19 +00:00
return (mac_bsdextended_check_vp(active_cred, vp, MBI_STAT));
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
}
Move to C99 sparse structure initialization for the mac_policy_ops structure definition, rather than using an operation vector we translate into the structure. Originally, we used a vector for two reasons: (1) We wanted to define the structure sparsely, which wasn't supported by the C compiler for structures. For a policy with five entry points, you don't want to have to stick in a few hundred NULL function pointers. (2) We thought it would improve ABI compatibility allowing modules to work with kernels that had a superset of the entry points defined in the module, even if the kernel had changed its entry point set. Both of these no longer apply: (1) C99 gives us a way to sparsely define a static structure. (2) The ABI problems existed anyway, due to enumeration numbers, argument changes, and semantic mismatches. Since the going rule for FreeBSD is that you really need your modules to pretty closely match your kernel, it's not worth the complexity. This submit eliminates the operation vector, dynamic allocation of the operation structure, copying of the vector to the structure, and redoes the vectors in each policy to direct structure definitions. One enourmous benefit of this change is that we now get decent type checking on policy entry point implementation arguments. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 18:48:51 +00:00
static struct mac_policy_ops mac_bsdextended_ops =
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
{
Move to C99 sparse structure initialization for the mac_policy_ops structure definition, rather than using an operation vector we translate into the structure. Originally, we used a vector for two reasons: (1) We wanted to define the structure sparsely, which wasn't supported by the C compiler for structures. For a policy with five entry points, you don't want to have to stick in a few hundred NULL function pointers. (2) We thought it would improve ABI compatibility allowing modules to work with kernels that had a superset of the entry points defined in the module, even if the kernel had changed its entry point set. Both of these no longer apply: (1) C99 gives us a way to sparsely define a static structure. (2) The ABI problems existed anyway, due to enumeration numbers, argument changes, and semantic mismatches. Since the going rule for FreeBSD is that you really need your modules to pretty closely match your kernel, it's not worth the complexity. This submit eliminates the operation vector, dynamic allocation of the operation structure, copying of the vector to the structure, and redoes the vectors in each policy to direct structure definitions. One enourmous benefit of this change is that we now get decent type checking on policy entry point implementation arguments. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 18:48:51 +00:00
.mpo_destroy = mac_bsdextended_destroy,
.mpo_init = mac_bsdextended_init,
Expand scope of the BSD extended "file system firewall" policy to include a new entry point available for enforcement: mac_bsdextended_check_system_swapon() - Apply extended access control checks to the file target of swap. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-03-25 01:14:03 +00:00
.mpo_check_system_swapon = mac_bsdextended_check_system_swapon,
Move to C99 sparse structure initialization for the mac_policy_ops structure definition, rather than using an operation vector we translate into the structure. Originally, we used a vector for two reasons: (1) We wanted to define the structure sparsely, which wasn't supported by the C compiler for structures. For a policy with five entry points, you don't want to have to stick in a few hundred NULL function pointers. (2) We thought it would improve ABI compatibility allowing modules to work with kernels that had a superset of the entry points defined in the module, even if the kernel had changed its entry point set. Both of these no longer apply: (1) C99 gives us a way to sparsely define a static structure. (2) The ABI problems existed anyway, due to enumeration numbers, argument changes, and semantic mismatches. Since the going rule for FreeBSD is that you really need your modules to pretty closely match your kernel, it's not worth the complexity. This submit eliminates the operation vector, dynamic allocation of the operation structure, copying of the vector to the structure, and redoes the vectors in each policy to direct structure definitions. One enourmous benefit of this change is that we now get decent type checking on policy entry point implementation arguments. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 18:48:51 +00:00
.mpo_check_vnode_access = mac_bsdextended_check_vnode_access,
.mpo_check_vnode_chdir = mac_bsdextended_check_vnode_chdir,
.mpo_check_vnode_chroot = mac_bsdextended_check_vnode_chroot,
.mpo_check_vnode_create = mac_bsdextended_check_create_vnode,
.mpo_check_vnode_delete = mac_bsdextended_check_vnode_delete,
.mpo_check_vnode_deleteacl = mac_bsdextended_check_vnode_deleteacl,
Implementations of mpo_check_vnode_deleteextattr() and mpo_check_vnode_listextattr() for Biba, MLS, and BSD Extended. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-08-21 14:34:54 +00:00
.mpo_check_vnode_deleteextattr = mac_bsdextended_check_vnode_deleteextattr,
Move to C99 sparse structure initialization for the mac_policy_ops structure definition, rather than using an operation vector we translate into the structure. Originally, we used a vector for two reasons: (1) We wanted to define the structure sparsely, which wasn't supported by the C compiler for structures. For a policy with five entry points, you don't want to have to stick in a few hundred NULL function pointers. (2) We thought it would improve ABI compatibility allowing modules to work with kernels that had a superset of the entry points defined in the module, even if the kernel had changed its entry point set. Both of these no longer apply: (1) C99 gives us a way to sparsely define a static structure. (2) The ABI problems existed anyway, due to enumeration numbers, argument changes, and semantic mismatches. Since the going rule for FreeBSD is that you really need your modules to pretty closely match your kernel, it's not worth the complexity. This submit eliminates the operation vector, dynamic allocation of the operation structure, copying of the vector to the structure, and redoes the vectors in each policy to direct structure definitions. One enourmous benefit of this change is that we now get decent type checking on policy entry point implementation arguments. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 18:48:51 +00:00
.mpo_check_vnode_exec = mac_bsdextended_check_vnode_exec,
.mpo_check_vnode_getacl = mac_bsdextended_check_vnode_getacl,
.mpo_check_vnode_getextattr = mac_bsdextended_check_vnode_getextattr,
.mpo_check_vnode_link = mac_bsdextended_check_vnode_link,
Implementations of mpo_check_vnode_deleteextattr() and mpo_check_vnode_listextattr() for Biba, MLS, and BSD Extended. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-08-21 14:34:54 +00:00
.mpo_check_vnode_listextattr = mac_bsdextended_check_vnode_listextattr,
Move to C99 sparse structure initialization for the mac_policy_ops structure definition, rather than using an operation vector we translate into the structure. Originally, we used a vector for two reasons: (1) We wanted to define the structure sparsely, which wasn't supported by the C compiler for structures. For a policy with five entry points, you don't want to have to stick in a few hundred NULL function pointers. (2) We thought it would improve ABI compatibility allowing modules to work with kernels that had a superset of the entry points defined in the module, even if the kernel had changed its entry point set. Both of these no longer apply: (1) C99 gives us a way to sparsely define a static structure. (2) The ABI problems existed anyway, due to enumeration numbers, argument changes, and semantic mismatches. Since the going rule for FreeBSD is that you really need your modules to pretty closely match your kernel, it's not worth the complexity. This submit eliminates the operation vector, dynamic allocation of the operation structure, copying of the vector to the structure, and redoes the vectors in each policy to direct structure definitions. One enourmous benefit of this change is that we now get decent type checking on policy entry point implementation arguments. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2002-10-30 18:48:51 +00:00
.mpo_check_vnode_lookup = mac_bsdextended_check_vnode_lookup,
.mpo_check_vnode_open = mac_bsdextended_check_vnode_open,
.mpo_check_vnode_readdir = mac_bsdextended_check_vnode_readdir,
.mpo_check_vnode_readlink = mac_bsdextended_check_vnode_readdlink,
.mpo_check_vnode_rename_from = mac_bsdextended_check_vnode_rename_from,
.mpo_check_vnode_rename_to = mac_bsdextended_check_vnode_rename_to,
.mpo_check_vnode_revoke = mac_bsdextended_check_vnode_revoke,
.mpo_check_vnode_setacl = mac_bsdextended_check_setacl_vnode,
.mpo_check_vnode_setextattr = mac_bsdextended_check_vnode_setextattr,
.mpo_check_vnode_setflags = mac_bsdextended_check_vnode_setflags,
.mpo_check_vnode_setmode = mac_bsdextended_check_vnode_setmode,
.mpo_check_vnode_setowner = mac_bsdextended_check_vnode_setowner,
.mpo_check_vnode_setutimes = mac_bsdextended_check_vnode_setutimes,
.mpo_check_vnode_stat = mac_bsdextended_check_vnode_stat,
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
};
Trim "trustedbsd_" from the front of the policy module "short names"; the vendor is only included in the long name currently, reducing verbosity when modules are registered and unregistered. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
2003-03-27 19:26:39 +00:00
MAC_POLICY_SET(&mac_bsdextended_ops, mac_bsdextended,
Introduce support for Mandatory Access Control and extensible kernel access control. Provide implementations of some sample operating system security policy extensions. These are not yet hooked up to the build as other infrastructure is still being committed. Most of these work fairly well and are in daily use in our development and (limited) production environments. Some are not yet in their final form, and a number of the labeled policies waste a lot of kernel memory and will be fixed over the next month or so to be more conservative. They do give good examples of the flexibility of the MAC framework for implementing a variety of security policies. mac_biba: Implementation of fixed-label Biba integrity policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned integrity levels, and information flow is controlled based on a read-up, write-down policy. Currently, purely hierarchal. mac_bsdextended: Implementation of a "file system firewall", which allows the administrator to specify a series of rules limiting access by users and groups to objects owned by other users and groups. This policy is unlabeled, relying on existing system security labeling (file permissions/ownership, process credentials). mac_ifoff: Secure interface silencing. Special-purpose module to limit inappropriate out-going network traffic for silent monitoring scenarios. Prevents the various network stacks from generating any output despite an interface being live for reception. mac_mls: Implementation of fixed-label Multi-Level Security confidentiality policy, similar to those found in a number of commercial trusted operating systems. All subjects and objects are assigned confidentiality levels, and information flow is controlled based on a write-up, read-down policy. Currently, purely hiearchal, although non-hierarchal support is in the works. mac_none: Policy module implementing all MAC policy entry points with empty stubs. A good place to start if you want all the prototypes types in for you, and don't mind a bit of pruning. Can be loaded, but has no access control impact. Useful also for performance measurements. mac_seeotheruids: Policy module implementing a security service similar to security.bsd.seeotheruids, only a slightly more detailed policy involving exceptions for members of specific groups, etc. This policy is unlabeled, relying on existing system security labeling (process credentials). mac_test: Policy module implementing basic sanity tests for label handling. Attempts to ensure that labels are not freed multiple times, etc, etc. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
2002-07-31 18:07:45 +00:00
"TrustedBSD MAC/BSD Extended", MPC_LOADTIME_FLAG_UNLOADOK, NULL);
Reference in New Issue Copy Permalink