[RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Günther Noack]

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/20251231213314.2979118-1-utilityemal77@gmail.com/

I am keeping this tagged as "RFC" since Justin's patch is RFC as well
so far.

The original feature request is at [4].

## Alternatives and Related Work

### Alternative: Use existing LSM hooks

The existing hooks security_unix_stream_connect(),
security_unix_may_send() and security_socket_connect() do not give
access to the resolved file system path.

Resolving the file system path again within Landlock would in my
understanding produce a TOCTOU race, so making the decision based on
the struct sockaddr_un contents is not an option.

It is tempting to use the struct path that the listening socket is
bound to, which can be acquired through the existing hooks.
Unfortunately, the listening socket may have been bound from within a
different namespace, and it is therefore a path that can not actually
be referenced by the sandboxed program at the time of constructing the
Landlock policy.  (More details are on the Github issue at [6]).

### Related work: Scope Control for Pathname Unix Sockets

The motivation for this patch is the same as in Tingmao Wang's patch
set for "scoped" control for pathname Unix sockets [2], originally
proposed in the Github feature request [5].

In my reply to this patch set [3], I have discussed the differences
between these two approaches.  On the related discussions on Github
[4] and [5], there was consensus that the scope-based control is
complimentary to the file system based control, but does not replace
it.  Mickael's opening remark on [5] says:

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

## Credits

The feature was originally suggested by Jann Horn in [7].

Tingmao Wang and Demi Marie Obenour have taken the initiative to
revive this discussion again in [1], [4] and [5] and Tingmao Wang has
sent the patch set for the scoped access control for pathname Unix
sockets [2].

Justin Suess has sent the patch for the LSM hook in [8].

Ryan Sullivan has started on an initial implementation and has brought
up relevant discussion points on the Github issue at [4] that lead to
the current approach.

[1] https://lore.kernel.org/landlock/515ff0f4-2ab3-46de-8d1e-5c66a93c6ede@gmail.com/
[2] Tingmao Wang's "Implemnet scope control for pathname Unix sockets"
    https://lore.kernel.org/all/cover.1767115163.git.m@maowtm.org/
[3] https://lore.kernel.org/all/20251230.bcae69888454@gnoack.org/
[4] Github issue for FS-based control for named Unix sockets:
    https://github.com/landlock-lsm/linux/issues/36
[5] Github issue for scope-based restriction of named Unix sockets:
    https://github.com/landlock-lsm/linux/issues/51
[6] https://github.com/landlock-lsm/linux/issues/36#issuecomment-2950632277
[7] https://lore.kernel.org/linux-security-module/CAG48ez3NvVnonOqKH4oRwRqbSOLO0p9djBqgvxVwn6gtGQBPcw@mail.gmail.com/
[8] Patch for the LSM hook:
    https://lore.kernel.org/linux-security-module/CAG48ez3NvVnonOqKH4oRwRqbSOLO0p9djBqgvxVwn6gtGQBPcw@mail.gmail.com/

Günther Noack (5):
  landlock/selftests: add a missing close(srv_fd) call
  landlock: Control connections to pathname UNIX sockets by path
  samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
  landlock/selftests: test LANDLOCK_ACCESS_FS_CONNECT_UNIX
  landlock: Document LANDLOCK_ACCESS_FS_UNIX_CONNECT

 Documentation/userspace-api/landlock.rst     | 14 ++-
 include/uapi/linux/landlock.h                |  3 +
 samples/landlock/sandboxer.c                 | 11 ++-
 security/landlock/access.h                   |  2 +-
 security/landlock/audit.c                    |  1 +
 security/landlock/fs.c                       |  9 +-
 security/landlock/limits.h                   |  2 +-
 security/landlock/syscalls.c                 |  2 +-
 tools/testing/selftests/landlock/base_test.c |  2 +-
 tools/testing/selftests/landlock/fs_test.c   | 94 ++++++++++++++++----
 10 files changed, 113 insertions(+), 27 deletions(-)

-- 
2.52.0

[RFC PATCH 1/5] landlock/selftests: add a missing close(srv_fd) call

[Günther Noack]

Signed-off-by: Günther Noack <gnoack3000@gmail.com>
---
 tools/testing/selftests/landlock/fs_test.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index 37a5a3df712ec..16503f2e6a481 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -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 */
-- 
2.52.0

[RFC PATCH 2/5] landlock: Control connections to pathname UNIX sockets by path

[Günther Noack]

* Add the LANDLOCK_ACCESS_FS_CONNECT_UNIX right.
* Hook into the path lookup in unix_find_bsd() in af_unix.c,
  using a LSM hook.  Decide based on the new access right.
* Increment the Landlock ABI version.
* Minor test adaptions to keep the tests working.

