RFC systemd-sysext/confext image context mounts

RFC systemd-sysext/confext image context mounts

[Chris PeBenito]

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


--
Chris PeBenito

Re: RFC systemd-sysext/confext image context mounts

[Stephen Smalley]

On Tue, Jan 6, 2026 at 11:08 AM Chris PeBenito
<chpebeni@linux.microsoft.com> wrote:
>
> 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 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?

What does validate mean in the above? Check that it matches the
mountpoint's match in file_contexts? Or just check that the context is
valid under the currently loaded policy?

A potential problem with only checking the root directory label is
that those are generally the same across all policies derived from
refpolicy, whereas you are more likely to find invalid or inconsistent
contexts on leaf nodes.

Re: RFC systemd-sysext/confext image context mounts

[Chris PeBenito]

On 1/6/2026 11:20 AM, Stephen Smalley wrote:
> On Tue, Jan 6, 2026 at 11:08 AM Chris PeBenito
> <chpebeni@linux.microsoft.com> wrote:
>>
>> 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 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?
> 
> What does validate mean in the above? Check that it matches the
> mountpoint's match in file_contexts? Or just check that the context is
> valid under the currently loaded policy?

I meant the latter.


> A potential problem with only checking the root directory label is
> that those are generally the same across all policies derived from
> refpolicy, whereas you are more likely to find invalid or inconsistent
> contexts on leaf nodes.

I was thinking about grossly different policies, but this is a good 
point for slightly incompatible policies.  My main concern for doing 
validation across the whole fs is with how expensive it could get if the 
extension is big.  This could also be an argument for having 
configurable behavior in the sysext/confext.conf, as a tradeoff for only 
checking the root dir label.

Re: RFC systemd-sysext/confext image context mounts

[Stephen Smalley]

On Tue, Jan 6, 2026 at 11:44 AM Chris PeBenito
<chpebeni@linux.microsoft.com> wrote:
>
> On 1/6/2026 11:20 AM, Stephen Smalley wrote:
> > On Tue, Jan 6, 2026 at 11:08 AM Chris PeBenito
> > <chpebeni@linux.microsoft.com> wrote:
> >>
> >> 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 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?
> >
> > What does validate mean in the above? Check that it matches the
> > mountpoint's match in file_contexts? Or just check that the context is
> > valid under the currently loaded policy?
>
> I meant the latter.

The matching file context for the mountpoint would be a more precise
check of whether the directory tree is labeled compatibly with the
host OS. Regardless, to get the actual on-disk xattr value the process
fetching it will need mac_admin permission and CAP_MAC_ADMIN in its
effective capability set, which we generally don't allow even for
unconfined domains, and use the _raw libselinux interfaces or the
getxattr interface directly. Otherwise it will be automatically
remapped to the unlabeled context if invalid.

> > A potential problem with only checking the root directory label is
> > that those are generally the same across all policies derived from
> > refpolicy, whereas you are more likely to find invalid or inconsistent
> > contexts on leaf nodes.
>
> I was thinking about grossly different policies, but this is a good
> point for slightly incompatible policies.  My main concern for doing
> validation across the whole fs is with how expensive it could get if the
> extension is big.  This could also be an argument for having
> configurable behavior in the sysext/confext.conf, as a tradeoff for only
> checking the root dir label.

Re: RFC systemd-sysext/confext image context mounts

[Chris PeBenito]

On 1/6/2026 12:08 PM, Stephen Smalley wrote:
> On Tue, Jan 6, 2026 at 11:44 AM Chris PeBenito
> <chpebeni@linux.microsoft.com> wrote:
>> On 1/6/2026 11:20 AM, Stephen Smalley wrote:
>>> On Tue, Jan 6, 2026 at 11:08 AM Chris PeBenito
>>> <chpebeni@linux.microsoft.com> wrote:
>>>>
>>>> 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 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?
>>>
>>> What does validate mean in the above? Check that it matches the
>>> mountpoint's match in file_contexts? Or just check that the context is
>>> valid under the currently loaded policy?
>>
>> I meant the latter.
> 
> The matching file context for the mountpoint would be a more precise
> check of whether the directory tree is labeled compatibly with the
> host OS. Regardless, to get the actual on-disk xattr value the process
> fetching it will need mac_admin permission and CAP_MAC_ADMIN in its
> effective capability set, which we generally don't allow even for
> unconfined domains, and use the _raw libselinux interfaces or the
> getxattr interface directly. Otherwise it will be automatically
> remapped to the unlabeled context if invalid.

This would probably be done with systemd-dissect, which, I believe, 
directly inspects the image, without mounting it.

Re: RFC systemd-sysext/confext image context mounts

[Dominick Grift]

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?

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.

>
>
> --
> Chris PeBenito
>

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

Re: RFC systemd-sysext/confext image context mounts

[Chris PeBenito]

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?


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

Re: RFC systemd-sysext/confext image context mounts

[Dominick Grift]

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

Re: RFC systemd-sysext/confext image context mounts

[Dominick Grift]

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