From: Christopher Lusk <clusk@northecho.dev>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: "Günther Noack" <gnoack@google.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Shuah Khan" <shuah@kernel.org>,
"Tahera Fahimi" <fahimitahera@gmail.com>,
"Paul Moore" <paul@paul-moore.com>,
"Casey Schaufler" <casey@schaufler-ca.com>,
"John Johansen" <john.johansen@canonical.com>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: [RFC PATCH 0/2] Landlock signal scope and TIOCSIG
Date: Sun, 13 Sep 2026 18:19:56 -0400 [thread overview]
Message-ID: <20260913221958.839429-1-clusk@northecho.dev> (raw)
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.
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
next reply other threads:[~2026-09-13 22:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 22:19 Christopher Lusk [this message]
2026-09-13 22:19 ` [RFC PATCH 1/2] tty: mediate TIOCSIG through task_kill LSM hooks Christopher Lusk
2026-09-13 23:49 ` Christopher Lusk
2026-09-13 22:19 ` [RFC PATCH 2/2] selftests/landlock: cover TIOCSIG signal scoping Christopher Lusk
2026-09-14 9:34 ` [RFC PATCH 0/2] Landlock signal scope and TIOCSIG Günther Noack
2026-09-14 13:40 ` Christopher Lusk
2026-09-14 17:13 ` Günther Noack
2026-09-14 18:09 ` [PATCH] docs: landlock: clarify TTY signal scoping Christopher Lusk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260913221958.839429-1-clusk@northecho.dev \
--to=clusk@northecho.dev \
--cc=casey@schaufler-ca.com \
--cc=fahimitahera@gmail.com \
--cc=gnoack@google.com \
--cc=jirislaby@kernel.org \
--cc=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mic@digikod.net \
--cc=oleg@redhat.com \
--cc=paul@paul-moore.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®