Re: [RFC PATCH 0/2] Landlock signal scope and TIOCSIG

["Günther Noack" <gnoack3000@gmail.com>]

Hello Christopher!

On Sun, Sep 13, 2026 at 06:19:56PM -0400, Christopher Lusk wrote:
> Landlock documents LANDLOCK_SCOPE_SIGNAL as limiting signal delivery to
> processes in the same or a nested Landlock domain.  A retained PTY master
> can currently use TIOCSIG to deliver SIGINT, SIGQUIT, or SIGTSTP to an
> out-of-domain slave foreground process group because the privileged TTY
> signal path never reaches security_task_kill().
> 
> This RFC asks two questions before proposing a final interface.
> 
> First, should this be classified as SCOPE_SIGNAL under-enforcement, or as
> part of Landlock's documented inherited-TTY limitation?  The "Current
> limitations / IOCTL support" section says that IOCTL_DEV does not affect
> pre-existing descriptors, names TIOCSTI and TIOCLINUX, and recommends
> closing inherited TTY descriptors.  That text discusses the filesystem
> IOCTL_DEV right rather than SCOPE_SIGNAL, and unlike the two named ioctls,
> TIOCSIG is not CAP_SYS_ADMIN-gated.  Commit 4b80320ca7ed fixed the same
> effect-level class for SIGIO rather than treating the retained signal
> source as exempt.
> 
> Second, if this is a bug, should TIOCSIG use the existing task_kill hook as
> patch 1 demonstrates, or should it gain a dedicated TTY-signal hook which
> Landlock can implement without changing other LSM policies?  The prototype
> is atomic with process-group delivery and behaviorally narrow to TIOCSIG,
> but calling task_kill means SELinux, Smack, AppArmor, BPF LSM programs, and
> future implementations also mediate this operation.  The series does not
> claim that cross-LSM policy change is settled.

Thank you for bringing this up; I was not aware of this code path and
researched it a bit.

Let me try to paraphrase the issue to make sure I understand:

1. A process creates a PTY device and acquires the PTY master FD.
2. The process then restricts itself into a signal-scoped Landlock domain.
3. Processes outside of the domain are attached to the terminal
4. Through the PTY master FD, the master process emulates a terminal
   to the attached processes.  One of the commands it can issue is
   TIOCSIG, allowing the PTY master process to send SIGINT ("Ctrl-C"),
   SIGQUIT ("Ctrl-\") or SIGTSTP ("Ctrl-Z") to TTY-attached processes,
   which may live *outside* the Landlock domain.  (source:
   pty_signal() in drivers/tty/pty.c)

TIOCSIG was introduced in 2010 in Linux [1] and in 1989 in BSD (quoted
in the Linux patch).  According to the patch, it is only required in a
special terminal mode where the mapping of signals is disabled.

In more normal operation modes, the terminal interprets these keyboard
shortcuts sent as characters.  This is implemented in
n_tty_receive_char_special() when you write() the characters '\x03'
(Ctrl-C), '\x1c' (Ctrl-\) or '\x1a' (Ctrl-Z) to the PTY master FD.
(Your proposed patch does not fix this either, even though it sends
the same signals.)

Additionally, PTYs can send:

* SIGWINCH (when you do ioctl(TIOCSWINSZ) on the master FD)
* SIGHUP and SIGCONT

[1] https://lore.kernel.org/all/E1OR73h-0004VN-JE@lirone.symas.net/


In summary:

* Sending signals to attached processes is a very normal way how PTYs
  interact with the attached processes, and TIOCSIG is not the only
  cause for it.
* Processes are attached to a PTY because they were started on that
  PTY or they have voluntarily attached to it.

With these two points in mind, I am leaning towards treating access to
the PTY master FD as a "capability" whose acquisition can already be
adequately restricted with existing Landlock controls.  Like
socketpair(), which Landlock also don't restrict, the creation of a
new PTY always returns a new master and client side TTY FD and it
feels to me more effective to control who attaches to these than to
control the TTY-internal communication protocols itself.

Maybe the way to think about this is to say that it is the *TTY
driver* which is sending these signals in response to the PTY master
FD receiving a TIOCSIG or having a Ctrl-C written to it.  This is
similar to a SSH or Telnet daemon which can also trigger signals for
the attached processes on the other end of the terminal by sending the
right commands over the wire, and I also don't see an issue with that,
because in the same way as here, the client programs have voluntarily
attached to the TTY. 🤔

Does that seem reasonable?  I am happy to be corrected if this
analysis is wrong.

If you agree, I think the best path forward might be to document it
more clearly that TTY interactions are not part of the SCOPE_SIGNAL
guarantees.

–Günther

> The demonstrated generic impact is low:
> CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L = 3.8.  Scope is changed
> because the effect reaches a process outside the sandbox authority, but
> the primitive is limited to three job-control signals and no independent
> integrity impact has been reproduced.
> 
> Patch 1 is the behaviorally validated proof-of-concept fix.  Patch 2 is a
> minimal regression test; further test polishing should follow the chosen
> interface direction.
> 
> Validation used the same userspace image against the affected and patched
> kernels.  Across three boots per image and 32 iterations per cell:
> 
>   affected: 96/96 cross-domain TIOCSIG deliveries
>   patched:  96/96 cross-domain TIOCSIG denials
>   both:     96/96 unconfined deliveries
>             96/96 same-domain deliveries
>             96/96 scoped direct-kill denials
> 
> The regression test separately fails on the affected image and passes on
> the patched image, with exactly one TAP test executed in each run.
> 
> No external report or patch has been sent before this RFC.  Guidance on
> both classification and hook direction would be appreciated.
> 
> Christopher Lusk (2):
>   tty: mediate TIOCSIG through task_kill LSM hooks
>   selftests/landlock: cover TIOCSIG signal scoping
> 
>  drivers/tty/pty.c                             |   8 +-
>  include/linux/sched/signal.h                  |   1 +
>  kernel/signal.c                               |  30 +++-
>  .../selftests/landlock/scoped_signal_test.c   | 142 ++++++++++++++++++
>  4 files changed, 177 insertions(+), 4 deletions(-)
> 
> -- 
> 2.55.0