On Wed, Jun 12, 2019 at 4:11 PM Roberto Sassu <roberto.sassu@xxxxxxxxxx> wrote: > > - after initialization > > - deny reading|writing anything without security.ima > > - deny reading|writing anything invalid > > - allow everything else > > > > The logic is pretty handy as it even creates additional layer of > > security around the early initialization files as they become > > unreadable after use. > > What if they should be legitimately used after the HMAC key is unsealed > and before switching to the persistent root file system? Any examples? Log files and such are mostly 'one way' and should probably be whitelisted in the policy? > > Now, if we initialize the system with a random key like in your patch, > > this logic is to change quite drastically? It sounds to me the > > userland may actually break, all the userland initialization files in > > the existing ima configurations that do not use digsigs would become > > unreadable given that the random key is put in? Remember, those files > > can be protected via other means (most commonly signed ramdisk). > > No, the first patch is about adding the ability to verify files created > during each boot. For any other file, EVM returns INTEGRITY_UNKNOWN as > before. The second patch changes the behavior, as INTEGRITY_UNKNOWN is > considered as an error for the enforce-evm appraisal mode. The second > patch aims at making the system more secure, as no file would be > accessible unless it is verified. > > It is true that configurations without digsigs won't work anymore but > the alternative is accepting any file until the HMAC key is unsealed. That's a pretty big change for the userland IMHO. Quite a few configurations out there will break, including mine I believe, so I hope there is a solid reason asking people to change their stuff. I'm fine holding off all writing until it is safe to do so for now.. -- Janne