Re: RFC systemd-sysext/confext image context mounts

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

Dominick Grift <dominick.grift@defensec.nl> writes:

> 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?

I looked into this but youre right indeed that all a image vendor has to
do is make the public key available. Then the consumer of the image just
needs to pull that into /etc/verity.d and then thats basically
everything you need for extensions.

So this was a non-argument.

>
> 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