landlock: Pathname-based UNIX connect() control

This scoping would be complementary to #36 which would mainly be about allowing a sandboxed process to connect to a more privileged service (identified with a path).

Signed-off-by Günther Noack <[email protected]>

---
 tools/testing/selftests/landlock/fs_test.c | 1 +
 1 file changed, 1 insertion(+)

tools/testing/selftests/landlock/fs_test.c +1 -0

index 37a5a3df712ec..16503f2e6a481 100644
@@ -4400,6 +4400,7 @@ TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
 	EXPECT_EQ(0, test_fionread_ioctl(cli_fd));
 
 	ASSERT_EQ(0, close(cli_fd));
+	ASSERT_EQ(0, close(srv_fd));
 }
 
 /* clang-format off */

Signature · 1 line

2.52.0

Good, I'll pick that in my -next branch.

Nit: The prefix should be "selftests/landlock"

Quoted 12 lines · Günther Noack

Signed-off-by Günther Noack <[email protected]>

---
 tools/testing/selftests/landlock/fs_test.c | 1 +
 1 file changed, 1 insertion(+)

tools/testing/selftests/landlock/fs_test.c +0 -0

index 37a5a3df712ec..16503f2e6a481 100644
@@ -4400,6 +4400,7 @@ TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
 	EXPECT_EQ(0, test_fionread_ioctl(cli_fd));
 

tools/testing/selftests/landlock/fs_test.c TEST_F_FORK(layout1, named_unix_domain_socket_ioctl) · line 4403

Quoted 2 lines

tools/testing/selftests/landlock/fs_test.c +1 -0

 	ASSERT_EQ(0, close(cli_fd));
+	ASSERT_EQ(0, close(srv_fd));

Quoted 7 lines

tools/testing/selftests/landlock/fs_test.c +0 -0

 }
 
 /* clang-format off */

Signature · 1 line

2.52.0

Quoted 17 lines · Mickaël Salaün

Good, I'll pick that in my -next branch.

Nit: The prefix should be "selftests/landlock"

Quoted 12 lines · Günther Noack

Signed-off-by Günther Noack <[email protected]>

---
 tools/testing/selftests/landlock/fs_test.c | 1 +
 1 file changed, 1 insertion(+)

tools/testing/selftests/landlock/fs_test.c +0 -0

index 37a5a3df712ec..16503f2e6a481 100644
@@ -4400,6 +4400,7 @@ TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
 	EXPECT_EQ(0, test_fionread_ioctl(cli_fd));
 

Quoted 2 lines

tools/testing/selftests/landlock/fs_test.c TEST_F_FORK(layout1, named_unix_domain_socket_ioctl) · line 4403

Quoted 2 lines

tools/testing/selftests/landlock/fs_test.c +1 -0

 	ASSERT_EQ(0, close(cli_fd));
+	ASSERT_EQ(0, close(srv_fd));

I'll also replace these ASSERT_EQ() with EXPECT_EQ().

Quoted 18 lines · Mickaël Salaün

Quoted 17 lines · Mickaël Salaün

Good, I'll pick that in my -next branch.

Nit: The prefix should be "selftests/landlock"

Quoted 12 lines · Günther Noack

Signed-off-by Günther Noack <[email protected]>

---
 tools/testing/selftests/landlock/fs_test.c | 1 +
 1 file changed, 1 insertion(+)

tools/testing/selftests/landlock/fs_test.c +0 -0

index 37a5a3df712ec..16503f2e6a481 100644
@@ -4400,6 +4400,7 @@ TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
 	EXPECT_EQ(0, test_fionread_ioctl(cli_fd));
 

Quoted 4 lines

Quoted 2 lines

tools/testing/selftests/landlock/fs_test.c TEST_F_FORK(layout1, named_unix_domain_socket_ioctl) · line 4403

Quoted 2 lines

tools/testing/selftests/landlock/fs_test.c +1 -0

 	ASSERT_EQ(0, close(cli_fd));
+	ASSERT_EQ(0, close(srv_fd));

I'll also replace these ASSERT_EQ() with EXPECT_EQ().

Fair enough. I would normally prefer ASSERT here, because that would be more symmetric with the corresponding setup steps, but it feels not worth bikeshedding over this.

The selftests, both Landlock and others, are inconsistent in how they use ASSERT and EXPECT, especially for close().

I wish we had an
easier way to do state teardown in the selftests without having to tie it to a FIXTURE()...

–Günther

Allow users to separately specify unix socket rights, document the variable, and make the right optional.

Signed-off-by Justin Suess <[email protected]>

Cc Günther Noack <[email protected]>

---

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

samples/landlock/sandboxer.c +1 -0

index b24ef317d1ea..3df7e7c8b6f1 100644
@@ -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;

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.

On 1/1/26 17:07, Tingmao Wang wrote:

(snip)

Quoted 8 lines

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.

Quoted 13 lines · Demi Marie Obenour

On 1/1/26 17:07, Tingmao Wang wrote:

(snip)

Quoted 8 lines

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.

Quoted 5 lines

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.))

Quoted 12 lines · Demi Marie Obenour

On 1/1/26 17:07, Tingmao Wang wrote:

(snip)

Quoted 8 lines

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.

Quoted 5 lines

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.))

Quoted 18 lines · Tingmao Wang

Quoted 17 lines · Demi Marie Obenour

On 1/1/26 17:07, Tingmao Wang wrote:

(snip)

Quoted 8 lines

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.

Quoted 6 lines

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).

Quoted 21 lines · Justin Suess

Quoted 20 lines · Tingmao Wang

Quoted 12 lines · Demi Marie Obenour

On 1/1/26 17:07, Tingmao Wang wrote:

(snip)

Quoted 8 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

Quoted 4 lines

(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.

Quoted 5 lines

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.

Quoted 22 lines · Demi Marie Obenour

Quoted 21 lines · Justin Suess

Quoted 20 lines · Tingmao Wang

Quoted 12 lines · Demi Marie Obenour

On 1/1/26 17:07, Tingmao Wang wrote:

(snip)

Quoted 8 lines

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.

Quoted 5 lines

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.

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

(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.

Quoted 7 lines

Quoted 5 lines

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.)

Allow users to separately specify unix socket rights, document the variable, and make the right optional.

Signed-off-by Justin Suess <[email protected]>

Cc Günther Noack <[email protected]>

Happy New Year!

This patch set introduces a file-system-based Landlock restriction mechanism for connecting to Unix sockets.

[...]
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.

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 4 lines

(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?

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.)

Quoted 8 lines · Günther Noack

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

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 24 lines · Günther Noack

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 6 lines

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.

Quoted 32 lines · Demi Marie Obenour

Quoted 30 lines · Günther Noack

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 2 lines

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.

Quoted 36 lines · Günther Noack

Quoted 34 lines · Demi Marie Obenour

Quoted 24 lines · Günther Noack

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 6 lines

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.

Quoted 4 lines

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'm not familiar with existing LSM hooks, but I do know that SELinux enforces checks on searching and reading directories and symlinks.

Quoted 3 lines

I take it back then. :) If there is prior art, implementing this might be more feasible than I thought.

I think so too!

Signature · 2 lines

Sincerely,
Demi Marie Obenour (she/her/hers)

Quoted 42 lines · Demi Marie Obenour

Quoted 40 lines · Günther Noack

Quoted 32 lines · Demi Marie Obenour

Quoted 24 lines · Günther Noack

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 6 lines

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.

Quoted 2 lines

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?

Quoted 2 lines

I'm not familiar with existing LSM hooks, but I do know that SELinux enforces checks on searching and reading directories and symlinks.

SELinux uses inode-based hooks, which is not (directly) possible for Landlock because it is an unprivileged access control, which means it cannot rely on extended file attributes to define a security policy.

See https://github.com/landlock-lsm/linux/issues/9

Quoted 46 lines · Mickaël Salaün

Quoted 44 lines · Demi Marie Obenour

Quoted 33 lines · Günther Noack

Quoted 32 lines · Demi Marie Obenour

Quoted 30 lines · Günther Noack

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 7 lines

Quoted 2 lines

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'm not familiar with existing LSM hooks, but I do know that SELinux enforces checks on searching and reading directories and symlinks.

Quoted 5 lines

SELinux uses inode-based hooks, which is not (directly) possible for Landlock because it is an unprivileged access control, which means it cannot rely on extended file attributes to define a security policy.

See https://github.com/landlock-lsm/linux/issues/9

