recommend restricting object access via LSMs

[cgwalters]

One mild concern/criticism I heard about composefs is that in theory a process can just bypass the upper mount and read the underlying object files directly. I think in a "pure composefs" model they should all be mode 0400 (especially not executable or suid) and also under an "inaccessible directory" (mode 0700). That alone would seem to cover this pretty well...especially since e.g. systemd and podman also use the "inaccessible directory" pattern for similar purposes. Realistically very few processes should be running as real root with CAP_DAC_OVERRIDE if one is concerned about security to this level.

But we can suggest system builders take this a step farther - e.g. with SELinux create a composefs_object_t and restrict all access to it to a special domain (for example install_t). I am sure a similar thing would be relatively straightforward with SMACK. I'm less certain about AppArmor which is path based AFAIK.

[alexlarsson]

I'm not 100% sure this will work. Don't the reading process context have to have access to both the overlayfs upper file and the lower one?

[allisonkarlitskaya]

Can you outline in a bit more detail what the attack scenario is? I tend to think about OS images as public assets, but of course that's not always true. Are we worried about users gaining access to non-public binaries to analyze them for vulnerabilities or is it more about access to secrets embedded in non-world-readable files in /etc during the customization process?

I feel like our responses to just the two situations above could be handled differently and maybe there are other ones we'd also like to consider.

[cgwalters]

Don't the reading process context have to have access to both the overlayfs upper file and the lower one?

Yeah I think you're right. We could probably add an option to skip that check to overlayfs? Could be generally useful.

Can you outline in a bit more detail what the attack scenario is?

Honestly this isn't a concern I had, but I'm filing it in response to what I'll call "somewhat vague composefs concerns" from a realtime discussion with someone else.

I would say the overall concern is basically "having the files mounted elsewhere makes it easier to bypass upper layer access controls". So it's kind of all of the above. The equivalent on a dm-verity system is reading the raw block devices, but that's already controlled well via capabilities and LSMs.

[jlebon]

If they really want, in the host rootfs case integrators could also e.g. right after mounting the composefs in the initramfs, bind-mount /usr/share/empty over the object store. Then it comes down to restricting access to umounting the bind-mount or mounting the filesystem containing the store elsewhere.

[alexlarsson]

Don't the reading process context have to have access to both the overlayfs upper file and the lower one?

Yeah I think you're right. We could probably add an option to skip that check to overlayfs? Could be generally useful.

Actually I'm not 100% sure of this. Maybe its really that the mounter of the overlayfs has to have access to the layer file, and the process accessing the file has to have access to the file with the permissions that overlayfs exposes.

Anyway, my estimation of the chances to making permission handling changes upstream, at least ones that weakens the checks, is about zero percent.

[cgwalters]

OK, let's just put this one on the back burner. I wanted to have a tracker issue for it as something to followup on.

What's way way way more important is to continue "productizing" the boot-to-composefs path; this is just a followup on that.

[alexlarsson]

Well, what may be useful in the short term is to just do some quick testing to see what the actual permission requirements are atm for the lower dirs.