kern: mac: add various jail MAC hooks

This adds the following hooks:
- mpo_prison_check_attach: check for subject capability to attach to
a given jail
- mpo_prison_check_create: check for subj

kern: mac: add various jail MAC hooks

This adds the following hooks:
- mpo_prison_check_attach: check for subject capability to attach to
a given jail
- mpo_prison_check_create: check for subject capability to create a
jail with the given option set
- mpo_prison_check_get: check for subject capability to fetch the
given parameters for a jail
- mpo_prison_check_set: check for subject capability to set the
given parameters for a jail
- mpo_prison_check_remove: check for subject capability to remove the
jail

check_get wouldn't typically be a privileged operation, but is included
to give MAC policies a wider range of capabilities at a relatively low
cost. We also add two more for the purpose of label propagation:
- mpo_prison_created: surface the creation of a jail so that one can
do propagation to, e.g., the root vnode or any mounts
- mpo_prison_attached: attach an existing process to the jail so that
one can propagate the jail label to the process, as appropriate.

It is unclear if this is preferred vs. having separate associate entry
points for each type of object we might associate. That would split
these up like so:

- prison_created -> prison_associate_vnode
- prison_attached -> prison_associate_proc

Some sample policy ideas that should be feasible to implement with this
set of hooks, in case it's inspiring:
- mac_bomb: policy that allows a poudriere user to construct jails
without root privilege, given a restricted set of jail parameters.
Slap a warning label on it.
- mac_capsule: policy that realizes the capsule idea that I pitched[0]
on -jail@ to create jails that are effectively immutable once
sealed, using these hooks and a label.

Perhaps a silly idea, but a downstream could consider a scenario where
it can implement special jail enumeration using a MAC policy and a
cooperating application that specifies non-parameter options to filter
the results.

[0] https://lists.freebsd.org/archives/freebsd-jail/2025-September/000550.html

Reviewed by: olce (slightly earlier version)
Differential Revision: https://reviews.freebsd.org/D53954

show more ...

kern: mac: add a MAC label to struct prison

Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D53953

MAC: Rename mac_cred_create_swapper to mac_cred_create_kproc0

Reported by: markj
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D54052

mac: Remove uses of DEBUG_VFS_LOCKS

We can assert that a vnode lock is held whenever INVARIANTS is
configured.

Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org

mac: Remove uses of DEBUG_VFS_LOCKS

We can assert that a vnode lock is held whenever INVARIANTS is
configured.

Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D51698

show more ...

New setcred() system call and associated MAC hooks

This new system call allows to set all necessary credentials of
a process in one go: Effective, real and saved UIDs, effective, real and
saved GIDs

New setcred() system call and associated MAC hooks

This new system call allows to set all necessary credentials of
a process in one go: Effective, real and saved UIDs, effective, real and
saved GIDs, supplementary groups and the MAC label. Its advantage over
standard credential-setting system calls (such as setuid(), seteuid(),
etc.) is that it enables MAC modules, such as MAC/do, to restrict the
set of credentials some process may gain in a fine-grained manner.

Traditionally, credential changes rely on setuid binaries that call
multiple credential system calls and in a specific order (setuid() must
be last, so as to remain root for all other credential-setting calls,
which would otherwise fail with insufficient privileges). This
piecewise approach causes the process to transiently hold credentials
that are neither the original nor the final ones. For the kernel to
enforce that only certain transitions of credentials are allowed, either
these possibly non-compliant transient states have to disappear (by
setting all relevant attributes in one go), or the kernel must delay
setting or checking the new credentials. Delaying setting credentials
could be done, e.g., by having some mode where the standard system calls
contribute to building new credentials but without committing them. It
could be started and ended by a special system call. Delaying checking
could mean that, e.g., the kernel only verifies the credentials
transition at the next non-credential-setting system call (we just
mention this possibility for completeness, but are certainly not
endorsing it).

We chose the simpler approach of a new system call, as we don't expect
the set of credentials one can set to change often. It has the
advantages that the traditional system calls' code doesn't have to be
changed and that we can establish a special MAC protocol for it, by
having some cleanup function called just before returning (this is
a requirement for MAC/do), without disturbing the existing ones.

The mac_cred_check_setcred() hook is passed the flags received by
setcred() (including the version) and both the old and new kernel's
'struct ucred' instead of 'struct setcred' as this should simplify
evolving existing hooks as the 'struct setcred' structure evolves. The
mac_cred_setcred_enter() and mac_cred_setcred_exit() hooks are always
called by pairs around potential calls to mac_cred_check_setcred().
They allow MAC modules to allocate/free data they may need in their
mac_cred_check_setcred() hook, as the latter is called under the current
process' lock, rendering sleepable allocations impossible. MAC/do is
going to leverage these in a subsequent commit. A scheme where
mac_cred_check_setcred() could return ERESTART was considered but is
incompatible with proper composition of MAC modules.

While here, add missing includes and declarations for standalone
inclusion of <sys/ucred.h> both from kernel and userspace (for the
latter, it has been working thanks to <bsm/audit.h> already including
<sys/types.h>).

Reviewed by: brooks
Approved by: markj (mentor)
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47618

show more ...

Remove gratuitous copyouts of unchanged struct mac.

The get operations change the data pointed to by the structure, but do
not update the contents of the struct.

Mark the struct mac arguments of ma

Remove gratuitous copyouts of unchanged struct mac.

