[PATCH v3 0/2] ima/evm fixes for v5.2
janne.karhunen at gmail.com
Wed Jun 12 13:38:07 UTC 2019
On Wed, Jun 12, 2019 at 4:11 PM Roberto Sassu <roberto.sassu at huawei.com> 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..
More information about the Linux-security-module-archive