Cc: Justin Suess <utilityemal77@gmail.com>
Cc: Mickaël Salaün <mic@digikod.net>
Suggested-by: Jann Horn <jannh@google.com>
Link: https://github.com/landlock-lsm/linux/issues/36
Signed-off-by: Günther Noack <gnoack3000@gmail.com>
---
 include/uapi/linux/landlock.h                | 3 +++
 security/landlock/access.h                   | 2 +-
 security/landlock/audit.c                    | 1 +
 security/landlock/fs.c                       | 9 ++++++++-
 security/landlock/limits.h                   | 2 +-
 security/landlock/syscalls.c                 | 2 +-
 tools/testing/selftests/landlock/base_test.c | 2 +-
 tools/testing/selftests/landlock/fs_test.c   | 5 +++--
 8 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
index f030adc462ee7..189a6e3bbac05 100644
--- a/include/uapi/linux/landlock.h
+++ b/include/uapi/linux/landlock.h
@@ -216,6 +216,8 @@ struct landlock_net_port_attr {
  *   :manpage:`ftruncate(2)`, :manpage:`creat(2)`, or :manpage:`open(2)` with
  *   ``O_TRUNC``.  This access right is available since the third version of the
  *   Landlock ABI.
+ * - %LANDLOCK_ACCESS_FS_CONNECT_UNIX: Connect to named :manpage:`unix(7)`
+ *    socket files.
  *
  * Whether an opened file can be truncated with :manpage:`ftruncate(2)` or used
  * with `ioctl(2)` is determined during :manpage:`open(2)`, in the same way as
@@ -321,6 +323,7 @@ struct landlock_net_port_attr {
 #define LANDLOCK_ACCESS_FS_REFER			(1ULL << 13)
 #define LANDLOCK_ACCESS_FS_TRUNCATE			(1ULL << 14)
 #define LANDLOCK_ACCESS_FS_IOCTL_DEV			(1ULL << 15)
+#define LANDLOCK_ACCESS_FS_CONNECT_UNIX			(1ULL << 16)
 /* clang-format on */
 
 /**
diff --git a/security/landlock/access.h b/security/landlock/access.h
index 7961c6630a2d7..c7784922be3ca 100644
--- a/security/landlock/access.h
+++ b/security/landlock/access.h
@@ -34,7 +34,7 @@
 	LANDLOCK_ACCESS_FS_IOCTL_DEV)
 /* clang-format on */
 
-typedef u16 access_mask_t;
+typedef u32 access_mask_t;
 
 /* Makes sure all filesystem access rights can be stored. */
 static_assert(BITS_PER_TYPE(access_mask_t) >= LANDLOCK_NUM_ACCESS_FS);
diff --git a/security/landlock/audit.c b/security/landlock/audit.c
index e899995f1fd59..1a937cbdca7af 100644
--- a/security/landlock/audit.c
+++ b/security/landlock/audit.c
@@ -37,6 +37,7 @@ static const char *const fs_access_strings[] = {
 	[BIT_INDEX(LANDLOCK_ACCESS_FS_REFER)] = "fs.refer",
 	[BIT_INDEX(LANDLOCK_ACCESS_FS_TRUNCATE)] = "fs.truncate",
 	[BIT_INDEX(LANDLOCK_ACCESS_FS_IOCTL_DEV)] = "fs.ioctl_dev",
+	[BIT_INDEX(LANDLOCK_ACCESS_FS_CONNECT_UNIX)] = "fs.connect_unix",
 };
 
 static_assert(ARRAY_SIZE(fs_access_strings) == LANDLOCK_NUM_ACCESS_FS);
diff --git a/security/landlock/fs.c b/security/landlock/fs.c
index 8205673c8b1c4..e8cecbd7f2490 100644
--- a/security/landlock/fs.c
+++ b/security/landlock/fs.c
@@ -314,7 +314,8 @@ static struct landlock_object *get_inode_object(struct inode *const inode)
 	LANDLOCK_ACCESS_FS_WRITE_FILE | \
 	LANDLOCK_ACCESS_FS_READ_FILE | \
 	LANDLOCK_ACCESS_FS_TRUNCATE | \
-	LANDLOCK_ACCESS_FS_IOCTL_DEV)
+	LANDLOCK_ACCESS_FS_IOCTL_DEV | \
+	LANDLOCK_ACCESS_FS_CONNECT_UNIX)
 /* clang-format on */
 
 /*
@@ -1588,6 +1589,11 @@ static int hook_path_truncate(const struct path *const path)
 	return current_check_access_path(path, LANDLOCK_ACCESS_FS_TRUNCATE);
 }
 
+static int hook_unix_path_connect(const struct path *const path)
+{
+	return current_check_access_path(path, LANDLOCK_ACCESS_FS_CONNECT_UNIX);
+}
+
 /* File hooks */
 
 /**
@@ -1872,6 +1878,7 @@ static struct security_hook_list landlock_hooks[] __ro_after_init = {
 	LSM_HOOK_INIT(path_unlink, hook_path_unlink),
 	LSM_HOOK_INIT(path_rmdir, hook_path_rmdir),
 	LSM_HOOK_INIT(path_truncate, hook_path_truncate),
+	LSM_HOOK_INIT(unix_path_connect, hook_unix_path_connect),
 
 	LSM_HOOK_INIT(file_alloc_security, hook_file_alloc_security),
 	LSM_HOOK_INIT(file_open, hook_file_open),
diff --git a/security/landlock/limits.h b/security/landlock/limits.h
index 65b5ff0516747..5928d538d8115 100644
--- a/security/landlock/limits.h
+++ b/security/landlock/limits.h
@@ -19,7 +19,7 @@
 #define LANDLOCK_MAX_NUM_LAYERS		16
 #define LANDLOCK_MAX_NUM_RULES		U32_MAX
 
-#define LANDLOCK_LAST_ACCESS_FS		LANDLOCK_ACCESS_FS_IOCTL_DEV
+#define LANDLOCK_LAST_ACCESS_FS		LANDLOCK_ACCESS_FS_CONNECT_UNIX
 #define LANDLOCK_MASK_ACCESS_FS		((LANDLOCK_LAST_ACCESS_FS << 1) - 1)
 #define LANDLOCK_NUM_ACCESS_FS		__const_hweight64(LANDLOCK_MASK_ACCESS_FS)
 
diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
index 0116e9f93ffe3..66fd196be85a8 100644
--- a/security/landlock/syscalls.c
+++ b/security/landlock/syscalls.c
@@ -161,7 +161,7 @@ static const struct file_operations ruleset_fops = {
  * Documentation/userspace-api/landlock.rst should be updated to reflect the
  * UAPI change.
  */