The get operations change the data pointed to by the structure, but do
not update the contents of the struct.

Mark the struct mac arguments of mac_[gs]etsockopt_*label() and
mac_check_structmac_consistent() const to prevent this from changing
in the future.

Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14488

show more ...

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

mac_ipacl: new MAC policy module to limit jail/vnet IP configuration

The mac_ipacl policy module enables fine-grained control over IP address
configuration within VNET jails from the base system.
It

mac_ipacl: new MAC policy module to limit jail/vnet IP configuration

The mac_ipacl policy module enables fine-grained control over IP address
configuration within VNET jails from the base system.
It allows the root user to define rules governing IP addresses for
jails and their interfaces using the sysctl interface.

Requested by: multiple
Sponsored by: Google, Inc. (GSoC 2019)
MFC after: 2 months
Reviewed by: bz, dch (both earlier versions)
Differential Revision: https://reviews.freebsd.org/D20967

show more ...

kdb: Modify securelevel policy

Currently, sysctls which enable KDB in some way are flagged with
CTLFLAG_SECURE, meaning that you can't modify them if securelevel > 0.
This is so that KDB cannot be u

kdb: Modify securelevel policy

Currently, sysctls which enable KDB in some way are flagged with
CTLFLAG_SECURE, meaning that you can't modify them if securelevel > 0.
This is so that KDB cannot be used to lower a running system's
securelevel, see commit 3d7618d8bf0b7. However, the newer mac_ddb(4)
restricts DDB operations which could be abused to lower securelevel
while retaining some ability to gather useful debugging information.

To enable the use of KDB (specifically, DDB) on systems with a raised
securelevel, change the KDB sysctl policy: rather than relying on
CTLFLAG_SECURE, add a check of the current securelevel to kdb_trap().
If the securelevel is raised, only pass control to the backend if MAC
specifically grants access; otherwise simply check to see if mac_ddb
vetoes the request, as before.

Add a new secure sysctl, debug.kdb.enter_securelevel, to override this
behaviour. That is, the sysctl lets one enter a KDB backend even with a
raised securelevel, so long as it is set before the securelevel is
raised.

Reviewed by: mhorne, stevek
MFC after: 1 month
Sponsored by: Juniper Networks
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D37122

show more ...

mac: cheaper check for mac_pipe_check_read

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D36082

mac: s/0/false/ in macros denoting probe enablement

No functional changes.

mac: kdb/ddb framework hooks

Add three simple hooks to the debugger allowing for a loaded MAC policy
to intervene if desired:
1. Before invoking the kdb backend
2. Before ddb command registration

mac: kdb/ddb framework hooks

Add three simple hooks to the debugger allowing for a loaded MAC policy
to intervene if desired:
1. Before invoking the kdb backend
2. Before ddb command registration
3. Before ddb command execution

We extend struct db_command with a private pointer and two flag bits
reserved for policy use.

Reviewed by: markj
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35370

show more ...

mac: cheaper check for ifnet_create_mbuf and ifnet_check_transmit

Sponsored by: Rubicon Communications, LLC ("Netgate")

mac: cheaper check for mac_vnode_check_readlink

pipe: allow for lockless pipe_stat

pipes get stated all thet time and this avoidably contributed to contention.
The pipe lock is only held to accomodate MAC and to check the type.

Since normally th

pipe: allow for lockless pipe_stat

pipes get stated all thet time and this avoidably contributed to contention.
The pipe lock is only held to accomodate MAC and to check the type.

Since normally there is no probe for pipe stat depessimize this by having the
flag.

The pipe_state field gets modified with locks held all the time and it's not
feasible to convert them to use atomic store. Move the type flag away to a
separate variable as a simple cleanup and to provide stable field to read.
Use short for both fields to avoid growing the struct.

While here short-circuit MAC for pipe_poll as well.

show more ...

mac_framework.h: fix build with DEBUG_VFS_LOCKS and !MAC

I have such a custom kernel configuration and its build failed with:
linking kernel.full
ld: error: undefined symbol: mac_vnode_assert_locked

mac_framework.h: fix build with DEBUG_VFS_LOCKS and !MAC

I have such a custom kernel configuration and its build failed with:
linking kernel.full
ld: error: undefined symbol: mac_vnode_assert_locked
>>> referenced by mac_framework.h:556 (/usr/devel/git/apu2c4/sys/security/mac/mac_framework.h:556)
>>> tmpfs_vnops.o:(mac_vnode_check_stat)
>>> referenced by mac_framework.h:556 (/usr/devel/git/apu2c4/sys/security/mac/mac_framework.h:556)
>>> vfs_default.o:(mac_vnode_check_stat)
>>> referenced by mac_framework.h:556 (/usr/devel/git/apu2c4/sys/security/mac/mac_framework.h:556)
>>> ufs_vnops.o:(mac_vnode_check_stat)

show more ...

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Merge ^/head r363739 through r363986.

mac: even up all entry points to the same scheme

- use a macro for checking whether the site is enabled
- expand it to 0 if mac is not compiled in to begin with

vfs: add a cheaper entry for mac_vnode_check_access

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Merge ^/head r363583 through r363738.

Fix tinderbox build after r363714

vfs: elide MAC-induced locking on rename if there are no relevant hoooks

vfs: add the infrastructure for lockless lookup

Reviewed by: kib
Tested by: pho (in a patchset)
Differential Revision: https://reviews.freebsd.org/D25577