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