Re: [PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

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 will still go ahead with doing this in the program though, since I
>> already got that far.
>
> Would it make sense to connect to the sockets and then block connect()
> and friends using seccomp?

I'm not sure it's worth it.  There's not a lot else to connect to and I
expect we'll be able to do this with landlock at some point.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]