Quoting Nathan Lynch (ntl@xxxxxxxxx): > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > > Quoting Nathan Lynch (ntl@xxxxxxxxx): > >> "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > >> > Quoting Nathan Lynch (ntl@xxxxxxxxx): > >> >> Oren Laadan <orenl@xxxxxxxxxxxxxxx> writes: > >> >> > >> >> > I think it's useful to be able to > >> >> > > >> >> > 1) checkpoint on a system with !CONFIG_UTS_NS, and - > >> >> > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a > >> >> > system with !CONFIG_UTS_NS (as long as all tasks in the image > >> >> > share a single uts-ns) > >> >> > >> >> In principle I agree, but what confidence can we have that meaningful > >> >> testing of such configurations (especially #2) will occur? > >> > > >> > History says, low confidence. So far just 1 is bad enough. It's > >> > taking a lot of my time on the LSM c/r (with the various combinations > >> > of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things > >> > like CONFIG_IPC_NS consistently break c/r anyway. > >> > > >> > So for 2 i'm tempted to say let's encode a sha1sum of the .config > >> > into the checkpoint header. We'll keep *trying* to support (2), and > >> > userspace can trivially rewrite the header if it really wants to believe > >> > we've succeeded. > >> > >> Are you suggesting having sys_restart code path consult the .config > >> sha1sum in the image? > > > > Yup. > > > >> Or is it just for the benefit of userspace? If > >> the former, I'm having difficulty grasping the benefit. > > > > Well we could also do it in userspace, but it seemed easier to actually > > store the sha1sum in a char buf in the c/r code in the kernel, stick it > > in the header at checkpoint, and verify it at restart. > > > > The benefit? Well... really I feel opposite today. Along the lines > > of supporting unprivileged restart as long as possible to make us > > consider security, I guess I'd argue we should support heterogenous > > (in terms of config :) c/r as long as possible. The reason I was > > thinking otherwise yesterday is that I have to special-case things > > like the task->security objref when CONFIG_SECURITY=n. It felt > > hacky yesterday, but the end result looks pretty good and is i > > think better thought out than it would have been were we doing the > > sha1sum thing. > > Okay. My thought was that the sha1sum would be as subject to tampering > as anything else in the image, so the restart path couldn't really rely > on it to convey accurate information about the image contents. But I > suppose it's moot now. whoa, I was in no way suggesting this as a way to stop userspace from loading such an image. As I said in an earlier email, it would be trivial - and be a feature - for userspace to rewrite the ckpt image with the new kernels' sha1sum(config). So the sha1sum would be to protect userspace from itself. To actually prevent userspace from loading such a ckpt image at all, we would need to ask the TPM to sign the ckpt image with a private key stored only on the TPM. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
