From: "Günther Noack" <gnoack@google.com>
To: "Günther Noack" <gnoack3000@gmail.com>,
"Paul Moore" <paul@paul-moore.com>,
"John Johansen" <john.johansen@canonical.com>,
"Tingmao Wang" <m@maowtm.org>
Cc: "Mickaël Salaün" <mic@digikod.net>,
"James Morris" <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
"Justin Suess" <utilityemal77@gmail.com>,
linux-security-module@vger.kernel.org,
"Samasth Norway Ananda" <samasth.norway.ananda@oracle.com>,
"Matthieu Buffet" <matthieu@buffet.re>,
"Mikhail Ivanov" <ivanov.mikhail1@huawei-partners.com>,
konstantin.meskhidze@huawei.com,
"Demi Marie Obenour" <demiobenour@gmail.com>,
"Alyssa Ross" <hi@alyssa.is>, "Jann Horn" <jannh@google.com>,
"Tahera Fahimi" <fahimitahera@gmail.com>,
"Simon Horman" <horms@kernel.org>,
netdev@vger.kernel.org,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>
Subject: Re: [PATCH v3 1/5] lsm: Add hook security_unix_find
Date: Wed, 4 Feb 2026 11:25:33 +0100 [thread overview]
Message-ID: <aYMenaSmBkAsFowd@google.com> (raw)
In-Reply-To: <20260119203457.97676-4-gnoack3000@gmail.com>
Hello!
John:
Friendly ping; as Paul said in [1], we would appreciate a look from
the AppArmor side whether this path-based LSM hook makes sense for
you.
Everyone:
In [2], we are currently discussing how the UNIX restriction feature
would work in the bigger scheme in Landlock, and the current plan is
that long-term we would like to support semantics where a UNIX
connection attempt is allowed if EITHER:
(a) the path is allow-listed in the policy, OR
(b) the server side we connect to is part of the same Landlock
sandbox ("domain")
With the currently proposed hook, (a) can be checked in the
security_unix_find() hook, and (b) can be checked in the
security_hook_socket_connect() hook. Unfortunately, it also would
mean that if the (a) check fails, we would have to store that
information on the side (struct sock LSM blob?), return 0 from (a) and
then later use that information in hook (b), so that we can check
whether maybe the second possible condition is met.
Q: The passing of information across multiple LSM hooks is slightly
more complicated than I had hoped; is this an approach that is
recommended?
Therefore, in [2], Tingmao is suggesting that we change the
security_unix_find() hook and pass the "other" struct sock instead of
the type.
There is obviously a balance between hooks that are very generic and
usable across multiple LSMs and hooks that are convenient to use for
every LSM.
Paul:
You have previously said that you would like hooks to be generic and
ideally reflect the arguments of the same function that they are
called from [3].
Q: Would it be acceptable to change the hook arguments, if we can then
avoid passing additional data between hooks through that side-storage?
You can see Tingmao's proposal for that in [2]. TL;DR: It moves the
call to security_unix_find() just after the place where the sk
variable ("other"-side socket) is looked up and then calls the hook
with the sk as argument instead of with the type. That way, we can do
both check (a) and (b) from above in the same hook and do not need to
store data on the side. Is that an acceptable trade-off for the LSM
interface?
Thanks,
—Günther
[1] https://lore.kernel.org/all/CAHC9VhQZ_J9316Us0squV_f-MjYXPcex34BnJ14vEBxS9Jyjbg@mail.gmail.com/
[2] https://lore.kernel.org/all/e6b6b069-384c-4c45-a56b-fa54b26bc72a@maowtm.org/
[3] https://lore.kernel.org/all/CAHC9VhQ234xihpndTs4e5ToNJ3tGCsP7AVtXuz8GajG-_jn3Ow@mail.gmail.com/
next prev parent reply other threads:[~2026-02-04 10:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 20:34 [PATCH v3 0/5] landlock: Pathname-based UNIX connect() control Günther Noack
2026-01-19 20:34 ` [PATCH v3 1/5] lsm: Add hook security_unix_find Günther Noack
2026-02-04 10:25 ` Günther Noack [this message]
2026-02-05 10:36 ` Mickaël Salaün
2026-02-09 17:09 ` Paul Moore
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=aYMenaSmBkAsFowd@google.com \
--to=gnoack@google.com \
--cc=brauner@kernel.org \
--cc=demiobenour@gmail.com \
--cc=fahimitahera@gmail.com \
--cc=gnoack3000@gmail.com \
--cc=hi@alyssa.is \
--cc=horms@kernel.org \
--cc=ivanov.mikhail1@huawei-partners.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=konstantin.meskhidze@huawei.com \
--cc=linux-security-module@vger.kernel.org \
--cc=m@maowtm.org \
--cc=matthieu@buffet.re \
--cc=mic@digikod.net \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=samasth.norway.ananda@oracle.com \
--cc=serge@hallyn.com \
--cc=utilityemal77@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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