Re: RFC systemd-sysext/confext image context mounts

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

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