Date: Thu, 7 Aug 2025 23:36:34 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: 8a5ceebece03 - main - kern: disallow user scheduling/debugging/signalling of jailed procs Message-ID: <9fa64be6-988d-4d04-ada2-91a5b627ad56@FreeBSD.org> In-Reply-To: <202508080427.5784RI42005179@gitrepo.freebsd.org> References: <202508080427.5784RI42005179@gitrepo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9fa64be6-988d-4d04-ada2-91a5b627ad56>