<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 6, 2024 at 6:17 PM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mi, 05.06.24 18:28, Itxaka Serrano Garcia (<a href="mailto:itxaka.garcia@spectrocloud.com" target="_blank">itxaka.garcia@spectrocloud.com</a>) wrote:<br>
<br>
> Hello again!<br>
><br>
> A few sysext questions that have arisen from our testing<br>
><br>
>  - image policy is configurable but it's there a single config file where<br>
> we can put that so it's used system wide? For example to only allow<br>
> verity+signed? Service override?<br>
<br>
This does not exist right now, because I was a bit unsure how the best<br>
expose this, i.e. whether to maintain separate config files for<br>
portabled, sysext, confext, nspawn, or a single knob.<br>
<br>
Note that the plan so far was to complement the userspace enforced<br>
logic wit a kernel-enforced logic, that refuses to allow mounting of<br>
block-based file systems unless they are dm-verity or dm-crypt via<br>
some LSM. Hence, the more fine-grained userspace image policy would be<br>
one thing, the more generic kernel image policy would be the<br>
other. Because of that I think the userspace knobs should be<br>
per-subsystem, i.e. one setting for portabled, a separate one for<br>
sysext, and for confext and so on. (in particular as for sysext one<br>
probably wants dm-verity, wile for confext dm-crypt is probably necessary)<br>
<br>
Anyway, having something like this is definitely planned, but not<br>
implemented yet, and not fully thought to the end. if you want to work<br>
on this, would be great.<br></blockquote><div><br></div><div><br></div><div>Would love to but this is a lot over my head lol<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>  - I can't see anything preventing a manual call to sysext refresh from<br>
> overriding the default policy, i.e if we set it at the service level in an<br>
> immutable system, nothing prevents someone from calling the sysext command<br>
> manually and override the image policy no?<br>
<br>
Yeah, let's say we add /etc/systemd/sysext.conf with an ImagePolicy=<br>
setting we should have one level of security.<br>
<br>
And some future LSM would then provide a 2nd level of security on<br>
this.<br>
<br>
Neither exist right now.<br>
<br>
>  - I also don't see anything that can run against a single sysext and<br>
> return a validity check, to check individual files conform to a given<br>
> policy for example? Any idea if there is something like that? Sysext verify<br>
> SYSEXT_FILE --image-policy=whatever<br>
<br>
This exists: "systemd-dissect --validate"<br></blockquote><div><br></div><div><br></div><div>Ohhh, really nice! Why is this not more publitized! This shows a lot of info about images, wow!</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>  - I have also seen that having several extensions verity+signed, if there<br>
> is just one that it's not either verity or signed, the whole merge<br>
> stops?<br>
<br>
That'd be a bug. The intention is definitely that we gracefully skip<br>
over DDIs that do not check out because of OS version mismatches,<br>
image policy mismatches, or missig keys, and still apply the others.<br>
<br>
> Is there any reasoning for that? Is that a bug? Should I open a bug for<br>
> this? IMHO it makes no sense as they are individual files so if something<br>
> does not match the policy it should just be skipped and the rest of the<br>
> extensions loaded anyway. But of course I have low visibility onto this, so<br>
> there may be good reasons for it.<br>
<br>
Yes, this is a bug, and I think there's already an issue filed about<br>
this, specific to the key-in-keyring issue.<br>
<br></blockquote><div><br></div><div><br></div><div>Ahh, found it but seems like the PR is only for the metadata being invalid like os release.</div><div>Linking here for archival purposes</div><div>issue: <a href="https://github.com/systemd/systemd/issues/32762">https://github.com/systemd/systemd/issues/32762</a></div><div>PR: <a href="https://github.com/systemd/systemd/pull/32967">https://github.com/systemd/systemd/pull/32967</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br></blockquote><div><br></div><div><br></div><div>Thanks for all the info!</div><div>Itxaka <br></div></div></div>