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! I will still go ahead with doing this in the program though, since I already got that far.