On Wed, Dec 15, 2021, at 1:45 PM, Luca Boccassi wrote: >> On Fri, Dec 10, 2021 at 10:47:52AM +0100, Vít Ondruch wrote: >> >> Any file covered by fs-verity is immutable after installation. So you >> cannot modify the contents, the kernel refuses. But you can just >> replace the file (like during an upgrade), and of course copy and edit >> in a different location. If replaced, no fs-verity checking is done >> any more by the kernel. There was some talk about high-level solution >> to prevent such files from being executed, e.g. an LSM module, but no >> details... (Thinking about this, it would be pretty hard, because the >> LSM would need to be smart enough to know which files are installed >> through rpm, and which files are not. I would love to hear more details >> about what is planned here.) >> >> Zbyszek > > There is such an LSM that supports fs-verity (and dm-verity), being > reviewed right now: IPE > > https://lore.kernel.org/lkml/81d5e825-1ee2-8f6b-cd9d-07b0f8bd3...@linux.microsoft.com/T/ > https://microsoft.github.io/ipe/
Hmm. Some interesting stuff going on there but I would have started with a new SELinux access vector. That'd allow fine-grained constraints, e.g. disallowing `init_t` but allowing `unconfined_service_t`. Possibly also landlock should be able to hook into this. IOW it's not clear to me that a new LSM is the best thing for the ecosystem here. But bigger picture I'd agree that fs-verity is significantly stronger when coupled with such a policy - strong enough to block exploits like the runc one: https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/ (Of course that one was *also* stopped by ostree's default read-only bind mount, which I keep saying is not really primarily about security, but hey it worked there) I said this about the IMA-for-Fedora proposal too - to me the approach of "sign all the RPMs" is not a good idea. Instead the focus should be on ensuring the capability works, and is usable from tools to build custom systems. And this of course runs into a bigger picture question of whether we should emphasize the entry point into Fedora being Anaconda/FCOS like (provision and configure a "pre-built" system) or more like Image Builder and tools like that. I think the answer has to be "we do both" really - it's just hard. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
