[systemd-devel] Sysext questions

[Itxaka Serrano Garcia]

On Thu, Jun 6, 2024 at 6:17 PM Lennart Poettering <lennart at poettering.net>
wrote:

> On Mi, 05.06.24 18:28, Itxaka Serrano Garcia (
> itxaka.garcia at spectrocloud.com) wrote:
>
> > Hello again!
> >
> > A few sysext questions that have arisen from our testing
> >
> >  - image policy is configurable but it's there a single config file where
> > we can put that so it's used system wide? For example to only allow
> > verity+signed? Service override?
>
> This does not exist right now, because I was a bit unsure how the best
> expose this, i.e. whether to maintain separate config files for
> portabled, sysext, confext, nspawn, or a single knob.
>
> Note that the plan so far was to complement the userspace enforced
> logic wit a kernel-enforced logic, that refuses to allow mounting of
> block-based file systems unless they are dm-verity or dm-crypt via
> some LSM. Hence, the more fine-grained userspace image policy would be
> one thing, the more generic kernel image policy would be the
> other. Because of that I think the userspace knobs should be
> per-subsystem, i.e. one setting for portabled, a separate one for
> sysext, and for confext and so on. (in particular as for sysext one
> probably wants dm-verity, wile for confext dm-crypt is probably necessary)
>
> Anyway, having something like this is definitely planned, but not
> implemented yet, and not fully thought to the end. if you want to work
> on this, would be great.
>


Would love to but this is a lot over my head lol



>
> >  - I can't see anything preventing a manual call to sysext refresh from
> > overriding the default policy, i.e if we set it at the service level in
> an
> > immutable system, nothing prevents someone from calling the sysext
> command
> > manually and override the image policy no?
>
> Yeah, let's say we add /etc/systemd/sysext.conf with an ImagePolicy=
> setting we should have one level of security.
>
> And some future LSM would then provide a 2nd level of security on
> this.
>
> Neither exist right now.
>
> >  - I also don't see anything that can run against a single sysext and
> > return a validity check, to check individual files conform to a given
> > policy for example? Any idea if there is something like that? Sysext
> verify
> > SYSEXT_FILE --image-policy=whatever
>
> This exists: "systemd-dissect --validate"
>


Ohhh, really nice! Why is this not more publitized! This shows a lot of
info about images, wow!


>
> >  - I have also seen that having several extensions verity+signed, if
> there
> > is just one that it's not either verity or signed, the whole merge
> > stops?
>
> That'd be a bug. The intention is definitely that we gracefully skip
> over DDIs that do not check out because of OS version mismatches,
> image policy mismatches, or missig keys, and still apply the others.
>
> > Is there any reasoning for that? Is that a bug? Should I open a bug for
> > this? IMHO it makes no sense as they are individual files so if something
> > does not match the policy it should just be skipped and the rest of the
> > extensions loaded anyway. But of course I have low visibility onto this,
> so
> > there may be good reasons for it.
>
> Yes, this is a bug, and I think there's already an issue filed about
> this, specific to the key-in-keyring issue.
>
>

Ahh, found it but seems like the PR is only for the metadata being invalid
like os release.
Linking here for archival purposes
issue: https://github.com/systemd/systemd/issues/32762
PR: https://github.com/systemd/systemd/pull/32967


> Lennart
>
> --
> Lennart Poettering, Berlin
>


Thanks for all the info!
Itxaka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240607/f49688b6/attachment.htm>