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:
- 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().
- 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