Re: git: 8a5ceebece03 - main - kern: disallow user scheduling/debugging/signalling of jailed procs

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 <kevans@FreeBSD.org>
> AuthorDate: 2025-08-08 04:26:51 +0000
> Commit:     Kyle Evans <kevans@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