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

[Alyssa Ross <hi@alyssa.is>]

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

Demi Marie Obenour <demiobenour@gmail.com> writes:

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

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