FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-04-23T18:47:09Z 2026-04-23T18:47:09Z Kyle Evans kevans@FreeBSD.org 2026-04-23T18:47:09Z urn:sha1:7982985bdf58d2ee90d10d5710b28f5c3cd48bb1 Reviewed by: bapt Differential Revision: https://reviews.freebsd.org/D55703 2026-04-23T18:47:09Z Kyle Evans kevans@FreeBSD.org 2026-04-23T18:47:09Z urn:sha1:28b0084af332c34af3bdc60354bb7feea8ceeaa3 mpc_name and mpc_fullname are string literals in correct usage, so they should really be const instead. mpc_ops aren't typically const, but the framework shouldn't be doing anything to clobber it; thus, good to constify it as a reminder. Switch to using a slightly more semantically correct `void **` in the fastpath bits while we're here, since we only do arithmetic on the outer layer of pointer and compare the inner to a pointer-typed (NULL). Reviewed by: bapt Differential Revision: https://reviews.freebsd.org/D55702 2026-04-23T18:47:09Z Kyle Evans kevans@FreeBSD.org 2026-04-23T18:47:09Z urn:sha1:0faa88f26c239b19ea543309f2c70384438eae73 The unmount check is straightforward and only really needs the struct mount and flags used, in case a MAC policy wants to reject force-unmounts or do special handling for FSID-based unmounts. The mount check offers as much information as I think might be of interest to a MAC policy: the vnode to be mounted on, vfsconf, and applicable mount options. XNU also has a later version that just takes a struct mount for everything that VFS_MOUNT() has to offer, but my draft policy doesn't need any of that. It also doesn't really need the unmount check, but it seems reasonable to add it while I'm here. The update check similarly passes the flags/options for the operation, along with the struct mount and label. Reviewed by: kib, olce Differential Revision: https://reviews.freebsd.org/D55601 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