mirror of
https://github.com/freebsd/freebsd-src.git
synced 2026-10-31 12:56:10 +01:00
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 9f269a0a77)