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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3864 bytes --]

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]