Apply OCI security settings to the guest workload

Hi,

When using Podman/crun with libkrun, options like --cap-drop, --security-opt no-new-privileges and seccomp restrict the VMM on the host, but aren't currently applied to the workload inside the guest.

Would it make sense for guest init to honour these too, as it already does for the OCI UID/GID?

The idea would be to keep init’s setup and supervision privileged, then apply the requested capabilities, no-new-privileges and seccomp filter before executing the workload. That would add another layer of protection inside the guest, while respecting the restrictions already requested for the container.

Put together a small PoC for capabilities and no-new-privileges, which works with stock crun.

For seccomp, there are changes in libkrun and crun. The crun change passes its compiled filter in the guest configuration using run.oci.seccomp_bpf_data, an existing annotation for supplying precompiled filters (also mentioned in this OCI proposal). That keeps the changes small and reuses crun’s compiler without adding libseccomp to guest init. Tested both with rootless Podman.

One limitation is confidential guests (SEV/SNP and TDX): crun’s per-launch /.krun_config.json isn't available inside their disk image. (Maybe those policies should be part of the image rather than set per launch? And what would be the intended way to supply them, ideally using the same mechanism for ordinary and confidential guests?)

Would there be interest in this? Does this approach make sense, and would PRs along these lines be welcome?