[PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run index d2bf78cefc3837b5d5369dbab819606e71bf1fc5..c3d67b6520d490c71bdce0f1056b2960115108b3 100755 --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run @@ -12,4 +12,12 @@ s6-ipcserver-socketbinder -a 0700 /run/vm/by-id/${VM}/vsock_219 if { fdmove 1 3 echo } fdclose 3 +unshare -inu -- +setpriv + --landlock-access fs + --landlock-rule path-beneath:read-file,execute:/nix/store + --landlock-rule path-beneath:read-file,execute:/usr/bin + --landlock-rule path-beneath:read-file,execute:/usr/lib + --landlock-rule path-beneath:read-file:/run/vm/by-id/${VM}/portal-bus + -- xdg-desktop-portal-spectrum-host --- base-commit: 59cda41acc455513cf9936e99b8d97647955ac07 change-id: 20251212-sandbox-dbus-portal-4f98ba29c23a -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything? And wouldn't it make more sense to implement this inside the program itself, since it's code we control that will only ever run on Spectrum? That way it could even drop privileges after they're no longer needed, perhaps. There's a nice landlock Rust crate that's already used by Cloud Hypervisor.
diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run index d2bf78cefc3837b5d5369dbab819606e71bf1fc5..c3d67b6520d490c71bdce0f1056b2960115108b3 100755 --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run @@ -12,4 +12,12 @@ s6-ipcserver-socketbinder -a 0700 /run/vm/by-id/${VM}/vsock_219 if { fdmove 1 3 echo } fdclose 3
+unshare -inu -- +setpriv + --landlock-access fs + --landlock-rule path-beneath:read-file,execute:/nix/store + --landlock-rule path-beneath:read-file,execute:/usr/bin + --landlock-rule path-beneath:read-file,execute:/usr/lib + --landlock-rule path-beneath:read-file:/run/vm/by-id/${VM}/portal-bus + -- xdg-desktop-portal-spectrum-host
--- base-commit: 59cda41acc455513cf9936e99b8d97647955ac07 change-id: 20251212-sandbox-dbus-portal-4f98ba29c23a
-- Sincerely, Demi Marie Obenour (she/her/hers)
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected. The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
And wouldn't it make more sense to implement this inside the program itself, since it's code we control that will only ever run on Spectrum? That way it could even drop privileges after they're no longer needed, perhaps. There's a nice landlock Rust crate that's already used by Cloud Hypervisor.
It definitely does make far more sense to use Landlock from within the process itself. That should allow dropping all filesystem and network access.
diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run index d2bf78cefc3837b5d5369dbab819606e71bf1fc5..c3d67b6520d490c71bdce0f1056b2960115108b3 100755 --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/xdg-desktop-portal-spectrum-host/run @@ -12,4 +12,12 @@ s6-ipcserver-socketbinder -a 0700 /run/vm/by-id/${VM}/vsock_219 if { fdmove 1 3 echo } fdclose 3
+unshare -inu -- +setpriv + --landlock-access fs + --landlock-rule path-beneath:read-file,execute:/nix/store + --landlock-rule path-beneath:read-file,execute:/usr/bin + --landlock-rule path-beneath:read-file,execute:/usr/lib + --landlock-rule path-beneath:read-file:/run/vm/by-id/${VM}/portal-bus + -- xdg-desktop-portal-spectrum-host
--- base-commit: 59cda41acc455513cf9936e99b8d97647955ac07 change-id: 20251212-sandbox-dbus-portal-4f98ba29c23a
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry! I will still go ahead with doing this in the program though, since I already got that far.
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`. I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I will still go ahead with doing this in the program though, since I already got that far.
Would it make sense to connect to the sockets and then block connect() and friends using seccomp? -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I will still go ahead with doing this in the program though, since I already got that far.
Would it make sense to connect to the sockets and then block connect() and friends using seccomp?
I'm not sure it's worth it. There's not a lot else to connect to and I expect we'll be able to do this with landlock at some point.
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I don't find it that surprising given the way landlock works. "connect" (to a non-abstract AF_UNIX socket) is not an operation there's a landlock action for, and it's not like the other actions care about access to parent directories and the like — I was able to execute a program via a symlink after only giving access to the symlink's target, without any access to the directory containing the symlink or the symlink itself, for example. Landlock, as I understand it, is intended to block a specified set of operations (on particular file hierarchies), rather than to completely prevent access to those hierarchies like permissions or mount namespaces could, so the lack of a way to block connecting to a socket is more of a missing feature than a security hole.
On 12/13/25 20:39, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
It is quite possible that these Landlock rules are unnecessarily permissive, but all of the paths to which read and execute access is granted are part of the root filesystem and therefore assumed to be public knowledge. Removing access from any of them would only increase the risk of accidental breakage in the future, and would not provide any security improvements. seccomp *could* provide some improvements, but the effort needed is too high for now.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I don't find it that surprising given the way landlock works. "connect" (to a non-abstract AF_UNIX socket) is not an operation there's a landlock action for, and it's not like the other actions care about access to parent directories and the like — I was able to execute a program via a symlink after only giving access to the symlink's target, without any access to the directory containing the symlink or the symlink itself, for example. Landlock, as I understand it, is intended to block a specified set of operations (on particular file hierarchies), rather than to completely prevent access to those hierarchies like permissions or mount namespaces could, so the lack of a way to block connecting to a socket is more of a missing feature than a security hole.
'man 7 unix' states: On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket. Landlock is definitely being inconsistent with DAC here. Also, this allows real-world sandbox breakouts. On systemd systems, the simplest way to escape is to use systemd-run to execute arbitrary commands. -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 20:39, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
> It is quite possible that these Landlock rules are unnecessarily > permissive, but all of the paths to which read and execute access is > granted are part of the root filesystem and therefore assumed to be > public knowledge. Removing access from any of them would only increase > the risk of accidental breakage in the future, and would not provide any > security improvements. seccomp *could* provide some improvements, but > the effort needed is too high for now. > > Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> > --- > .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ > 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I don't find it that surprising given the way landlock works. "connect" (to a non-abstract AF_UNIX socket) is not an operation there's a landlock action for, and it's not like the other actions care about access to parent directories and the like — I was able to execute a program via a symlink after only giving access to the symlink's target, without any access to the directory containing the symlink or the symlink itself, for example. Landlock, as I understand it, is intended to block a specified set of operations (on particular file hierarchies), rather than to completely prevent access to those hierarchies like permissions or mount namespaces could, so the lack of a way to block connecting to a socket is more of a missing feature than a security hole.
'man 7 unix' states:
On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket.
Landlock is definitely being inconsistent with DAC here. Also, this allows real-world sandbox breakouts. On systemd systems, the simplest way to escape is to use systemd-run to execute arbitrary commands.
(UnCCing the landlock and LSM lists because I don't think they're going to get much from this.) Yes, Landlock is inconsistent with DAC. They are two different mechanisms. "Write permission" is not a Landlock concept ("write file" is, but it's specifically for files), and I don't think Landlock is intended to be a complete sandbox all on its own. It is a mechanism to restrict specific, enumerated operations, and it is working here as described. Nowhere is it promised that turning on the whole set of restrictions gets you a complete sandbox.
On Sat, Dec 13, 2025 at 11:49:11PM -0500, Demi Marie Obenour wrote:
On 12/13/25 20:39, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
> It is quite possible that these Landlock rules are unnecessarily > permissive, but all of the paths to which read and execute access is > granted are part of the root filesystem and therefore assumed to be > public knowledge. Removing access from any of them would only increase > the risk of accidental breakage in the future, and would not provide any > security improvements. seccomp *could* provide some improvements, but > the effort needed is too high for now. > > Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> > --- > .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ > 1 file changed, 8 insertions(+)
Are you sure this is working as intended? There's no rule allowing access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be able to access that. Don't you need to set a rule that *restricts* filesystem access and then add holes? Did you ever see this deny anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I don't find it that surprising given the way landlock works. "connect" (to a non-abstract AF_UNIX socket) is not an operation there's a landlock action for, and it's not like the other actions care about access to parent directories and the like — I was able to execute a program via a symlink after only giving access to the symlink's target, without any access to the directory containing the symlink or the symlink itself, for example. Landlock, as I understand it, is intended to block a specified set of operations (on particular file hierarchies), rather than to completely prevent access to those hierarchies like permissions or mount namespaces could, so the lack of a way to block connecting to a socket is more of a missing feature than a security hole.
'man 7 unix' states:
On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket.
Landlock is definitely being inconsistent with DAC here. Also, this allows real-world sandbox breakouts. On systemd systems, the simplest way to escape is to use systemd-run to execute arbitrary commands.
The Linux kernel is complex and the link between the VFS and named UNIX sockets is "special" (see the linked GitHub issue). Landlock doesn't handle named UNIX sockets yet for the same reason it doesn't handle some other kind of kernel resources or access rights: someone needs to implement it (including tests, doc...). There is definitely interest to add this feature, it has been discussed for some time, but it's not trivial. It is a work in progress though: https://github.com/landlock-lsm/linux/issues/36 Contributions are welcome! Regards, Mickaël
On Sun, Dec 14, 2025 at 08:50:45PM +0100, Mickaël Salaün wrote:
On Sat, Dec 13, 2025 at 11:49:11PM -0500, Demi Marie Obenour wrote:
On 12/13/25 20:39, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 14:12, Alyssa Ross wrote: > Demi Marie Obenour <demiobenour@gmail.com> writes: > >> It is quite possible that these Landlock rules are unnecessarily >> permissive, but all of the paths to which read and execute access is >> granted are part of the root filesystem and therefore assumed to be >> public knowledge. Removing access from any of them would only increase >> the risk of accidental breakage in the future, and would not provide any >> security improvements. seccomp *could* provide some improvements, but >> the effort needed is too high for now. >> >> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> >> --- >> .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ >> 1 file changed, 8 insertions(+) > > Are you sure this is working as intended? There's no rule allowing > access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be > able to access that. Don't you need to set a rule that *restricts* > filesystem access and then add holes? Did you ever see this deny > anything?
'man 1 setpriv' states that '--landlock-access fs' blocks all filesystem access unless a subsequent --landlock-rule permits it. I tried running with no --landlock-rule flags and the execve of xdg-desktop-portal-spectrum-host failed as expected.
The socket is passed over stdin, and I'm pretty sure Landlock doesn't restrict using an already-open file descriptor. xdg-desktop-portal-spectrum-host does need to find the path to the socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I don't find it that surprising given the way landlock works. "connect" (to a non-abstract AF_UNIX socket) is not an operation there's a landlock action for, and it's not like the other actions care about access to parent directories and the like — I was able to execute a program via a symlink after only giving access to the symlink's target, without any access to the directory containing the symlink or the symlink itself, for example. Landlock, as I understand it, is intended to block a specified set of operations (on particular file hierarchies), rather than to completely prevent access to those hierarchies like permissions or mount namespaces could, so the lack of a way to block connecting to a socket is more of a missing feature than a security hole.
'man 7 unix' states:
On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket.
Landlock is definitely being inconsistent with DAC here. Also, this allows real-world sandbox breakouts. On systemd systems, the simplest way to escape is to use systemd-run to execute arbitrary commands.
The Linux kernel is complex and the link between the VFS and named UNIX sockets is "special" (see the linked GitHub issue). Landlock doesn't handle named UNIX sockets yet for the same reason it doesn't handle some other kind of kernel resources or access rights: someone needs to implement it (including tests, doc...). There is definitely interest to add this feature, it has been discussed for some time, but it's not trivial. It is a work in progress though: https://github.com/landlock-lsm/linux/issues/36
Agreed, this would be the change that would let us restrict connect() on AF_UNIX sockets. Additionally, *in the case that you do not actually need* Unix sockets, the other patch set that would be of interest is the one for restricting the creation of new socket FDs: https://github.com/landlock-lsm/linux/issues/6 In this talk in 2014, I explained my mental model around the network-related restrictions: https://youtu.be/K2onopkMhuM?si=LCObEX6HhGdzPnks&t=2030 The discussed socket control feature continues to be a central missing piece, as the TCP port restrictions do not make much sense as long as you can still create sockets for other protocol types. Issue #6 that should fix this is still under active development -- an updated version of the patch was posted just last month. To bridge the gap, the same thing can also be emulated with seccomp, but as you noted above as well in this thread, this is harder. –Günther
On 12/15/25 03:20, Günther Noack wrote:
On Sun, Dec 14, 2025 at 08:50:45PM +0100, Mickaël Salaün wrote:
On Sat, Dec 13, 2025 at 11:49:11PM -0500, Demi Marie Obenour wrote:
On 12/13/25 20:39, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
> On 12/13/25 14:12, Alyssa Ross wrote: >> Demi Marie Obenour <demiobenour@gmail.com> writes: >> >>> It is quite possible that these Landlock rules are unnecessarily >>> permissive, but all of the paths to which read and execute access is >>> granted are part of the root filesystem and therefore assumed to be >>> public knowledge. Removing access from any of them would only increase >>> the risk of accidental breakage in the future, and would not provide any >>> security improvements. seccomp *could* provide some improvements, but >>> the effort needed is too high for now. >>> >>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> >>> --- >>> .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >> >> Are you sure this is working as intended? There's no rule allowing >> access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be >> able to access that. Don't you need to set a rule that *restricts* >> filesystem access and then add holes? Did you ever see this deny >> anything? > > 'man 1 setpriv' states that '--landlock-access fs' blocks all > filesystem access unless a subsequent --landlock-rule permits it. > I tried running with no --landlock-rule flags and the execve of > xdg-desktop-portal-spectrum-host failed as expected. > > The socket is passed over stdin, and I'm pretty sure Landlock > doesn't restrict using an already-open file descriptor. > xdg-desktop-portal-spectrum-host does need to find the path to the > socket, but I don't think it ever accesses that path.
I've been looking into this a bit myself, and from what I can tell Landlock just doesn't restrict connecting to sockets at all, even if they're inside directories that would otherwise be inaccessible. It's able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus socket even with a maximally restrictive landlock rule. So you were right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I don't find it that surprising given the way landlock works. "connect" (to a non-abstract AF_UNIX socket) is not an operation there's a landlock action for, and it's not like the other actions care about access to parent directories and the like — I was able to execute a program via a symlink after only giving access to the symlink's target, without any access to the directory containing the symlink or the symlink itself, for example. Landlock, as I understand it, is intended to block a specified set of operations (on particular file hierarchies), rather than to completely prevent access to those hierarchies like permissions or mount namespaces could, so the lack of a way to block connecting to a socket is more of a missing feature than a security hole.
'man 7 unix' states:
On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket.
Landlock is definitely being inconsistent with DAC here. Also, this allows real-world sandbox breakouts. On systemd systems, the simplest way to escape is to use systemd-run to execute arbitrary commands.
The Linux kernel is complex and the link between the VFS and named UNIX sockets is "special" (see the linked GitHub issue). Landlock doesn't handle named UNIX sockets yet for the same reason it doesn't handle some other kind of kernel resources or access rights: someone needs to implement it (including tests, doc...). There is definitely interest to add this feature, it has been discussed for some time, but it's not trivial. It is a work in progress though: https://github.com/landlock-lsm/linux/issues/36
Agreed, this would be the change that would let us restrict connect() on AF_UNIX sockets.
Additionally, *in the case that you do not actually need* Unix sockets, the other patch set that would be of interest is the one for restricting the creation of new socket FDs: https://github.com/landlock-lsm/linux/issues/6
In this talk in 2014, I explained my mental model around the network-related restrictions: https://youtu.be/K2onopkMhuM?si=LCObEX6HhGdzPnks&t=2030
The discussed socket control feature continues to be a central missing piece, as the TCP port restrictions do not make much sense as long as you can still create sockets for other protocol types.
Issue #6 that should fix this is still under active development -- an updated version of the patch was posted just last month.
To bridge the gap, the same thing can also be emulated with seccomp, but as you noted above as well in this thread, this is harder.
–Günther
I'm a bit surprised that this needs to be separate from other access controls. To me, it seems like a bit of a misdesign in the core kernel (not Landlock). I would go as far as to state that enabling other filesystem restrictions should also restrict AF_UNIX filesystem sockets automatically, as that is what users and administrators will expect. What surprises me somewhat is that Linux does not have any sort of unified hook for filesystem path walks. My mental model of Landlock is that from a filesystem perspective, the result should be equivalent to creating an empty mount namespace, putting a tmpfs on its root, and bind-mounting the allowed paths. That this mental model does not match reality was quite surprising. -- Sincerely, Demi Marie Obenour (she/her/hers)
On Mon, Dec 15, 2025 at 03:54:25AM -0500, Demi Marie Obenour wrote:
On 12/15/25 03:20, Günther Noack wrote:
On Sun, Dec 14, 2025 at 08:50:45PM +0100, Mickaël Salaün wrote:
On Sat, Dec 13, 2025 at 11:49:11PM -0500, Demi Marie Obenour wrote:
On 12/13/25 20:39, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/13/25 16:42, Alyssa Ross wrote: > Demi Marie Obenour <demiobenour@gmail.com> writes: > >> On 12/13/25 14:12, Alyssa Ross wrote: >>> Demi Marie Obenour <demiobenour@gmail.com> writes: >>> >>>> It is quite possible that these Landlock rules are unnecessarily >>>> permissive, but all of the paths to which read and execute access is >>>> granted are part of the root filesystem and therefore assumed to be >>>> public knowledge. Removing access from any of them would only increase >>>> the risk of accidental breakage in the future, and would not provide any >>>> security improvements. seccomp *could* provide some improvements, but >>>> the effort needed is too high for now. >>>> >>>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> >>>> --- >>>> .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>> >>> Are you sure this is working as intended? There's no rule allowing >>> access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be >>> able to access that. Don't you need to set a rule that *restricts* >>> filesystem access and then add holes? Did you ever see this deny >>> anything? >> >> 'man 1 setpriv' states that '--landlock-access fs' blocks all >> filesystem access unless a subsequent --landlock-rule permits it. >> I tried running with no --landlock-rule flags and the execve of >> xdg-desktop-portal-spectrum-host failed as expected. >> >> The socket is passed over stdin, and I'm pretty sure Landlock >> doesn't restrict using an already-open file descriptor. >> xdg-desktop-portal-spectrum-host does need to find the path to the >> socket, but I don't think it ever accesses that path. > > I've been looking into this a bit myself, and from what I can tell > Landlock just doesn't restrict connecting to sockets at all, even if > they're inside directories that would otherwise be inaccessible. It's > able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus > socket even with a maximally restrictive landlock rule. So you were > right after all, sorry!
That's not good at all! It's a trivial sandbox escape in so many cases. For instance, with access to D-Bus I can just call `systemd-run`.
I'm CCing the Landlock and LSM mailing lists because if you are correct, then this is a bad security hole.
I don't find it that surprising given the way landlock works. "connect" (to a non-abstract AF_UNIX socket) is not an operation there's a landlock action for, and it's not like the other actions care about access to parent directories and the like — I was able to execute a program via a symlink after only giving access to the symlink's target, without any access to the directory containing the symlink or the symlink itself, for example. Landlock, as I understand it, is intended to block a specified set of operations (on particular file hierarchies), rather than to completely prevent access to those hierarchies like permissions or mount namespaces could, so the lack of a way to block connecting to a socket is more of a missing feature than a security hole.
'man 7 unix' states:
On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket.
Landlock is definitely being inconsistent with DAC here. Also, this allows real-world sandbox breakouts. On systemd systems, the simplest way to escape is to use systemd-run to execute arbitrary commands.
The Linux kernel is complex and the link between the VFS and named UNIX sockets is "special" (see the linked GitHub issue). Landlock doesn't handle named UNIX sockets yet for the same reason it doesn't handle some other kind of kernel resources or access rights: someone needs to implement it (including tests, doc...). There is definitely interest to add this feature, it has been discussed for some time, but it's not trivial. It is a work in progress though: https://github.com/landlock-lsm/linux/issues/36
Agreed, this would be the change that would let us restrict connect() on AF_UNIX sockets.
Additionally, *in the case that you do not actually need* Unix sockets, the other patch set that would be of interest is the one for restricting the creation of new socket FDs: https://github.com/landlock-lsm/linux/issues/6
In this talk in 2014, I explained my mental model around the network-related restrictions: https://youtu.be/K2onopkMhuM?si=LCObEX6HhGdzPnks&t=2030
The discussed socket control feature continues to be a central missing piece, as the TCP port restrictions do not make much sense as long as you can still create sockets for other protocol types.
Issue #6 that should fix this is still under active development -- an updated version of the patch was posted just last month.
To bridge the gap, the same thing can also be emulated with seccomp, but as you noted above as well in this thread, this is harder.
–Günther
I'm a bit surprised that this needs to be separate from other access controls. To me, it seems like a bit of a misdesign in the core kernel (not Landlock).
I would go as far as to state that enabling other filesystem restrictions should also restrict AF_UNIX filesystem sockets automatically, as that is what users and administrators will expect.
I agree, that would be nice, but it's legacy.
What surprises me somewhat is that Linux does not have any sort of unified hook for filesystem path walks. My mental model of Landlock is that from a filesystem perspective, the result should be equivalent to creating an empty mount namespace, putting a tmpfs on its root, and bind-mounting the allowed paths. That this mental model does not match reality was quite surprising.
The approach taken by Landlock is to not break user space with kernel updates, follow an incremental approach, and have a nice compatibility story. This is why a ruleset is created with a set of well-defined "handled" access rights and restrictions. Each new handled access right or restriction must come with an explicit request from user space (e.g. set new bits in struct landlock_ruleset_attr). It would have been appealing to start from scratch, drop all access rights, and then gradually implement access rights, but that would have make Landlock unusable in most use cases. Instead, we gradually extend the scope of Landlock with well-defined and well-tested restrictions. This approach eases the integration of Landlock and when new kernel features are available, it's easy to update an integration to leverage the new features. From day one, Landlock has been useful, even if it doesn't cover all use cases and environments. When sandboxing a program (or properly securing an OS), most of the time, the difficult part is to get a good security architecture with proper privilege separation. Once this is done, it's much easier to gradually improve it. We should probably improve the Landlock documentation, especially by extending the warning block with some other relevant syscalls: https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
participants (4)
-
Alyssa Ross -
Demi Marie Obenour -
Günther Noack -
Mickaël Salaün