On Thu, Jun 6, 2024 at 6:17 PM Lennart Poettering <lenn...@poettering.net> wrote:
> On Mi, 05.06.24 18:28, Itxaka Serrano Garcia ( > itxaka.gar...@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
