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-20T02:57:42Z Kyle Evans kevans@FreeBSD.org 2026-01-20T02:57:42Z urn:sha1:3f3b53e68a7b2f9319ee1fdac82b511c9f9f22d7 Nobody else's mac.conf(5) has any entries for jails, so they get a trivial ENOENT and we fail before we can fetch any jail parameters. Most notably, this breaks `jls -s` / `jls -n` if you do not have any loaded policy that applies jail labels. Add an entry that works for everyone, and hardcode that as an ENOENT fallback in libjail to provide a smoother transition. This is probably not harmful to leave in long-term, since mac.conf(5) will override it. This unearthed one additional issue, in that mac_get_prison() in the MAC framework handled the no-label-policies bit wrong. We don't want to break jail utilities enumerating jail parameters automatically, so we must ingest the label in all cases -- we can still use it as a small optimization to avoid trying to copy out any label. We will break things if a non-optional element is specified in the copied in label, but that's expected. The APIs dedicated to jaildescs remain unphased, since they won't be used in the same way. Fixes: db3b39f063d9f05 ("libjail: extend struct handlers [...]") Fixes: bd55cbb50c58876 ("kern: add a mac.label jail parameter") Reported by: jlduran (on behalf of Jenkins) Reviewed by: jlduran Differential Revision: https://reviews.freebsd.org/D54786 2026-01-16T00:23:39Z Kyle Evans kevans@FreeBSD.org 2025-11-07T04:19:31Z urn:sha1:bd55cbb50c58876281f925cfd91961544f0153ad Have it take a `struct mac` and we'll paper over the difference for jail(8)/jls(8) in libjail(3). The mac_syscalls.h model is taken from mac_set_proc_*() that were previously done. Reviewed by: olce Differential Revision: https://reviews.freebsd.org/D53958 2026-01-16T00:23:39Z Kyle Evans kevans@FreeBSD.org 2025-11-07T04:15:45Z urn:sha1:626fe12e2801a06c59eaa056ecf11f573e30ecbb A future commit to the area will further our jail integration and add a use for this: the struct mac itself was already copied in as part of vfs_buildopts(), so we only need to copyin the strings. We add an explicit flag argument because the jail operation will need to do it while holding the prison lock. Reviewed by: olce Differential Revision: https://reviews.freebsd.org/D53957 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 2026-01-11T17:12:49Z urn:sha1:92b7366e438d8422a9e453aed02ca365da25bf62 A last-minute change to the jail MAC entry points in D53954 is going to pass the jail_[gs]et(2) flags to mac_prison_check_[gs]et() so that a policy can, e.g., reject or allow a change if the intent is to immediately attach, or disallow some fetching of dying jails. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D54658 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 2025-12-04T19:52:59Z John Baldwin jhb@FreeBSD.org 2025-12-04T19:52:59Z urn:sha1:61ffc1bf8c4288c18d0ef86877e2558fa7ae3e13 Reported by: markj Reviewed by: olce Differential Revision: https://reviews.freebsd.org/D54052 2025-11-24T15:47:20Z John Baldwin jhb@FreeBSD.org 2025-11-24T15:47:20Z urn:sha1:134d00bd2c910cc7cc21c11fba093ff82bbb9344 This removes mac_label_copyin32() as mac_label_copyin() can now handle both native and 32-bit struct mac objects. Reviewed by: olce, brooks Obtained from: CheriBSD Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D53755