-const int landlock_abi_version = 7;
+const int landlock_abi_version = 8;
 
 /**
  * sys_landlock_create_ruleset - Create a new ruleset
diff --git a/tools/testing/selftests/landlock/base_test.c b/tools/testing/selftests/landlock/base_test.c
index 7b69002239d7e..f4b1a275d8d96 100644
--- a/tools/testing/selftests/landlock/base_test.c
+++ b/tools/testing/selftests/landlock/base_test.c
@@ -76,7 +76,7 @@ TEST(abi_version)
 	const struct landlock_ruleset_attr ruleset_attr = {
 		.handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE,
 	};
-	ASSERT_EQ(7, landlock_create_ruleset(NULL, 0,
+	ASSERT_EQ(8, landlock_create_ruleset(NULL, 0,
 					     LANDLOCK_CREATE_RULESET_VERSION));
 
 	ASSERT_EQ(-1, landlock_create_ruleset(&ruleset_attr, 0,
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index 16503f2e6a481..74e975c5e9847 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -575,9 +575,10 @@ TEST_F_FORK(layout1, inval)
 	LANDLOCK_ACCESS_FS_WRITE_FILE | \
 	LANDLOCK_ACCESS_FS_READ_FILE | \
 	LANDLOCK_ACCESS_FS_TRUNCATE | \
-	LANDLOCK_ACCESS_FS_IOCTL_DEV)
+	LANDLOCK_ACCESS_FS_IOCTL_DEV | \
+	LANDLOCK_ACCESS_FS_CONNECT_UNIX)
 
-#define ACCESS_LAST LANDLOCK_ACCESS_FS_IOCTL_DEV
+#define ACCESS_LAST LANDLOCK_ACCESS_FS_CONNECT_UNIX
 
 #define ACCESS_ALL ( \
 	ACCESS_FILE | \
-- 
2.52.0

[RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Günther Noack]

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

[RFC PATCH 4/5] landlock/selftests: test LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Günther Noack]

* 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

[RFC PATCH 5/5] landlock: Document LANDLOCK_ACCESS_FS_UNIX_CONNECT

[Günther Noack]

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

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Justin Suess]

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

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Tingmao Wang]

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.

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Demi Marie Obenour]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Demi Marie Obenour]

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

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Tingmao Wang]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Tingmao Wang]

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

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Demi Marie Obenour]

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

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Justin Suess]

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

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Demi Marie Obenour]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Demi Marie Obenour]

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

Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Günther Noack]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Günther Noack]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Günther Noack]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Demi Marie Obenour]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Günther Noack]

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

Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 2393 bytes --]

On 1/2/26 05:50, Günther Noack wrote:
> 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'm not familiar with existing LSM hooks, but I do know that SELinux
enforces checks on searching and reading directories and symlinks.

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

I think so too!
-- 
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 --]