From: Demi Marie Obenour <demiobenour@gmail.com>
To: Alyssa Ross <hi@alyssa.is>
Cc: Spectrum OS Development <devel@spectrum-os.org>,
linux-security-module@vger.kernel.org, landlock@lists.linux.dev
Subject: Re: [PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host
Date: Sat, 13 Dec 2025 19:22:55 -0500 [thread overview]
Message-ID: <00256266-26db-40cf-8f5b-f7c7064084c2@gmail.com> (raw)
In-Reply-To: <87ikea5a8x.fsf@alyssa.is>
[-- Attachment #1.1.1: Type: text/plain, Size: 2639 bytes --]
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?
--
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 --]
next prev parent reply other threads:[~2025-12-14 0:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-13 0:00 [PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host Demi Marie Obenour
2025-12-13 19:12 ` Alyssa Ross
2025-12-13 21:21 ` Demi Marie Obenour
2025-12-13 21:42 ` Alyssa Ross
2025-12-14 0:22 ` Demi Marie Obenour [this message]
2025-12-14 0:28 ` Alyssa Ross
2025-12-14 1:39 ` Alyssa Ross
2025-12-14 4:49 ` Demi Marie Obenour
2025-12-14 10:52 ` Alyssa Ross
2025-12-14 19:50 ` Mickaël Salaün
2025-12-15 8:20 ` Günther Noack
2025-12-15 8:54 ` Demi Marie Obenour
2025-12-15 11:27 ` Mickaël Salaün
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00256266-26db-40cf-8f5b-f7c7064084c2@gmail.com \
--to=demiobenour@gmail.com \
--cc=devel@spectrum-os.org \
--cc=hi@alyssa.is \
--cc=landlock@lists.linux.dev \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).