Demi Marie Obenour writes: > On 12/13/25 16:42, Alyssa Ross wrote: >> Demi Marie Obenour writes: >> >>> On 12/13/25 14:12, Alyssa Ross wrote: >>>> Demi Marie Obenour 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 >>>>> --- >>>>> .../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.