On 8/7/25 23:27, Kyle Evans wrote:
The branch main has been updated by kevans:
URL:
https://cgit.FreeBSD.org/src/commit/?id=8a5ceebece0311bc41180b3ca0ce7237def1e253
commit 8a5ceebece0311bc41180b3ca0ce7237def1e253
Author: Kyle Evans <kev...@freebsd.org>
AuthorDate: 2025-08-08 04:26:51 +0000
Commit: Kyle Evans <kev...@freebsd.org>
CommitDate: 2025-08-08 04:26:51 +0000
kern: disallow user scheduling/debugging/signalling of jailed procs
Currently, jails are generally ignored when determining whether the
current process/thread can take action upon another, except to determine
if the target's jail is somewhere in the source's hierarchy. Notably,
uid 1001 in a jail (including prison0) can take action upon a process
run by uid 1001 inside of a subordinate jail by default.
While this could be considered a feature at times, it is a scenario
that really should be deliberately crafted; there is no guarantee that
uid 1001 in the parent jail is at all related to uid 1001 in a
subordinate.
This changes introduces three new privileges that grant a process
this kind of insight into other jails:
- PRIV_DEBUG_DIFFJAIL
- PRIV_SCHED_DIFFJAIl
- PRIV_SIGNAL_DIFFJAIL
These can be granted independently or in conjunction with the
accompanying *_DIFFCRED privileges, i.e.:
- PRIV_DEBUG_DIFFCRED alone will let uid 1001 debug uid 1002, but
PRIV_DEBUG_DIFFJAIL is additionally needed to let it debug uid 1002
in a jail.
- PRIV_DEBUG_DIFFJAIL alone will let uid 1001 debug uid 1001 in a jail,
but will not allow it to debug uid 1002 in a jail.
Note that security.bsd.see_jail_proc can be used for similar effects,
but does not prevent a user from learning the pid of a jailed process
with matching creds and signalling it or rescheduling it (e.g., cpuset).
Debugging is restricted by visibility in all cases, so that one is less
of a concern.
>
Sorry, I didn't rewrite this part of the message enough. As of olce@'s
more recent changes in the area, visibility does in-fact restrict these
actions, but it's useful to provide this additional level of control so
that one doesn't have to apply that level of hammer to restrict
interactions.
This change adds a new jail(8) parameter for the parent to indicate on
a per-jail basis if its users are open to being tampered with by the
parent's unprivileged users: allow.unprivileged_parent_tampering. This
is disabled by default, but may be enabled to bypass the new priv(9)
checks in some scenarios where the functionality is useful. For
development setups that involve regularly debugging jailed processes
from outside the jail, consider adding a default
`allow.unprivileged_parent_tampering;` to your /etc/jail.conf.
This may get MFC'd in the future with the default flipped to preserve
pre-existing behavior but allow opt-in for the new position sooner.
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D51645
