On Thu, Jun 6, 2024 at 6:17 PM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On Mi, 05.06.24 18:28, Itxaka Serrano Garcia (itxaka.garcia@xxxxxxxxxxxxxxxx) 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
Lennart
--
Lennart Poettering, Berlin
Thanks for all the info!
Itxaka
