* Re: [PATCH v8 05/12] tpm2-sessions: Define TPM2_NAME_MAX_SIZE
From: Jarkko Sakkinen @ 2026-01-02 16:35 UTC (permalink / raw)
To: Jonathan McDowell
Cc: linux-integrity, Peter Huewe, Jason Gunthorpe, David Howells,
Paul Moore, James Morris, Serge E. Hallyn, open list,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM
In-Reply-To: <aUUbkosWlOjZ48YP@earth.li>
On Fri, Dec 19, 2025 at 09:32:02AM +0000, Jonathan McDowell wrote:
> On Tue, Dec 16, 2025 at 11:21:39AM +0200, Jarkko Sakkinen wrote:
> > Define TPM2_NAME_MAX_SIZE, which describes the maximum size for hashes
> > encoded as TPMT_HA, which the prime identifier used for persistent and
> > transient keys in TPM2 protocol.
> >
> > Set its value to 'SHA512_DIGEST_SIZE + 2', as SHA512 has the largest
> > digest size of the algorithms in TCG algorithm repository.
> >
> > In additionl, rename TPM2_NAME_SIZE as TPM2_NULL_NAME_SIZE in order to
> > avoid any possible confusion.
>
> One minor capitalisation nit, otherwise:
>
> Reviewed-by: Jonathan McDowell <noodles@meta.com>
>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > v6:
> > - Rewrote the commit message.
> > v2:
> > - Rename TPM2_NAME_SIZE as TPM2_NULL_NAME_SIZE.
> > ---
> > drivers/char/tpm/tpm-sysfs.c | 2 +-
> > drivers/char/tpm/tpm2-sessions.c | 2 +-
> > include/linux/tpm.h | 37 +++++++++++++++++++++-----------
> > 3 files changed, 27 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
> > index 94231f052ea7..4a6a27ee295d 100644
> > --- a/drivers/char/tpm/tpm-sysfs.c
> > +++ b/drivers/char/tpm/tpm-sysfs.c
> > @@ -314,7 +314,7 @@ static ssize_t null_name_show(struct device *dev, struct device_attribute *attr,
> > char *buf)
> > {
> > struct tpm_chip *chip = to_tpm_chip(dev);
> > - int size = TPM2_NAME_SIZE;
> > + int size = TPM2_NULL_NAME_SIZE;
> >
> > bin2hex(buf, chip->null_key_name, size);
> > size *= 2;
> > diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
> > index 4149379665c4..525b8622d1c3 100644
> > --- a/drivers/char/tpm/tpm2-sessions.c
> > +++ b/drivers/char/tpm/tpm2-sessions.c
> > @@ -137,7 +137,7 @@ struct tpm2_auth {
> > * we must compute and remember
> > */
> > u32 name_h[AUTH_MAX_NAMES];
> > - u8 name[AUTH_MAX_NAMES][2 + SHA512_DIGEST_SIZE];
> > + u8 name[AUTH_MAX_NAMES][TPM2_MAX_NAME_SIZE];
> > };
> >
> > #ifdef CONFIG_TCG_TPM2_HMAC
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > index 202da079d500..e10f2096eae7 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -27,9 +27,33 @@
> >
> > #define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
> >
> > +/*
> > + * SHA-512 is, as of today, the largest digest in the TCG algorithm repository.
> > + */
> > #define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
> > +
> > +/*
> > + * A TPM name digest i.e., TPMT_HA, is a concatenation of TPM_ALG_ID of the
> > + * name algorithm and hash of TPMT_PUBLIC.
> > + */
> > +#define TPM2_MAX_NAME_SIZE (TPM2_MAX_DIGEST_SIZE + 2)
> > +
> > +/*
> > + * The maximum number of PCR banks.
> > + */
> > #define TPM2_MAX_PCR_BANKS 8
> >
> > +/*
> > + * fixed define for the size of a name. This is actually HASHALG size
>
> "Fixed define".
Thanks, yeah, I can fix this up :-)
>
> > + * plus 2, so 32 for SHA256
> > + */
> > +#define TPM2_NULL_NAME_SIZE 34
> > +
> > +/*
> > + * The maximum size for an object context
> > + */
> > +#define TPM2_MAX_CONTEXT_SIZE 4096
> > +
> > struct tpm_chip;
> > struct trusted_key_payload;
> > struct trusted_key_options;
> > @@ -139,17 +163,6 @@ struct tpm_chip_seqops {
> > /* fixed define for the curve we use which is NIST_P256 */
> > #define EC_PT_SZ 32
> >
> > -/*
> > - * fixed define for the size of a name. This is actually HASHALG size
> > - * plus 2, so 32 for SHA256
> > - */
> > -#define TPM2_NAME_SIZE 34
> > -
> > -/*
> > - * The maximum size for an object context
> > - */
> > -#define TPM2_MAX_CONTEXT_SIZE 4096
> > -
> > struct tpm_chip {
> > struct device dev;
> > struct device devs;
> > @@ -211,7 +224,7 @@ struct tpm_chip {
> > /* saved context for NULL seed */
> > u8 null_key_context[TPM2_MAX_CONTEXT_SIZE];
> > /* name of NULL seed */
> > - u8 null_key_name[TPM2_NAME_SIZE];
> > + u8 null_key_name[TPM2_NULL_NAME_SIZE];
> > u8 null_ec_key_x[EC_PT_SZ];
> > u8 null_ec_key_y[EC_PT_SZ];
> > struct tpm2_auth *auth;
> > --
> > 2.39.5
> >
> >
>
> J.
>
> --
> Why do I get the feeling I'm going to regret this?
> This .sig brought to you by the letter S and the number 50
> Product of the Republic of HuggieTag
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v8 02/12] KEYS: trusted: Use get_random_bytes_wait() instead of tpm_get_random()
From: Jarkko Sakkinen @ 2026-01-02 16:34 UTC (permalink / raw)
To: Jonathan McDowell
Cc: linux-integrity, Eric Biggers, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, James Bottomley, Mimi Zohar,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <aUUZKu2xaZvEdq-2@earth.li>
On Fri, Dec 19, 2025 at 09:21:46AM +0000, Jonathan McDowell wrote:
> On Tue, Dec 16, 2025 at 11:21:36AM +0200, Jarkko Sakkinen wrote:
> > Substitute remaining tpm_get_random() calls in trusted_tpm1.c with
> > get_random_bytes_wait() thus aligning random number generation for TPM 1.2
> > with the removal of '.get_random' callback.
>
> Had to double check we wouldn't end up not getting all the randomness we ask
> for, but get_random_bytes_wait does indeed DTRT.
>
> Reviewed-by: Jonathan McDowell <noodles@meta.com>
Thank you.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v8 07/12] KEYS: trusted: Remove dead branch from tpm2_unseal_cmd
From: Jarkko Sakkinen @ 2026-01-02 16:31 UTC (permalink / raw)
To: James Bottomley
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <57e69d4fd5a40899cd779ee04f29f33009c97431.camel@HansenPartnership.com>
On Fri, Dec 19, 2025 at 03:54:47PM -0500, James Bottomley wrote:
> On Tue, 2025-12-16 at 11:21 +0200, Jarkko Sakkinen wrote:
> > TPM2_Unseal requires TPM2_ST_SESSIONS, and tpm2_unseal_cmd() always
> > does set up either password or HMAC session.
> >
> > Remove the branch in tpm2_unseal_cmd() conditionally setting
> > TPM2_ST_NO_SESSIONS. It is faulty but luckily it is never exercised
> > at run-time, and thus does not cause regressions.
>
> Shouldn't that also be
>
> Fixes: b7960b904861 ("tpm2-sessions: Open code tpm_buf_append_hmac_session()")
The implementation has pre-existed before that commit so it did
not really cause it. The call path was just more masked before
open coding it.
The code is of course exercised in !TCG_TPM2_HMAC case but it
by definition does nothing.
>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > security/keys/trusted-keys/trusted_tpm2.c | 10 +---------
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/security/keys/trusted-keys/trusted_tpm2.c
> > b/security/keys/trusted-keys/trusted_tpm2.c
> > index d3a5c5f2b926..3666e3e48eab 100644
> > --- a/security/keys/trusted-keys/trusted_tpm2.c
> > +++ b/security/keys/trusted-keys/trusted_tpm2.c
> > @@ -451,10 +451,8 @@ static int tpm2_unseal_cmd(struct tpm_chip
> > *chip,
> > struct trusted_key_options *options,
> > u32 blob_handle)
> > {
> > - struct tpm_header *head;
> > struct tpm_buf buf;
> > u16 data_len;
> > - int offset;
> > u8 *data;
> > int rc;
> >
> > @@ -495,14 +493,8 @@ static int tpm2_unseal_cmd(struct tpm_chip
> > *chip,
> > tpm_buf_append_u16(&buf, options->blobauth_len);
> > tpm_buf_append(&buf, options->blobauth, options-
> > >blobauth_len);
> >
> > - if (tpm2_chip_auth(chip)) {
> > + if (tpm2_chip_auth(chip))
>
> Since the statement above is that the if is always true, why do you
> still have it here?
This is still necessary for !TCG_TPM2_HMAC case. The commit is pretty
much exactly in its described scope.
>
> Regards,
>
> James
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH V2 1/1] IMA event log trimming
From: steven chen @ 2026-01-02 14:33 UTC (permalink / raw)
To: Mimi Zohar, linux-integrity
Cc: roberto.sassu, dmitry.kasatkin, eric.snowberg, corbet, serge,
paul, jmorris, linux-security-module, anirudhve, gregorylumen,
nramas, sushring, linux-doc, steven chen
In-Reply-To: <9a26898f46406314be1308e5416c0d51cedf44a4.camel@linux.ibm.com>
On 12/23/2025 2:32 PM, Mimi Zohar wrote:
> On Tue, 2025-12-16 at 11:59 -0800, steven chen wrote:
>>>>> +{
>>>>> + struct ima_queue_entry *qe, *qe_tmp;
>>>>> + LIST_HEAD(ima_measurements_staged);
>>>>> + unsigned int i;
>>>>> + long cur = number_logs;
>>> The variable name "number_logs" is confusing. As I mentioned in the patch
>>> description, there is one measurement list with multiple records. There aren't
>>> multiple logs in the kernel (other than the staged list).
>> Will update it to "req_value". Thanks!
> Please refer to the section titled "Naming" in Documentation/process/coding-
> style.rst. Since this is the number of records being deleted, perhaps a better
> variable name would be "num_records".
>
Will update. Thanks
Steven
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Günther Noack @ 2026-01-02 10:50 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Tingmao Wang, Mickaël Salaün, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <81f908e3-8a98-46e7-b20c-fe647784ceb4@gmail.com>
On Fri, Jan 02, 2026 at 05:27:40AM -0500, Demi Marie Obenour wrote:
> On 1/2/26 05:16, Günther Noack wrote:
> > On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
> >> On 1/1/26 17:34, Tingmao Wang wrote:
> >>> On 1/1/26 22:14, Demi Marie Obenour wrote:
> >>>> [...]
> >>>> Does this leave directory traversal as the only missing Landlock
> >>>> filesystem access control? Ideally Landlock could provide the same
> >>>> isolation from the filesystem that mount namespaces do.
> >>>
> >>> I think that level of isolation would require path walk control - see:
> >>> https://github.com/landlock-lsm/linux/issues/9
> >>>
> >>> (Landlock also doesn't currently control some metadata operations - see
> >>> the warning at the end of the "Filesystem flags" section in [1])
> >>>
> >>> [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
> >>
> >> Could this replace all of the existing hooks?
> >
> > If you do not need to distinguish between the different operations
> > which Landlock offers access rights for, but you only want to limit
> > the visibility of directory hierarchies in the file system, then yes,
> > the path walk control described in issue 9 would be sufficient and a
> > more complete control.
> >
> > The path walk control is probably among the more difficult Landlock
> > feature requests. A simple implementation would be easy to implement
> > technically, but it also requires a new LSM hook which will have to
> > get called *during* path lookup, and we'd have to make sure that the
> > performance impact stays in check. Path lookup is after all a very
> > central facility in a OS kernel.
>
> What about instead using the inode-based hooks for directory searching?
> SELinux can already restrict that.
Oh, thanks, good pointer! I was under the impression that this didn't
exist yet -- I assume you are referring to the
security_inode_follow_link() hook, which is already happening during
path resolution?
I take it back then. :) If there is prior art, implementing this might
be more feasible than I thought.
–Günther
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Demi Marie Obenour @ 2026-01-02 10:27 UTC (permalink / raw)
To: Günther Noack
Cc: Tingmao Wang, Mickaël Salaün, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <20260102.93e0d7b9c9b5@gnoack.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1722 bytes --]
On 1/2/26 05:16, Günther Noack wrote:
> On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
>> On 1/1/26 17:34, Tingmao Wang wrote:
>>> On 1/1/26 22:14, Demi Marie Obenour wrote:
>>>> [...]
>>>> Does this leave directory traversal as the only missing Landlock
>>>> filesystem access control? Ideally Landlock could provide the same
>>>> isolation from the filesystem that mount namespaces do.
>>>
>>> I think that level of isolation would require path walk control - see:
>>> https://github.com/landlock-lsm/linux/issues/9
>>>
>>> (Landlock also doesn't currently control some metadata operations - see
>>> the warning at the end of the "Filesystem flags" section in [1])
>>>
>>> [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
>>
>> Could this replace all of the existing hooks?
>
> If you do not need to distinguish between the different operations
> which Landlock offers access rights for, but you only want to limit
> the visibility of directory hierarchies in the file system, then yes,
> the path walk control described in issue 9 would be sufficient and a
> more complete control.
>
> The path walk control is probably among the more difficult Landlock
> feature requests. A simple implementation would be easy to implement
> technically, but it also requires a new LSM hook which will have to
> get called *during* path lookup, and we'd have to make sure that the
> performance impact stays in check. Path lookup is after all a very
> central facility in a OS kernel.
What about instead using the inode-based hooks for directory searching?
SELinux can already restrict that.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Günther Noack @ 2026-01-02 10:25 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Tingmao Wang, Mickaël Salaün, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <20260102.93e0d7b9c9b5@gnoack.org>
On Fri, Jan 02, 2026 at 11:16:33AM +0100, Günther Noack wrote:
> Regarding the un-restrictable operations, Tingmao's pointers are
> correct. In the warning box in the documentation, the missing
> operations that I am aware of are (a) the Unix socket connect()
> operation, and (b) the symlink lookup which happens implicitly during
> path traversal and which Landlock and other LSMs can not control
> through LSM hooks at the moment. (A symlink always gets implicitly
> resolved during path lookup even when you do not have directory read
> permissions on the directory where the symlink is.)
I forgot to mention - the error codes returned by Landlock make it
possible to probe for the presence of files, even when all available
FS access rights are denied on a directory. Attempting to open a file
for reading will return EEXIST if it is missing, but will return
EACCES if it is denied by Landlock.
gnoack:/tmp/xxx$ ls
foobar.txt
gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/cat foobar.txt
cat: foobar.txt: Permission denied
gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/cat nonexistent.txt
cat: nonexistent.txt: No such file or directory
gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/ls
ls: cannot open directory '.': Permission denied
–Günther
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Günther Noack @ 2026-01-02 10:16 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Tingmao Wang, Mickaël Salaün, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <1d36b2ee-b967-42d7-a6c2-e5b1602a512f@gmail.com>
On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
> On 1/1/26 17:34, Tingmao Wang wrote:
> > On 1/1/26 22:14, Demi Marie Obenour wrote:
> >> [...]
> >> Does this leave directory traversal as the only missing Landlock
> >> filesystem access control? Ideally Landlock could provide the same
> >> isolation from the filesystem that mount namespaces do.
> >
> > I think that level of isolation would require path walk control - see:
> > https://github.com/landlock-lsm/linux/issues/9
> >
> > (Landlock also doesn't currently control some metadata operations - see
> > the warning at the end of the "Filesystem flags" section in [1])
> >
> > [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
>
> Could this replace all of the existing hooks?
If you do not need to distinguish between the different operations
which Landlock offers access rights for, but you only want to limit
the visibility of directory hierarchies in the file system, then yes,
the path walk control described in issue 9 would be sufficient and a
more complete control.
The path walk control is probably among the more difficult Landlock
feature requests. A simple implementation would be easy to implement
technically, but it also requires a new LSM hook which will have to
get called *during* path lookup, and we'd have to make sure that the
performance impact stays in check. Path lookup is after all a very
central facility in a OS kernel.
Regarding the un-restrictable operations, Tingmao's pointers are
correct. In the warning box in the documentation, the missing
operations that I am aware of are (a) the Unix socket connect()
operation, and (b) the symlink lookup which happens implicitly during
path traversal and which Landlock and other LSMs can not control
through LSM hooks at the moment. (A symlink always gets implicitly
resolved during path lookup even when you do not have directory read
permissions on the directory where the symlink is.)
–Günther
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Günther Noack @ 2026-01-02 9:53 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Justin Suess, Tingmao Wang, fahimitahera, hi, ivanov.mikhail1,
jannh, konstantin.meskhidze, linux-security-module, matthieu, mic,
paul, samasth.norway.ananda
In-Reply-To: <884e44c6-7695-49a2-8d60-c7e76d260bea@gmail.com>
On Thu, Jan 01, 2026 at 05:39:26PM -0500, Demi Marie Obenour wrote:
> On 1/1/26 17:38, Justin Suess wrote:
> > On 1/1/26 17:19, Tingmao Wang wrote:
> >> On 1/1/26 22:11, Demi Marie Obenour wrote:
> >>> On 1/1/26 17:07, Tingmao Wang wrote:
> >>>
> >>> (snip)
> >>>
> >>>> Looking at this I guess it might also make sense for the kernel side to
> >>>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
> >>>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
> >>>>
> >>>> Also, for the sandboxer logic, maybe a better way would be having
> >>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
> >>>> then another if(!S_ISSOCK) below this that will clear out
> >>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
> >>> A process might legitimately need to connect to a socket that doesn't
> >>> exist at the time it sandboxes itself. Therefore, I think it makes
> >>> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
> >>> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
> >>> directory. This matches the flexibility mount namespaces can achieve.
> >> Right, I forgot about the fact that we also need it on dirs, apologies.
> >>
> >> (But maybe it might still make sense to not allow this on files which are
> >> neither a socket or a dir? (If the file later gets removed and recreated
> >> as a socket, the rule would not apply retroactively anyway due to being
> >> tied to the inode.))
> > How do we handle IOCTL access on regular files? I think that landlock will let you put IOCTL rights on regular files even they are not valid for that operation.
>
> Regular files definitely support ioctls.
The LANDLOCK_ACCESS_FS_IOCTL_DEV right only applies to ioctl(2)
invocations on device files.
> > Sockets seem like a similar case where the operation is only valid for a subset of file types.
> >
> > I think we should mirror the existing behavior is for consistency.
> >
> > Besides, restricting which file types can have that right also makes it harder for applications that may not care about the specific file type, but now would have to check the filetype before making a policy on them (also opening them to TOCTOU).
>
> I agree.
I also agree with your interpretation, Justin.
For the record, Landlock's kernel implementation currently groups FS
access rights into two groups:
- file access rights
- directory-only rights
When adding a rule, the directory access rights can only be granted on
a directory inode. The file access rights can be granted on both a
directory inode and a regular file inode.
It is pointless to grant the CONNECT_UNIX (or IOCTL_DEV) right on a
file which is not a Unix socket (or device file). But it complicates
the userspace API if we introduce more special rules there. - Users of
Landlock would have to keep track of all these special cases and
mirror the logic, which is error prone. IMHO is is granular enough if
we differentiate between files and directories as we currently do.
For reference, this is documented at
https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
and the logic is implemented in landlock_append_fs_rule() in fs.c.
(Actually, in the implementation, the IOCTL_DEV right is treated the
same as one of the ACCESS_FILE rights - I should probably revise that
documentation: That right does not *directly* apply to a directory
inode, as directories are not device files. It only inherits down in
the file system hierarchy. Looking back at earlier versions of the
IOCTL_DEV patch set, it was different there. I think I missed to keep
the documentation in-line.)
–Günther
^ permalink raw reply
* Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect
From: Justin Suess @ 2026-01-01 23:40 UTC (permalink / raw)
To: Tingmao Wang
Cc: gnoack3000, gnoack, horms, jmorris, kuniyu, linux-security-module,
mic, netdev, paul, serge
In-Reply-To: <b992df90-92da-48bd-91d1-051af9670d07@maowtm.org>
On 1/1/26 18:11, Tingmao Wang wrote:
> On 1/1/26 19:45, Justin Suess wrote:
>> [...]
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 55cdebfa0da0..397687e2d87f 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -1226,6 +1226,18 @@ static struct sock *unix_find_bsd(struct
>> sockaddr_un *sunaddr, int addr_len,
>> if (!S_ISSOCK(inode->i_mode))
>> goto path_put;
>>
>> + /*
>> + * We call the hook because we know that the inode is a socket
>> + * and we hold a valid reference to it via the path.
>> + * We intentionally forgo the ability to restrict SOCK_COREDUMP.
>> + */
>> + if (!(flags & SOCK_COREDUMP)) {
>> + err = security_unix_path_connect(&path);
>> + if (err)
>> + goto path_put;
>> + err = -ECONNREFUSED;
> I'm not sure if this is a good suggestion, but I think it might be cleaner
> to move this `err = -ECONNREFUSED;` out of the if, and do it
> unconditionally above the `sk = unix_find_socket_byinode(inode);` below?
> To me that makes the intention for resetting err clear (it is to ensure
> that a NULL return from unix_find_socket_byinode causes us to return
> -ECONNREFUSED).
>
I'll do that. That does make it more clear.
I suspect resetting the error accidentally was what caused the syzbot to rightfully complain.
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 55cdebfa0da0..2e0300121ab5 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1226,6 +1226,18 @@ static struct sock *unix_find_bsd(struct sockaddr_un *sunaddr, int addr_len,
if (!S_ISSOCK(inode->i_mode))
goto path_put;
+ /*
+ * We call the hook because we know that the inode is a socket
+ * and we hold a valid reference to it via the path.
+ * We intentionally forgo the ability to restrict SOCK_COREDUMP.
+ */
+ if (!(flags & SOCK_COREDUMP)) {
+ err = security_unix_path_connect(&path);
+ if (err)
+ goto path_put;
+ }
+ err = -ECONNREFUSED;
+
sk = unix_find_socket_byinode(inode);
if (!sk)
goto path_put;
^ permalink raw reply related
* Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect
From: Tingmao Wang @ 2026-01-01 23:11 UTC (permalink / raw)
To: Justin Suess
Cc: gnoack3000, gnoack, horms, jmorris, kuniyu, linux-security-module,
mic, netdev, paul, serge
In-Reply-To: <20260101194551.4017198-1-utilityemal77@gmail.com>
On 1/1/26 19:45, Justin Suess wrote:
> [...]
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 55cdebfa0da0..397687e2d87f 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1226,6 +1226,18 @@ static struct sock *unix_find_bsd(struct
> sockaddr_un *sunaddr, int addr_len,
> if (!S_ISSOCK(inode->i_mode))
> goto path_put;
>
> + /*
> + * We call the hook because we know that the inode is a socket
> + * and we hold a valid reference to it via the path.
> + * We intentionally forgo the ability to restrict SOCK_COREDUMP.
> + */
> + if (!(flags & SOCK_COREDUMP)) {
> + err = security_unix_path_connect(&path);
> + if (err)
> + goto path_put;
> + err = -ECONNREFUSED;
I'm not sure if this is a good suggestion, but I think it might be cleaner
to move this `err = -ECONNREFUSED;` out of the if, and do it
unconditionally above the `sk = unix_find_socket_byinode(inode);` below?
To me that makes the intention for resetting err clear (it is to ensure
that a NULL return from unix_find_socket_byinode causes us to return
-ECONNREFUSED).
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Demi Marie Obenour @ 2026-01-01 22:44 UTC (permalink / raw)
To: Tingmao Wang
Cc: Günther Noack, Mickaël Salaün, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <73c5509a-5daa-4ea5-ab9f-e24a59786f6d@maowtm.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 755 bytes --]
On 1/1/26 17:34, Tingmao Wang wrote:
> On 1/1/26 22:14, Demi Marie Obenour wrote:
>> [...]
>> Does this leave directory traversal as the only missing Landlock
>> filesystem access control? Ideally Landlock could provide the same
>> isolation from the filesystem that mount namespaces do.
>
> I think that level of isolation would require path walk control - see:
> https://github.com/landlock-lsm/linux/issues/9
>
> (Landlock also doesn't currently control some metadata operations - see
> the warning at the end of the "Filesystem flags" section in [1])
>
> [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
Could this replace all of the existing hooks?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Demi Marie Obenour @ 2026-01-01 22:39 UTC (permalink / raw)
To: Justin Suess, Tingmao Wang, Günther Noack
Cc: fahimitahera, hi, ivanov.mikhail1, jannh, konstantin.meskhidze,
linux-security-module, matthieu, mic, paul, samasth.norway.ananda
In-Reply-To: <43c0515d-afd3-4e00-a0fe-4d651a1d5cf1@gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2095 bytes --]
On 1/1/26 17:38, Justin Suess wrote:
> On 1/1/26 17:19, Tingmao Wang wrote:
>> On 1/1/26 22:11, Demi Marie Obenour wrote:
>>> On 1/1/26 17:07, Tingmao Wang wrote:
>>>
>>> (snip)
>>>
>>>> Looking at this I guess it might also make sense for the kernel side to
>>>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
>>>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
>>>>
>>>> Also, for the sandboxer logic, maybe a better way would be having
>>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
>>>> then another if(!S_ISSOCK) below this that will clear out
>>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
>>> A process might legitimately need to connect to a socket that doesn't
>>> exist at the time it sandboxes itself. Therefore, I think it makes
>>> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
>>> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
>>> directory. This matches the flexibility mount namespaces can achieve.
>> Right, I forgot about the fact that we also need it on dirs, apologies.
>>
>> (But maybe it might still make sense to not allow this on files which are
>> neither a socket or a dir? (If the file later gets removed and recreated
>> as a socket, the rule would not apply retroactively anyway due to being
>> tied to the inode.))
> How do we handle IOCTL access on regular files? I think that landlock will let you put IOCTL rights on regular files even they are not valid for that operation.
Regular files definitely support ioctls.
> Sockets seem like a similar case where the operation is only valid for a subset of file types.
>
> I think we should mirror the existing behavior is for consistency.
>
> Besides, restricting which file types can have that right also makes it harder for applications that may not care about the specific file type, but now would have to check the filetype before making a policy on them (also opening them to TOCTOU).
I agree.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Justin Suess @ 2026-01-01 22:38 UTC (permalink / raw)
To: Tingmao Wang, Demi Marie Obenour, Günther Noack
Cc: fahimitahera, hi, ivanov.mikhail1, jannh, konstantin.meskhidze,
linux-security-module, matthieu, mic, paul, samasth.norway.ananda
In-Reply-To: <2d02eefa-bc86-4f04-b190-beed304337d4@maowtm.org>
On 1/1/26 17:19, Tingmao Wang wrote:
> On 1/1/26 22:11, Demi Marie Obenour wrote:
>> On 1/1/26 17:07, Tingmao Wang wrote:
>>
>> (snip)
>>
>>> Looking at this I guess it might also make sense for the kernel side to
>>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
>>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
>>>
>>> Also, for the sandboxer logic, maybe a better way would be having
>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
>>> then another if(!S_ISSOCK) below this that will clear out
>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
>> A process might legitimately need to connect to a socket that doesn't
>> exist at the time it sandboxes itself. Therefore, I think it makes
>> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
>> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
>> directory. This matches the flexibility mount namespaces can achieve.
> Right, I forgot about the fact that we also need it on dirs, apologies.
>
> (But maybe it might still make sense to not allow this on files which are
> neither a socket or a dir? (If the file later gets removed and recreated
> as a socket, the rule would not apply retroactively anyway due to being
> tied to the inode.))
How do we handle IOCTL access on regular files? I think that landlock will let you put IOCTL rights on regular files even they are not valid for that operation.
Sockets seem like a similar case where the operation is only valid for a subset of file types.
I think we should mirror the existing behavior is for consistency.
Besides, restricting which file types can have that right also makes it harder for applications that may not care about the specific file type, but now would have to check the filetype before making a policy on them (also opening them to TOCTOU).
Justin
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Demi Marie Obenour @ 2026-01-01 22:36 UTC (permalink / raw)
To: Tingmao Wang, Günther Noack, Justin Suess
Cc: fahimitahera, hi, ivanov.mikhail1, jannh, konstantin.meskhidze,
linux-security-module, matthieu, mic, paul, samasth.norway.ananda
In-Reply-To: <2d02eefa-bc86-4f04-b190-beed304337d4@maowtm.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1414 bytes --]
On 1/1/26 17:19, Tingmao Wang wrote:
> On 1/1/26 22:11, Demi Marie Obenour wrote:
>> On 1/1/26 17:07, Tingmao Wang wrote:
>>
>> (snip)
>>
>>> Looking at this I guess it might also make sense for the kernel side to
>>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
>>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
>>>
>>> Also, for the sandboxer logic, maybe a better way would be having
>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
>>> then another if(!S_ISSOCK) below this that will clear out
>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
>>
>> A process might legitimately need to connect to a socket that doesn't
>> exist at the time it sandboxes itself. Therefore, I think it makes
>> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
>> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
>> directory. This matches the flexibility mount namespaces can achieve.
>
> Right, I forgot about the fact that we also need it on dirs, apologies.
>
> (But maybe it might still make sense to not allow this on files which are
> neither a socket or a dir? (If the file later gets removed and recreated
> as a socket, the rule would not apply retroactively anyway due to being
> tied to the inode.))
I agree with this.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Tingmao Wang @ 2026-01-01 22:34 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Günther Noack, Mickaël Salaün, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <61a6be66-a9bd-4d68-98ed-29aac65b7dfb@gmail.com>
On 1/1/26 22:14, Demi Marie Obenour wrote:
> [...]
> Does this leave directory traversal as the only missing Landlock
> filesystem access control? Ideally Landlock could provide the same
> isolation from the filesystem that mount namespaces do.
I think that level of isolation would require path walk control - see:
https://github.com/landlock-lsm/linux/issues/9
(Landlock also doesn't currently control some metadata operations - see
the warning at the end of the "Filesystem flags" section in [1])
[1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Tingmao Wang @ 2026-01-01 22:19 UTC (permalink / raw)
To: Demi Marie Obenour, Günther Noack, Justin Suess
Cc: fahimitahera, hi, ivanov.mikhail1, jannh, konstantin.meskhidze,
linux-security-module, matthieu, mic, paul, samasth.norway.ananda
In-Reply-To: <22e29fd8-2f39-4a64-b08c-2f41153e3be8@gmail.com>
On 1/1/26 22:11, Demi Marie Obenour wrote:
> On 1/1/26 17:07, Tingmao Wang wrote:
>
> (snip)
>
>> Looking at this I guess it might also make sense for the kernel side to
>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
>>
>> Also, for the sandboxer logic, maybe a better way would be having
>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
>> then another if(!S_ISSOCK) below this that will clear out
>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
>
> A process might legitimately need to connect to a socket that doesn't
> exist at the time it sandboxes itself. Therefore, I think it makes
> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
> directory. This matches the flexibility mount namespaces can achieve.
Right, I forgot about the fact that we also need it on dirs, apologies.
(But maybe it might still make sense to not allow this on files which are
neither a socket or a dir? (If the file later gets removed and recreated
as a socket, the rule would not apply retroactively anyway due to being
tied to the inode.))
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Demi Marie Obenour @ 2026-01-01 22:14 UTC (permalink / raw)
To: Günther Noack, Mickaël Salaün, Paul Moore
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <20260101134102.25938-1-gnoack3000@gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 432 bytes --]
On 1/1/26 08:40, Günther Noack wrote:
> Happy New Year!
>
> This patch set introduces a file-system-based Landlock restriction
> mechanism for connecting to Unix sockets.
(snip)
Does this leave directory traversal as the only missing Landlock
filesystem access control? Ideally Landlock could provide the same
isolation from the filesystem that mount namespaces do.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Demi Marie Obenour @ 2026-01-01 22:11 UTC (permalink / raw)
To: Tingmao Wang, Günther Noack, Justin Suess
Cc: fahimitahera, hi, ivanov.mikhail1, jannh, konstantin.meskhidze,
linux-security-module, matthieu, mic, paul, samasth.norway.ananda
In-Reply-To: <423dd2ca-ecba-47cf-98a7-4d99a48939da@maowtm.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 931 bytes --]
On 1/1/26 17:07, Tingmao Wang wrote:
(snip)
> Looking at this I guess it might also make sense for the kernel side to
> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
>
> Also, for the sandboxer logic, maybe a better way would be having
> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
> then another if(!S_ISSOCK) below this that will clear out
> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
A process might legitimately need to connect to a socket that doesn't
exist at the time it sandboxes itself. Therefore, I think it makes
sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
directory. This matches the flexibility mount namespaces can achieve.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Tingmao Wang @ 2026-01-01 22:07 UTC (permalink / raw)
To: Günther Noack, Justin Suess
Cc: demiobenour, fahimitahera, hi, ivanov.mikhail1, jannh,
konstantin.meskhidze, linux-security-module, matthieu, mic, paul,
samasth.norway.ananda
In-Reply-To: <20260101193009.4005972-1-utilityemal77@gmail.com>
On 1/1/26 19:30, Justin Suess wrote:
> Allow users to separately specify unix socket rights,
> document the variable, and make the right optional.
>
> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> Cc: Günther Noack <gnoack3000@gmail.com>
> ---
>
> Notes:
>
> Small fixup suggestion patch to this RFC series.
>
> Handling the unix connect rights separate from
> other rights makes more sense, and makes the sandboxer
> much easier to use. Also connect doesn't really neatly
> correspond to "roughly write" in my opinion, so this puts
> it in a separate variable documented in the help printout.
>
> This also makes it possible to specify rights on the socket itself,
> which wasn't possible.
>
> before:
> ~ # LL_FS_RO=/ LL_FS_RW=/tmp/test.sock landlock-sandboxer sh -c 'echo "hello" |
> socat - UNIX-CONNECT:/tmp/test.sock'
> Executing the sandboxed command...
> 2026/01/01 19:14:33 socat[78] E connect(, AF=1 "/tmp/test.sock", 16): Permission denied
>
> after:
> ~ # LL_FS_RO=/ LL_FS_RW= LL_UNIX_CONNECT=/tmp/test.sock landlock-sandboxer sh -c
> 'echo "hello" | socat - UNIX-CONNECT:/tmp/test.sock'
> Executing the sandboxed command...
> hello
>
> samples/landlock/sandboxer.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c
> index b24ef317d1ea..3df7e7c8b6f1 100644
> --- a/samples/landlock/sandboxer.c
> +++ b/samples/landlock/sandboxer.c
> @@ -62,6 +62,7 @@ static inline int landlock_restrict_self(const int ruleset_fd,
> #define ENV_TCP_CONNECT_NAME "LL_TCP_CONNECT"
> #define ENV_SCOPED_NAME "LL_SCOPED"
> #define ENV_FORCE_LOG_NAME "LL_FORCE_LOG"
> +#define ENV_UNIX_CONNECT_NAME "LL_UNIX_CONNECT"
> #define ENV_DELIMITER ":"
>
> static int str2num(const char *numstr, __u64 *num_dst)
> @@ -163,8 +164,14 @@ static int populate_ruleset_fs(const char *const env_var, const int ruleset_fd,
> goto out_free_name;
> }
> path_beneath.allowed_access = allowed_access;
> - if (!S_ISDIR(statbuf.st_mode))
> + if (!S_ISDIR(statbuf.st_mode)) {
> path_beneath.allowed_access &= ACCESS_FILE;
> + /* Keep CONNECT_UNIX for socket files. */
> + if (S_ISSOCK(statbuf.st_mode))
> + path_beneath.allowed_access |=
> + allowed_access &
> + LANDLOCK_ACCESS_FS_CONNECT_UNIX;
Looking at this I guess it might also make sense for the kernel side to
enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
Also, for the sandboxer logic, maybe a better way would be having
LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
then another if(!S_ISSOCK) below this that will clear out
LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
^ permalink raw reply
* Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect
From: Justin Suess @ 2026-01-01 19:45 UTC (permalink / raw)
To: gnoack3000
Cc: gnoack, horms, jmorris, kuniyu, linux-security-module, m, mic,
netdev, paul, serge, utilityemal77
In-Reply-To: <20260101.f6d0f71ca9bb@gnoack.org>
On 1/1/26 07:13, Günther Noack wrote:
> On Wed, Dec 31, 2025 at 04:33:14PM -0500, Justin Suess wrote:
>> Adds an LSM hook unix_path_connect.
>>
>> This hook is called to check the path of a named unix socket before a
>> connection is initiated.
>>
>> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
>> Cc: Günther Noack <gnoack3000@gmail.com>
>> ---
>> include/linux/lsm_hook_defs.h | 1 +
>> include/linux/security.h | 6 ++++++
>> net/unix/af_unix.c | 8 ++++++++
>> security/security.c | 16 ++++++++++++++++
>> 4 files changed, 31 insertions(+)
>>
>> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
>> index 8c42b4bde09c..a42d1aaf3b8a 100644
>> --- a/include/linux/lsm_hook_defs.h
>> +++ b/include/linux/lsm_hook_defs.h
>> @@ -318,6 +318,7 @@ LSM_HOOK(int, 0, watch_key, struct key *key)
>> #endif /* CONFIG_SECURITY && CONFIG_KEY_NOTIFICATIONS */
>>
>> #ifdef CONFIG_SECURITY_NETWORK
>> +LSM_HOOK(int, 0, unix_path_connect, const struct path *path)
>
> You are placing this guarded by CONFIG_SECURITY_NETWORK, but there is
> also CONFIG_SECURITY_PATH. Should it be guarded by both?
Agreed. I've moved it to a separate #if block with both
CONFIG_SECURITY_NETWORK and CONFIG_SECURITY_PATH for this and the other
places it was needed.
>
>
>
>> LSM_HOOK(int, 0, unix_stream_connect, struct sock *sock, struct sock *other,
>> struct sock *newsk)
>> LSM_HOOK(int, 0, unix_may_send, struct socket *sock, struct socket *other)
>> diff --git a/include/linux/security.h b/include/linux/security.h
>> index 83a646d72f6f..ab66f22f7e5a 100644
>> --- a/include/linux/security.h
>> +++ b/include/linux/security.h
>> @@ -1638,6 +1638,7 @@ static inline int security_watch_key(struct key *key)
>>
>> #ifdef CONFIG_SECURITY_NETWORK
>>
>> +int security_unix_path_connect(const struct path *path);
>> int security_netlink_send(struct sock *sk, struct sk_buff *skb);
>> int security_unix_stream_connect(struct sock *sock, struct sock *other, struct sock *newsk);
>> int security_unix_may_send(struct socket *sock, struct socket *other);
>> @@ -1699,6 +1700,11 @@ static inline int security_netlink_send(struct sock *sk, struct sk_buff *skb)
>> return 0;
>> }
>>
>> +static inline int security_unix_path_connect(const struct path *path)
>> +{
>> + return 0;
>> +}
>> +
>> static inline int security_unix_stream_connect(struct sock *sock,
>> struct sock *other,
>> struct sock *newsk)
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 55cdebfa0da0..af1a6083a69b 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -1226,6 +1226,14 @@ static struct sock *unix_find_bsd(struct sockaddr_un *sunaddr, int addr_len,
>> if (!S_ISSOCK(inode->i_mode))
>> goto path_put;
>>
>> + /*
>> + * We call the hook because we know that the inode is a socket
>> + * and we hold a valid reference to it via the path.
>> + */
>> + err = security_unix_path_connect(&path);
>> + if (err)
>> + goto path_put;
>
> In this place, the hook call is done also for the coredump socket.
>
> The coredump socket is a system-wide setting, and it feels weird to me
> that unprivileged processes should be able to inhibit that connection?
No I don't think they should be able to. Does this look better?
It also fixes overwriting the the error code when the hook returns.
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 55cdebfa0da0..397687e2d87f 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1226,6 +1226,18 @@ static struct sock *unix_find_bsd(struct
sockaddr_un *sunaddr, int addr_len,
if (!S_ISSOCK(inode->i_mode))
goto path_put;
+ /*
+ * We call the hook because we know that the inode is a socket
+ * and we hold a valid reference to it via the path.
+ * We intentionally forgo the ability to restrict SOCK_COREDUMP.
+ */
+ if (!(flags & SOCK_COREDUMP)) {
+ err = security_unix_path_connect(&path);
+ if (err)
+ goto path_put;
+ err = -ECONNREFUSED;
+ }
+
sk = unix_find_socket_byinode(inode);
if (!sk)
goto path_put;
>
>
>> +
>> sk = unix_find_socket_byinode(inode);
>> if (!sk)
>> goto path_put;
>> diff --git a/security/security.c b/security/security.c
>> index 31a688650601..17af5d0ddf28 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -4047,6 +4047,22 @@ int security_unix_stream_connect(struct sock *sock, struct sock *other,
>> }
>> EXPORT_SYMBOL(security_unix_stream_connect);
>>
>> +/*
>> + * security_unix_path_connect() - Check if a named AF_UNIX socket can connect
>> + * @path: Path of the socket being connected to
> ^
> mega-nit: lowercase for consistency
Gotcha.
>
>
>> + *
>> + * This hook is called to check permissions before connecting to a named
>> + * AF_UNIX socket. This is necessary because it was not possible to check the
>> + * VFS inode of the target socket before the connection is made.
>
> I'd drop the last sentence; the defense why this is necessary can go
> in the commit message, and once we have a call-site for the hook,
> someone browsing the kernel code can look up what it is used for.
Sounds good to me.
>
>
>> + *
>> + * Return: Returns 0 if permission is granted.
>> + */
>> +int security_unix_path_connect(const struct path *path)
>> +{
>> + return call_int_hook(unix_path_connect, path);
>> +}
>> +EXPORT_SYMBOL(security_unix_path_connect);
>> +
>> /**
>> * security_unix_may_send() - Check if AF_UNIX socket can send datagrams
>> * @sock: originating sock
>> --
>> 2.51.0
>>
^ permalink raw reply related
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Justin Suess @ 2026-01-01 19:30 UTC (permalink / raw)
To: gnoack3000
Cc: demiobenour, fahimitahera, hi, ivanov.mikhail1, jannh,
konstantin.meskhidze, linux-security-module, m, matthieu, mic,
paul, samasth.norway.ananda, utilityemal77
In-Reply-To: <20260101134102.25938-4-gnoack3000@gmail.com>
Allow users to separately specify unix socket rights,
document the variable, and make the right optional.
Signed-off-by: Justin Suess <utilityemal77@gmail.com>
Cc: Günther Noack <gnoack3000@gmail.com>
---
Notes:
Small fixup suggestion patch to this RFC series.
Handling the unix connect rights separate from
other rights makes more sense, and makes the sandboxer
much easier to use. Also connect doesn't really neatly
correspond to "roughly write" in my opinion, so this puts
it in a separate variable documented in the help printout.
This also makes it possible to specify rights on the socket itself,
which wasn't possible.
before:
~ # LL_FS_RO=/ LL_FS_RW=/tmp/test.sock landlock-sandboxer sh -c 'echo "hello" |
socat - UNIX-CONNECT:/tmp/test.sock'
Executing the sandboxed command...
2026/01/01 19:14:33 socat[78] E connect(, AF=1 "/tmp/test.sock", 16): Permission denied
after:
~ # LL_FS_RO=/ LL_FS_RW= LL_UNIX_CONNECT=/tmp/test.sock landlock-sandboxer sh -c
'echo "hello" | socat - UNIX-CONNECT:/tmp/test.sock'
Executing the sandboxed command...
hello
samples/landlock/sandboxer.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c
index b24ef317d1ea..3df7e7c8b6f1 100644
--- a/samples/landlock/sandboxer.c
+++ b/samples/landlock/sandboxer.c
@@ -62,6 +62,7 @@ static inline int landlock_restrict_self(const int ruleset_fd,
#define ENV_TCP_CONNECT_NAME "LL_TCP_CONNECT"
#define ENV_SCOPED_NAME "LL_SCOPED"
#define ENV_FORCE_LOG_NAME "LL_FORCE_LOG"
+#define ENV_UNIX_CONNECT_NAME "LL_UNIX_CONNECT"
#define ENV_DELIMITER ":"
static int str2num(const char *numstr, __u64 *num_dst)
@@ -163,8 +164,14 @@ static int populate_ruleset_fs(const char *const env_var, const int ruleset_fd,
goto out_free_name;
}
path_beneath.allowed_access = allowed_access;
- if (!S_ISDIR(statbuf.st_mode))
+ if (!S_ISDIR(statbuf.st_mode)) {
path_beneath.allowed_access &= ACCESS_FILE;
+ /* Keep CONNECT_UNIX for socket files. */
+ if (S_ISSOCK(statbuf.st_mode))
+ path_beneath.allowed_access |=
+ allowed_access &
+ LANDLOCK_ACCESS_FS_CONNECT_UNIX;
+ }
if (landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
&path_beneath, 0)) {
fprintf(stderr,
@@ -295,8 +302,7 @@ static bool check_ruleset_scope(const char *const env_var,
LANDLOCK_ACCESS_FS_MAKE_SYM | \
LANDLOCK_ACCESS_FS_REFER | \
LANDLOCK_ACCESS_FS_TRUNCATE | \
- LANDLOCK_ACCESS_FS_IOCTL_DEV | \
- LANDLOCK_ACCESS_FS_CONNECT_UNIX)
+ LANDLOCK_ACCESS_FS_IOCTL_DEV)
/* clang-format on */
@@ -326,6 +332,7 @@ static const char help[] =
"* " ENV_SCOPED_NAME ": actions denied on the outside of the landlock domain\n"
" - \"a\" to restrict opening abstract unix sockets\n"
" - \"s\" to restrict sending signals\n"
+ "* " ENV_UNIX_CONNECT_NAME ": paths of unix sockets connections are allowed to\n"
"\n"
"A sandboxer should not log denied access requests to avoid spamming logs, "
"but to test audit we can set " ENV_FORCE_LOG_NAME "=1\n"
@@ -353,7 +360,7 @@ int main(const int argc, char *const argv[], char *const *const envp)
access_fs_rw = ACCESS_FS_ROUGHLY_READ | ACCESS_FS_ROUGHLY_WRITE;
struct landlock_ruleset_attr ruleset_attr = {
- .handled_access_fs = access_fs_rw,
+ .handled_access_fs = access_fs_rw | LANDLOCK_ACCESS_FS_CONNECT_UNIX,
.handled_access_net = LANDLOCK_ACCESS_NET_BIND_TCP |
LANDLOCK_ACCESS_NET_CONNECT_TCP,
.scoped = LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET |
@@ -460,9 +467,6 @@ int main(const int argc, char *const argv[], char *const *const envp)
"provided by ABI version %d (instead of %d).\n",
abi, LANDLOCK_ABI_LAST);
}
- access_fs_ro &= ruleset_attr.handled_access_fs;
- access_fs_rw &= ruleset_attr.handled_access_fs;
-
/* Removes bind access attribute if not supported by a user. */
env_port_name = getenv(ENV_TCP_BIND_NAME);
if (!env_port_name) {
@@ -476,6 +480,9 @@ int main(const int argc, char *const argv[], char *const *const envp)
~LANDLOCK_ACCESS_NET_CONNECT_TCP;
}
+ access_fs_ro &= ruleset_attr.handled_access_fs;
+ access_fs_rw &= ruleset_attr.handled_access_fs;
+
if (check_ruleset_scope(ENV_SCOPED_NAME, &ruleset_attr))
return 1;
@@ -510,6 +517,11 @@ int main(const int argc, char *const argv[], char *const *const envp)
if (populate_ruleset_fs(ENV_FS_RW_NAME, ruleset_fd, access_fs_rw)) {
goto err_close_ruleset;
}
+ if (getenv(ENV_UNIX_CONNECT_NAME) &&
+ populate_ruleset_fs(ENV_UNIX_CONNECT_NAME, ruleset_fd,
+ LANDLOCK_ACCESS_FS_CONNECT_UNIX)) {
+ goto err_close_ruleset;
+ }
if (populate_ruleset_net(ENV_TCP_BIND_NAME, ruleset_fd,
LANDLOCK_ACCESS_NET_BIND_TCP)) {
--
2.51.0
^ permalink raw reply related
* [RFC PATCH 5/5] landlock: Document LANDLOCK_ACCESS_FS_UNIX_CONNECT
From: Günther Noack @ 2026-01-01 13:41 UTC (permalink / raw)
To: Mickaël Salaün, Paul Moore
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Günther Noack
In-Reply-To: <20260101134102.25938-1-gnoack3000@gmail.com>
Cc: Justin Suess <utilityemal77@gmail.com>
Cc: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Günther Noack <gnoack3000@gmail.com>
---
Documentation/userspace-api/landlock.rst | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst
index 1d0c2c15c22e3..6efb5c51253b0 100644
--- a/Documentation/userspace-api/landlock.rst
+++ b/Documentation/userspace-api/landlock.rst
@@ -77,7 +77,8 @@ to be explicit about the denied-by-default access rights.
LANDLOCK_ACCESS_FS_MAKE_SYM |
LANDLOCK_ACCESS_FS_REFER |
LANDLOCK_ACCESS_FS_TRUNCATE |
- LANDLOCK_ACCESS_FS_IOCTL_DEV,
+ LANDLOCK_ACCESS_FS_IOCTL_DEV |
+ LANDLOCK_ACCESS_FS_UNIX_CONNECT,
.handled_access_net =
LANDLOCK_ACCESS_NET_BIND_TCP |
LANDLOCK_ACCESS_NET_CONNECT_TCP,
@@ -127,6 +128,10 @@ version, and only use the available subset of access rights:
/* Removes LANDLOCK_SCOPE_* for ABI < 6 */
ruleset_attr.scoped &= ~(LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET |
LANDLOCK_SCOPE_SIGNAL);
+ __attribute__((fallthrough));
+ case 7:
+ /* Removes LANDLOCK_ACCESS_FS_UNIX_CONNECT for ABI < 8 */
+ ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_UNIX_CONNECT;
}
This enables the creation of an inclusive ruleset that will contain our rules.
@@ -604,6 +609,13 @@ Landlock audit events with the ``LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF``,
sys_landlock_restrict_self(). See Documentation/admin-guide/LSM/landlock.rst
for more details on audit.
+Pathname UNIX sockets (ABI < 8)
+-------------------------------
+
+Starting with the Landlock ABI version 8, it is possible to restrict
+connections to a pathname :manpage:`unix(7)` socket using the new
+``LANDLOCK_ACCESS_FS_UNIX_CONNECT`` right.
+
.. _kernel_support:
Kernel support
--
2.52.0
^ permalink raw reply related
* [RFC PATCH 4/5] landlock/selftests: test LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Günther Noack @ 2026-01-01 13:41 UTC (permalink / raw)
To: Mickaël Salaün, Paul Moore
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Günther Noack
In-Reply-To: <20260101134102.25938-1-gnoack3000@gmail.com>
* Exercise the LANDLOCK_ACCESS_FS_CONNECT_UNIX access right.
* Extract common helpers from an existing IOCTL test that
also uses pathname unix(7) sockets.
Cc: Justin Suess <utilityemal77@gmail.com>
Cc: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Günther Noack <gnoack3000@gmail.com>
---
tools/testing/selftests/landlock/fs_test.c | 88 +++++++++++++++++-----
1 file changed, 71 insertions(+), 17 deletions(-)
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index 74e975c5e9847..fb5b240bab629 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -4358,30 +4358,58 @@ TEST_F_FORK(layout1, named_pipe_ioctl)
ASSERT_EQ(child_pid, waitpid(child_pid, NULL, 0));
}
+/*
+ * set_up_named_unix_server - Create a pathname unix socket and listen
+ *
+ * Return: The listening FD - it is the caller responsibility to close it.
+ */
+static int set_up_named_unix_server(struct __test_metadata *const _metadata,
+ const char *const path)
+{
+ int fd;
+ struct sockaddr_un addr = {
+ .sun_family = AF_UNIX,
+ };
+
+ ASSERT_EQ(0, unlink(path));
+ fd = socket(AF_UNIX, SOCK_STREAM, 0);
+ ASSERT_LE(0, fd);
+
+ strncpy(addr.sun_path, path, sizeof(addr.sun_path));
+ ASSERT_EQ(0, bind(fd, (struct sockaddr *)&addr, sizeof(addr)));
+
+ ASSERT_EQ(0, listen(fd, 10 /* qlen */));
+ return fd;
+}
+
+/*
+ * test_connect_named_unix - connect to the given named UNIX socket
+ *
+ * Return: The errno from connect(), or 0
+ */
+static int test_connect_named_unix(int fd, const char *const path)
+{
+ struct sockaddr_un addr = {
+ .sun_family = AF_UNIX,
+ };
+ strncpy(addr.sun_path, path, sizeof(addr.sun_path));
+
+ if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) == -1)
+ return errno;
+ return 0;
+}
+
/* For named UNIX domain sockets, no IOCTL restrictions apply. */
TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
{
const char *const path = file1_s1d1;
int srv_fd, cli_fd, ruleset_fd;
- struct sockaddr_un srv_un = {
- .sun_family = AF_UNIX,
- };
- struct sockaddr_un cli_un = {
- .sun_family = AF_UNIX,
- };
const struct landlock_ruleset_attr attr = {
.handled_access_fs = LANDLOCK_ACCESS_FS_IOCTL_DEV,
};
/* Sets up a server */
- ASSERT_EQ(0, unlink(path));
- srv_fd = socket(AF_UNIX, SOCK_STREAM, 0);
- ASSERT_LE(0, srv_fd);
-
- strncpy(srv_un.sun_path, path, sizeof(srv_un.sun_path));
- ASSERT_EQ(0, bind(srv_fd, (struct sockaddr *)&srv_un, sizeof(srv_un)));
-
- ASSERT_EQ(0, listen(srv_fd, 10 /* qlen */));
+ srv_fd = set_up_named_unix_server(_metadata, path);
/* Enables Landlock. */
ruleset_fd = landlock_create_ruleset(&attr, sizeof(attr), 0);
@@ -4393,9 +4421,7 @@ TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
cli_fd = socket(AF_UNIX, SOCK_STREAM, 0);
ASSERT_LE(0, cli_fd);
- strncpy(cli_un.sun_path, path, sizeof(cli_un.sun_path));
- ASSERT_EQ(0,
- connect(cli_fd, (struct sockaddr *)&cli_un, sizeof(cli_un)));
+ ASSERT_EQ(0, test_connect_named_unix(cli_fd, path));
/* FIONREAD and other IOCTLs should not be forbidden. */
EXPECT_EQ(0, test_fionread_ioctl(cli_fd));
@@ -4570,6 +4596,34 @@ TEST_F_FORK(ioctl, handle_file_access_file)
ASSERT_EQ(0, close(file_fd));
}
+TEST_F_FORK(layout1, named_unix_domain_socket)
+{
+ const char *const path = file1_s1d1;
+ int cli_fd, srv_fd, ruleset_fd;
+ const struct landlock_ruleset_attr attr = {
+ .handled_access_fs = LANDLOCK_ACCESS_FS_CONNECT_UNIX,
+ };
+
+ /* Sets up a server */
+ srv_fd = set_up_named_unix_server(_metadata, path);
+
+ /* Enables Landlock. */
+ ruleset_fd = landlock_create_ruleset(&attr, sizeof(attr), 0);
+ ASSERT_LE(0, ruleset_fd);
+ enforce_ruleset(_metadata, ruleset_fd);
+ ASSERT_EQ(0, close(ruleset_fd));
+
+ /* Sets up a client connection to it */
+ cli_fd = socket(AF_UNIX, SOCK_STREAM, 0);
+ ASSERT_LE(0, cli_fd);
+
+ /* Connecting to the Unix socket is denied. */
+ EXPECT_EQ(EACCES, test_connect_named_unix(cli_fd, path));
+
+ ASSERT_EQ(0, close(cli_fd));
+ ASSERT_EQ(0, close(srv_fd));
+}
+
/* clang-format off */
FIXTURE(layout1_bind) {};
/* clang-format on */
--
2.52.0
^ permalink raw reply related
* [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Günther Noack @ 2026-01-01 13:41 UTC (permalink / raw)
To: Mickaël Salaün, Paul Moore
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Günther Noack
In-Reply-To: <20260101134102.25938-1-gnoack3000@gmail.com>
Add unix(7) connect() support to the Landlock sample tool.
The "connect UNIX" right is grouped with the read-write rights in the
sample tool. Rationale: In the general case, any operations are
possible through a Unix domain socket, including data-mutating
operations.
Cc: Justin Suess <utilityemal77@gmail.com>
Cc: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Günther Noack <gnoack3000@gmail.com>
---
samples/landlock/sandboxer.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c
index e7af02f98208b..b24ef317d1ea9 100644
--- a/samples/landlock/sandboxer.c
+++ b/samples/landlock/sandboxer.c
@@ -295,11 +295,12 @@ static bool check_ruleset_scope(const char *const env_var,
LANDLOCK_ACCESS_FS_MAKE_SYM | \
LANDLOCK_ACCESS_FS_REFER | \
LANDLOCK_ACCESS_FS_TRUNCATE | \
- LANDLOCK_ACCESS_FS_IOCTL_DEV)
+ LANDLOCK_ACCESS_FS_IOCTL_DEV | \
+ LANDLOCK_ACCESS_FS_CONNECT_UNIX)
/* clang-format on */
-#define LANDLOCK_ABI_LAST 7
+#define LANDLOCK_ABI_LAST 8
#define XSTR(s) #s
#define STR(s) XSTR(s)
@@ -444,6 +445,12 @@ int main(const int argc, char *const argv[], char *const *const envp)
"provided by ABI version %d (instead of %d).\n",
LANDLOCK_ABI_LAST, abi);
__attribute__((fallthrough));
+ case 7:
+ /* Removes LANDLOCK_ACCESS_FS_CONNECT_UNIX for ABI < 8 */
+ ruleset_attr.handled_access_fs &=
+ ~LANDLOCK_ACCESS_FS_CONNECT_UNIX;
+
+ __attribute__((fallthrough));
case LANDLOCK_ABI_LAST:
break;
default:
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox