kern: disallow user scheduling/debugging/signalling of jailed procsHEADmain

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.

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

0 files changed, 0 insertions, 0 deletions