mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack3000@gmail.com>
To: Christopher Lusk <clusk@northecho.dev>
Cc: "Mickaël Salaün" <mic@digikod.net>,
	"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: Re: [RFC PATCH 0/2] Landlock signal scope and TIOCSIG
Date: Mon, 14 Sep 2026 19:13:15 +0200	[thread overview]
Message-ID: <20260914.239dc75285d2@gnoack.org> (raw)
In-Reply-To: <20260914134013.1457130-1-clusk@northecho.dev>

Hello!

On Mon, Sep 14, 2026 at 09:40:13AM -0400, Christopher Lusk wrote:
> Your capability framing convinces me.  Controlling who may attach to (or
> open a master for) the PTY is the right layer, and the master FD is best
> thought of as the capability, the same way socketpair() is.
> 
> You are also right that the series is incomplete as a fix: the same three
> signals arrive through the n_tty control-character path (Ctrl-C / Ctrl-\ /
> Ctrl-Z) that my patch does not touch, and PTYs additionally raise SIGWINCH,
> SIGHUP and SIGCONT.  That reinforces your point rather than mine.  Chasing
> individual signal-delivery paths inside the TTY layer is the wrong layer,
> and a per-ioctl hook would only paper over one entry into a mechanism that
> is working as designed.
>
> One question, mostly so I have the line right in my own notes rather than
> to relitigate: how do you see this relative to the SIGIO/fowner path that
> 4b80320ca7ed brought under SCOPE_SIGNAL?  My read of the distinction is
> that in the SIGIO case the sandboxed process unilaterally selects the target
> by arming the owner, whereas here the recipients have voluntarily attached
> to the terminal and the TTY driver delivers job-control signals over that
> attachment.  If that is the intended boundary, it is a clean one, and I am
> happy to treat TTY-driven signals as outside the guarantee.

Yes, that is the difference why SIGIO had to be protected -- in the
SIGIO case, it was the already landlocked process which could itself
select the signal recipients through fcntl(fd, F_SETOWN, ...).

In the terminal case, it is the TTY-client-side processes that select
which processes are attached to the terminal.  With the PTY master FD
alone, it is not possible to signal processes that aren't already
attached to the terminal.


> If it is useful, I would be glad to send a small documentation patch making
> that explicit: a note in the SCOPE_SIGNAL / IPC-scoping section of
> landlock.rst that TTY-driver signal delivery (TIOCSIG and the
> control-character path) is not mediated by SCOPE_SIGNAL, with the practical
> guidance to control PTY attachment instead.  I will drop the task_kill
> approach.

Thank you, I would appreciate that!

Thanks,
–Günther

      reply	other threads:[~2026-09-14 17:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13 22:19 Christopher Lusk
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 [this message]

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=20260914.239dc75285d2@gnoack.org \
    --to=gnoack3000@gmail.com \
    --cc=casey@schaufler-ca.com \
    --cc=clusk@northecho.dev \
    --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®