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

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/ (local)


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