Re: [PATCH v3 0/2] ima/evm fixes for v5.2

From: Janne Karhunen <janne.karhunen@gmail.com>
To: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	dmitry.kasatkin@huawei.com, mjg59@google.com,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	silviu.vlasceanu@huawei.com
Subject: Re: [PATCH v3 0/2] ima/evm fixes for v5.2
Date: Wed, 12 Jun 2019 16:38:07 +0300	[thread overview]
Message-ID: <CAE=NcraHqzST=SZNcrSgpv5EqfyUfpCCb7iQ0Oh6uohL3yiCdw@mail.gmail.com> (raw)
In-Reply-To: <d9efe3c7-20dd-bbb0-40d8-40f69cba5b88@huawei.com>

On Wed, Jun 12, 2019 at 4:11 PM Roberto Sassu <roberto.sassu@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..

--
Janne