This reduces the size of a trigger entry from 24 bytes to 16 (or from 12 bytes to 8 on 32-bit) with no additional complexity. MFC after: 1 week Sponsored by: Klara, Inc. Reviewed by: kevans, emaste Differential Revision: https://reviews.freebsd.org/D57464 (cherry picked from commit 77e894cb09affe828f4bc81b8e4751a7e22860de)
It was previously not possible to poll() or select() on the trigger device, which made implementing proper signal handling in auditd difficult. MFC after: 1 week Sponsored by: Klara, Inc. Reviewed by: kevans, markj Differential Revision: https://reviews.freebsd.org/D57457 (cherry picked from commit 0620c99d278b6a2fd6fe995f5bb365158e04ad7c)
The specificgid functionality has historically allowed only a single group to be exempt, but in practice one might want a few services to be exempt for reasons. From a security perspective, we probably don't want to encourage unrelated users to be grouped together solely for this purpose, as that creates one point of shared access that could be used for nefarious purposes. Normalize the group list as we do cr_groups to allow for linear matching rather than quadratic, we just need to account for the differences in FreeBSD 15.0+ where cr_groups is entirely supplementary groups vs. earlier versions, where cr_groups[0] is the egid and the rest is sorted. Reviewed by: csjp, des (earlier version) Sponsored by: Klara, Inc. (cherry picked from commit b675ff8eedc9ac93cdf1cfe33185b7a1a027df37)
MFC after: 1 week (cherry picked from commit 12ac59a0d1f6ae2065e8e2cb36c53c00771bfc74) (cherry picked from commit 2e5a55c7af56022fb38e3d528b2e8b1257de891d)
MFC after: 1 week (cherry picked from commit 32c1e940e07c48ab80427efd3d6ff2091407d577) (cherry picked from commit c48a31e3508555606b4399d33000cf60fe98e207)
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 (cherry picked from commit 134d00bd2c910cc7cc21c11fba093ff82bbb9344)
Use `if_t` instead of `struct ifnet *`, and if_name() accessor. Sponsored by: Juniper Networks, Inc. (cherry picked from commit b820820ece099a73511d7daec407d78f38185a9b)
A future change may split cr_gid out of cr_groups[0] so that there's a cleaner separation between the supplemental groups and the effective group. Do the mechanical conversion where we can, and drop some comments where we need further work because some assumptions about cr_gid == cr_groups[0] have been made. This should not be a functional change, but downstreams and other out-of-tree code are advised to investigate their usage of cr_groups sooner rather than later, as a future change will render assumptions about these two being equivalent harmful. Reviewed by: asomers, kib, olce Differential Revision: https://reviews.freebsd.org/D51153 (cherry picked from commit 46c07316f90628a82dd461376ccff64a81254325) This was MFCed to ease application of further commits. NOTE: Downstreams and out-of-tree code targeting stable/14 need not do the switch, as splitting 'cr_gid' out of cr_groups[], as we did in stable/15 (and is in 15.0), is not on the agenda for stable/14. Comments that were added temporarily for stable/15, alluding to the future split, have been removed.
- s/Authenticateion/Authentication/ (cherry picked from commit 63af953e09ccd11f2f5b4d83b10cc231f691de46)
Contrary to my initial belief, vn_fullpath() does return a vnode's path from the current chroot, and not from the global root (which would have been a bug also, but without security consequences). This enables a "confused deputy"-like scenario where a chroot(2) can change which executable can be authorized by MAC/do, which is even more problematic for unprivileged chroot(2). This was found by re-examining the code following two close events: 1. Shawn Webb sent a mail to freebsd-hackers@ on 08/05 saying that in HardenedBSD they had added a check on P2_NO_NEW_PRIVS (in mac_do_priv_grant()), which I responded to on 08/20 saying that P2_NO_NEW_PRIVS was not necessary for mac_do(4), with a correct reasoning but based on the wrong above-mentioned assumption about vn_fullpath(). 2. I reviewed some code by Kushagra Srivastava (GSoC 2025 student working on mac_do(4)/mdo(1)) adding the ability to specify which executables can spawn processes that mac_do(4) may decide to authorize (others are simply ignored), which currently is hardcoded to '/usr/bin/mdo'. MFC after: 3 days Event: EuroBSDCon 2025 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52758 (cherry picked from commit 9f269a0a771aff4f0a735211907a52c52fc0661b)