aboutsummaryrefslogtreecommitdiffstats
path: root/share/man
diff options
context:
space:
mode:
authorOlivier Certner <olce@FreeBSD.org>2025-09-27 11:56:33 +0200
committerOlivier Certner <olce@FreeBSD.org>2025-10-02 18:57:19 +0200
commit89958992b6189eaecbb3d036fce90fcecb005cb2 (patch)
tree700e0878dc489f6b4c2244e099a73d366e4cafdd /share/man
parent09ae06b1b224517b792a799620cf6038d7b52893 (diff)
MAC/do: Check executable path from the current jail's root
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)
Diffstat (limited to 'share/man')
0 files changed, 0 insertions, 0 deletions