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

[Roberto Sassu <roberto.sassu@huawei.com>]

On 6/12/2019 3:38 PM, Janne Karhunen wrote:
> 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?

I checked better when the random key would be used to verify files
created during the boot. If we consider rootfs only, basically it would
be used for dracut-state.sh.

Before I was using a rule to measure digest lists in tmpfs. I had many
errors due to the fact that appraisal denied access to files in /run.
The default policy does not appraise files in tmpfs, and also for digest
lists it is not necessary (now I use: measure/appraise fsname=rootfs).


>>> 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..

The goal of appraisal is to allow access only to files with a valid
signature or HMAC. With the current behavior, that cannot be guaranteed.

Unfortunately, dracut-state.sh is created very early. It could be
possible to unseal the key before, but this probably means modifying
systemd.

Roberto

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI