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.