FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-02-14T04:20:52Z 2026-02-14T04:20:52Z Kyle Evans kevans@FreeBSD.org 2026-02-14T04:19:18Z urn:sha1:99e138f20a9bad8276e9ebbb1e155daadf201272 The MAC framework provides a lot of useful functionality that can be configured per-jail without requiring the use of labels. Having another entry point that we invoke just for general prison cleanup rather than freeing the label is useful to allow a module that can otherwise work off of a series of MAC entry points + sysctls for configuration to free its per-jail configuration without having to bring in osd(9). One such example in the wild is HardenedBSD's secadm, but some of my own personal use had wanted it as well- it was simply overlooked in the final version because my first policy made more sense with labels. On that note, it's expected that prison_cleanup and prison_destroy_label will effectively be mutually exclusive -- the former only used when a label isn't needed, the latter when it is. Note that prison_cleanup isn't perfectly symmetrical w.r.t. prison_created: the latter takes a label as well, because it's called later in jail setup and a better point for propagation than when the label is created. As discussed with olce@, we may want to later revisit the notion that struct labels get passed around explicitly along with the referenced object and consider stripping them from all entry points in favor of an object -> label accessor or something. __FreeBSD_version bumped to force a rebuild of MAC policies. Reviewed by: olce Differential Revision: https://reviews.freebsd.org/D54833 2026-01-16T00:23:39Z Kyle Evans kevans@FreeBSD.org 2025-10-26T01:57:33Z urn:sha1:31c2728185d1705634ff84c93936a4c91a651b22 We'll still add an old-fashioned jail param to configure jail MAC labels, but for testing it's really easy to grab a jaildesc and use that. Reviewed by: jamie, olce Differential Revision: https://reviews.freebsd.org/D53956 2026-01-16T00:23:39Z Kyle Evans kevans@FreeBSD.org 2025-10-21T03:42:50Z urn:sha1:8254b0dec02b376dae259cd2043513842d827bd8 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 2026-01-16T00:23:39Z Kyle Evans kevans@FreeBSD.org 2025-10-04T03:46:03Z urn:sha1:11d6ea47f06a38f66536b173e85ddf2674da6aff Reviewed by: olce Differential Revision: https://reviews.freebsd.org/D53953