This means that the mount point is not verified at all, right? Shouldn't we rather check that the mount point is a container rootfs dir?

I think enabling allow_storages() for the first time in the main branch, and cleaning up various issues related to it, is a reasonable enough goal for this PR.

I agree that the driver == "image_guest_pull" rules will likely still need improvements after this PR. Some ideas to make progress with this other type of work in future PRs:

1. If someone can explain to me the rules for verifying that the image_guest_pull storage input is correct, I will try to implement these rules in genpolicy.
2. If someone else already knows the rules for verifying that the image_guest_pull storage input is correct, maybe they can contribute these improvements to genpolicy.
3. I believe pulling images on the Host has been discussed again recently for CoCo (while I was out from work for a few weeks), so maybe Host-pulled images will become at least as popular as image_guest_pull images?

We should add a TODO comment for the missing image_guest_pull rules though.

I think enabling allow_storages() for the first time in the main branch, and cleaning up various issues related to it, is a reasonable enough goal for this PR.

Agreed and I'm happy about making progress here, but I think we should try not to leave a state that superficially seems to do the right thing, but actually doesn't. I would be ok with a warning comment, though.

1. If someone can explain to me the rules for verifying that the image_guest_pull storage input is correct, I will try to implement these rules in genpolicy.

There's actually not that much to verify: image and mountpoint. A simple implementation would just check that the input is exactly equal to what's configured here:

However, when I implemented guest pull verification, I decided to only verify the manifest digest, not the registry/repo/tag, because that allows generating policies in one registry and pulling the images from another. Now, the alternative to pinning the image is to work with a tag and rely on image signatures, but in that case we'd need to verify registry and repository. Personally, I think that images used in CoCo should be pinned, if only because of reliability concerns. I don't mean to force that opinion onto people, though.

How about I open an RFC for this? Or is there an existing issue that I missed?

2. If someone else already knows the rules for verifying that the image_guest_pull storage input is correct, maybe they can contribute these improvements to genpolicy.

I can open a PR with my downstream implementation, and try to also cover the signed image case.

3. I believe pulling images on the Host has been discussed again recently for CoCo (while I was out from work for a few weeks), so maybe Host-pulled images will become at least as popular as image_guest_pull images?

Host-pulled with EROFS-snapshotter sounds very promising, it is definitely desirable when working with large images, and I think we can reuse most of the tardev policy for it. But there are good arguments for also supporting guest pull (simpler policy, confidential encrypted images), so we probably need to support both.

Thanks @burgerdev - I agree with what you said! I just didn't want to let Great be the enemy of Good in this case. I agree that we need that kind of comment for the remaining missing features.

Perhaps verifying the registry/repo/tag raises the bar a bit depending on use case - but CoCo users would also have to worry about the confidentiality/integrity of their network stack, and of the image repository server. Otherwise, images with correct registry/repo/tag might be downloaded from a rogue server.

Verifying manifest digests and/or using trusted signatures seems useful to me.

Thanks for volunteering to help with the image_guest_pull implementation! If the community would like support for verifying manifest digests, I am not aware of good reasons to wait until the signature and/or registry/repo/tag verification get implemented too.

I wrote an RFC: #11354.