Could Landlock use a side table, with the inode's address in memory as the key?

Quoted 51 lines · Demi Marie Obenour

Quoted 50 lines · Mickaël Salaün

Quoted 37 lines · Demi Marie Obenour

Quoted 36 lines · Günther Noack

Quoted 34 lines · Demi Marie Obenour

Quoted 24 lines · Günther Noack

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 6 lines

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.

Quoted 7 lines

Quoted 4 lines

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'm not familiar with existing LSM hooks, but I do know that SELinux enforces checks on searching and reading directories and symlinks.

SELinux uses inode-based hooks, which is not (directly) possible for Landlock because it is an unprivileged access control, which means it cannot rely on extended file attributes to define a security policy.

Quoted 4 lines

Quoted 1 line

See https://github.com/landlock-lsm/linux/issues/9

Could Landlock use a side table, with the inode's address in memory as the key?

A struct inode is not enough because we need to resolve a file hierarchy, which is only possible with a struct path.

Quoted 54 lines · Mickaël Salaün

Quoted 53 lines · Demi Marie Obenour

Quoted 51 lines · Mickaël Salaün

Quoted 37 lines · Demi Marie Obenour

Quoted 36 lines · Günther Noack

Quoted 34 lines · Demi Marie Obenour

Quoted 24 lines · Günther Noack

Quoted 10 lines · Demi Marie Obenour

Quoted 9 lines · Tingmao Wang

Quoted 4 lines · Demi Marie Obenour

[...]
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

Quoted 6 lines

Quoted 4 lines

