Re: Proposal: Enabling unprivileged chroot by default

On Tue, 5 Aug 2025 at 16:12, Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
>
> FYI: mac_do(4) needs to take NO_NEW_PRIVS into account. Patch in
> HardenedBSD:
> https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/ef712e6e4701c8c943d7e8a1c9b08e0ab93cb51a

Yeah, as a consequence of my investigation into the work done to
support unprivileged chroot I brought this up with olce@. Based on the
name of the existing flag (i.e., P2_NO_NEW_PRIVS or
PROC_NO_NEW_PRIVS_CTL) it's a reasonable assumption that it would
prevent mac_do from changing uid/gid. But the documentation reveals a
more limited scope:

   Allows one to ignore the set-user-ID and set-
   group-ID bits on the program images activated by
   execve(2) in the specified process and its future
   descendants.

Anyhow olce@ is AFK for a bit, but should comment on this later on.

> Without that patch, an overly permissive mac_do(4) policy could result
> in privilege escalation in the unprivileged chroot:
>
> ==== BEGIN LOG ====
> hbsd-current-01[shawn]:/home/shawn $ sysctl security.bsd.unprivileged_chroot security.mac.do.rules
> security.bsd.unprivileged_chroot: 1
> security.mac.do.rules: uid=1001:uid=0

You've given uid 1001 the ability to set its user ID to root,
independent of the chroot. In particular, you can observe the same
behaviour with `proccontrol -m nonewprivs -s enable /bin/sh`. So I
think your referenced change is likely reasonable, but also somewhat
orthogonal to unprivileged chroot. The descriptions for
P2_NO_NEW_PRIVS in proc.h and PROC_NO_NEW_PRIVS_CTL in procctl(2)
would also need to be updated though.