Demi Marie Obenour writes: > On 12/13/25 20:39, Alyssa Ross wrote: >> 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. > > '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.