(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.

Quoted 6 lines

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.

Quoted 7 lines

Quoted 4 lines

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'm not familiar with existing LSM hooks, but I do know that SELinux enforces checks on searching and reading directories and symlinks.

SELinux uses inode-based hooks, which is not (directly) possible for Landlock because it is an unprivileged access control, which means it cannot rely on extended file attributes to define a security policy.

See https://github.com/landlock-lsm/linux/issues/9

Quoted 5 lines

Quoted 2 lines

Could Landlock use a side table, with the inode's address in memory as the key?

A struct inode is not enough because we need to resolve a file hierarchy, which is only possible with a struct path.

Could Landlock "piggyback" on the core kernel's own path resolution, updating its state when each hook gets called?

Happy New Year!

This patch set introduces a file-system-based Landlock restriction mechanism for connecting to Unix sockets.

## Motivation

Currently, landlocked processes can connect() to named UNIX sockets through the BSD socket API described in unix(7), by invoking socket(2) followed by connect(2) with a suitable struct sockname_un holding the socket's filename. This can come as a surprise for users (e.g. in [1]) and it can be used to escape a sandbox when a Unix service offers command execution (some scenarios were listed by Tingmao Wang in [2]).

These patches are built on Justin Suess's patch which adds the LSM hook:
https://lore.kernel.org/all/[email protected]/

Quoted 9 lines · Günther Noack

## Motivation

Currently, landlocked processes can connect() to named UNIX sockets through the BSD socket API described in unix(7), by invoking socket(2) followed by connect(2) with a suitable struct sockname_un holding the socket's filename. This can come as a surprise for users (e.g. in [1]) and it can be used to escape a sandbox when a Unix service offers command execution (some scenarios were listed by Tingmao Wang in [2]).

Quoted 3 lines

These patches are built on Justin Suess's patch which adds the LSM hook:
https://lore.kernel.org/all/[email protected]/

As Kuniyuki pointed out [1], we should handle both connect and send. This would be similar to the scoped restriction from Tingmao. I guess we'll need a similar hook for the send operation. Because there is no need to differenciate between connected and disconnected unix socket in a security policy, we should have one access right for both. Any proposal for its name? Something like TRANSMIT_UNIX or EMIT_UNIX?

[1] https://lore.kernel.org/all/CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com/

Quoted 14 lines · Mickaël Salaün

Quoted 9 lines · Günther Noack

## Motivation

Currently, landlocked processes can connect() to named UNIX sockets through the BSD socket API described in unix(7), by invoking socket(2) followed by connect(2) with a suitable struct sockname_un holding the socket's filename. This can come as a surprise for users (e.g. in [1]) and it can be used to escape a sandbox when a Unix service offers command execution (some scenarios were listed by Tingmao Wang in [2]).

Quoted 3 lines

These patches are built on Justin Suess's patch which adds the LSM hook:
https://lore.kernel.org/all/[email protected]/

Quoted 8 lines

As Kuniyuki pointed out [1], we should handle both connect and send. This would be similar to the scoped restriction from Tingmao. I guess we'll need a similar hook for the send operation. Because there is no need to differenciate between connected and disconnected unix socket in a security policy, we should have one access right for both. Any proposal for its name? Something like TRANSMIT_UNIX or EMIT_UNIX?

[1] https://lore.kernel.org/all/CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com/

Ah, thanks for pointing it out.

The restriction as implemented in this patch set already solves this for all the three cases where a Unix socket file is looked up. I believe that it is happening in all the right times (everytime when the lookup has to happen).

The cases where the restriction applies are the following:

* unix_stream_connect - when calling connect() on a stream socket
* unix_dgram_connect - when calling connect() on a dgram socket
* unix_dgram_sendmsg - when calling sendmsg() on a dgram socket (per-message lookup only)

You can find the code locations by looking for the call to unix_find_other() in af_unix.c. (That function invokes either unix_find_bsd() or the lookup for abstract Unix sockets.)

In the unix_dgram_sendmsg() case, the lookup is only performed if an explicit sockaddr_un was provided together with the arguments to the sendmsg(). (And sendto(2) also uses the same code path as sendmsg(2).)

It is true that the current name for the access right is slightly misleading. How about LANDLOCK_ACCESS_FS_UNIX_SEND? (Like "transmit", but a bit closer to the naming of the sendmsg(2) networking API?)

(I guess the other alternative would be to wire the socket type information through to the unix_find_bsd() function and pass it through. Would require a small change to the af_unix.c implementation, but then we could tell apart LANDLOCK_ACCESS_FS_UNIX_STREAM_CONNECT and LANDLOCK_ACCESS_FS_UNIX_DGRAM_SEND). WDYT?

Quoted 28 lines · Günther Noack

Quoted 8 lines · Mickaël Salaün

As Kuniyuki pointed out [1], we should handle both connect and send. This would be similar to the scoped restriction from Tingmao. I guess we'll need a similar hook for the send operation. Because there is no need to differenciate between connected and disconnected unix socket in a security policy, we should have one access right for both. Any proposal for its name? Something like TRANSMIT_UNIX or EMIT_UNIX?

[1] https://lore.kernel.org/all/CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com/

Ah, thanks for pointing it out.

The restriction as implemented in this patch set already solves this for all the three cases where a Unix socket file is looked up. I believe that it is happening in all the right times (everytime when the lookup has to happen).

The cases where the restriction applies are the following:

* unix_stream_connect - when calling connect() on a stream socket
* unix_dgram_connect - when calling connect() on a dgram socket
* unix_dgram_sendmsg - when calling sendmsg() on a dgram socket (per-message lookup only)

You can find the code locations by looking for the call to unix_find_other() in af_unix.c. (That function invokes either unix_find_bsd() or the lookup for abstract Unix sockets.)

Quoted 4 lines

In the unix_dgram_sendmsg() case, the lookup is only performed if an explicit sockaddr_un was provided together with the arguments to the sendmsg(). (And sendto(2) also uses the same code path as sendmsg(2).)

Great

Quoted 4 lines

It is true that the current name for the access right is slightly misleading. How about LANDLOCK_ACCESS_FS_UNIX_SEND? (Like "transmit", but a bit closer to the naming of the sendmsg(2) networking API?)

We should try to keep the access right naming consistent:
LANDLOCK_ACCESS_FS_<VERB>[_NOUN]

What about USE_UNIX, or FIND_UNIX (closer to the kernel function), or RESOLVE_UNIX? It should be clear with the name that it is not about listening nor receiving from a process outside of the sandbox (which should have its own access right BTW).

Quoted 5 lines

(I guess the other alternative would be to wire the socket type information through to the unix_find_bsd() function and pass it through. Would require a small change to the af_unix.c implementation, but then we could tell apart LANDLOCK_ACCESS_FS_UNIX_STREAM_CONNECT and LANDLOCK_ACCESS_FS_UNIX_DGRAM_SEND). WDYT?

I think the hook should have the same arguments as unix_find_bsd()'s ones. This gives the full context of the call.