Re: RFC systemd-sysext/confext image context mounts

[Dominick Grift <dominick.grift@defensec.nl>]

Chris PeBenito <chpebeni@linux.microsoft.com> writes:

> On 1/6/2026 12:01 PM, Dominick Grift wrote:
>> Chris PeBenito <chpebeni@linux.microsoft.com> writes:
>> 
>>> Systemd provides tools for composing directories like /usr and /opt
>>> (system extensions, sysext) or /etc (configuration extensions,
>>> confext).   These tools create an overlayfs at the target location,
>>> with the root filesystem and extensions.  While they support raw
>>> directories, files, and mutable filesystems, my current concern is
>>> with extending immutable distributions at runtime using additional
>>> immutable images.
>>>
>>> The challenge lies in ensuring proper labeling before deploying an
>>> image, which is problematic for third-party images lacking labels or
>>> using incompatible ones.  I haven't made any patches yet, as I want to
>>> consult this group and the systemd developers first.  My proposal is:
>>> for internally labeled filesystems (ext4, etc.), have the tools
>>> validate the image's root directory label.  If validation fails, apply
>> Sounds fragile as these filesystems by definition have more then
>> just a
>> root directory.
>> 
>>> a context= mount using the label from the contexts/systemd_contexts
>>> file in the policy.  I'd probably also add options in sysext.conf(.d)
>>> and confext.conf(.d) to override this behavior, such as for specifying
>>> an alternate label for the context mount.
>>>
>>> What are your thoughts?
>> I am not opposed per se but feels inconsistent. Consider for
>> example verity authentication which will also most likely be used in
>> these types of scenarios: why would one be able to deal with verity but
>> not with selinux labels?
>
> A third party would provide the hashtree and root hash along with the
> image.  If you're referring to a signature, that would be provided
> too. Are you expecting them to also put out an image every time
> someone comes up with a new policy variation?

Sounds like that won't be an issue then. Good. I don't think in terms of
"them". I would probably use the same key/crt for both the hosts root as
well as extension images. I also think that I would probably update my
extensions if a change to the hosts policy affects them negatively. I am
not sure if systemd.v (vpick) currently works with extensions and or if
there are plans to make that work but I can see the potential benefits
in that regard

>
>
>> Also wondering where systemd is going to go with extensions will we get
>> per-user instances that work together with systemd-mountfsd like we
>> currently have with systemd-nspawn? If so how will that affect this design.
> Can you elaborate?  I'm not familiar with these aspects.
>

systemd-mountfsd allows unprivileged users to request it to mount images
on their behalf. I don't know how per-user extensions for say ~/.config
and/or ~/.local(/share)? would be implemented technically but I have no
doubt that if there is a desire/interest for such functionality that Poettering
will be able to implement it.

I imagine that it could work similar with for example starting a
systemd --user service unit with RootImage= or systemd-nspawn -I ran without
root. Which by the way present similar challenges.

But. Keep in mind that we have container, root, extension and portable
image types. They all have similar challenges and aside from root images
they can be imported with importctl. importctl --user currently works
for container images and so I have no reason to believe that it will not
be made to work if there is a desire for per-user extensions and/or portables.

Again. Not opposed per se. Just contributing my 2 cents. Happy to share
my thoughts.

-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl