Re: RFC: Make it practical to ship EVM signatures

From: Roberto Sassu <roberto.sassu@huawei.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Matthew Garrett <mjg59@google.com>
Cc: <linux-integrity@vger.kernel.org>,
	Mikhail Kurinnoi <viewizard@viewizard.com>
Subject: Re: RFC: Make it practical to ship EVM signatures
Date: Mon, 2 Oct 2017 10:55:38 +0200	[thread overview]
Message-ID: <61b5b92e-3fcc-5805-7358-34d74a036035@huawei.com> (raw)
In-Reply-To: <1506646397.5691.64.camel@linux.vnet.ibm.com>

On 9/29/2017 2:53 AM, Mimi Zohar wrote:
> On Thu, 2017-09-28 at 14:13 -0700, Matthew Garrett wrote:
>> On Thu, Sep 28, 2017 at 1:12 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>>> Earlier this year there were discussions on defining a portable EVM
>>> signature, that could be included in software packages.
>>>
>>> The reason for including as much metadata as possible in the HMAC is
>>> to limit cut & paste attacks.  For this reason, the portable data is
>>> only used in transmission, not on disk.
>>
>> The concern is that two identical copies of a file may exist, but with
>> different security contexts, and that not protecting the inode would
>> allow an attacker to copy the security metadata from one file onto the
>> other? This presumably only has meaning if they're on separate
>> filesystems, since otherwise the attacker could just delete one file
>> and hardlink the other to the former's location? I think that for our
>> purposes this isn't a big deal.
> 
> Without the inode included in the HMAC calculation, the same file
> could exist as a different file name on the same file system.  No need
> for the two files to be on different file systems.
> 
>>> A new EVM type is defined that does not convert the EVM signature to
>>> an HMAC.
>>>
>>> Mikhail's patches:
>>> https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/thread/2017
>>> 0113072602.4ffaa30a@totoro/
>>
>> That looks broadly like what we want, but I think there's some
>> advantage in maintaining the flexibility of choosing which information
>> is embedded. One additional option would be to allow userland to place
>> a restriction on which options *must* be present, ie local policy
>> could refuse to allow any signatures that didn't include a specific
>> set of metadata.
> 
> This introduces a new level of complexity, which I'm not sure is warranted.
> 
>> One of the reasons we're interested in allowing the use of signatures
>> rather than HMACs is to avoid the case where a machine being
>> compromised would allow an attacker to obtain the symmetric key and
>> drop new appropriately HMACed binaries on the system that would
>> persist even if the kernel was updated to fix the vulnerability.

With a predictable system state, you would be able to prevent misuse
of the symmetric key. For example, suppose that the state is about
to change (with a digest list, IMA extends PCR 10 with the digest
of unknown files). Then, countermeasures can be implemented to avoid
using the symmetric key before the system is compromised.

The remaining issue is when vulnerabilities are discovered in known
software. In this case, the symmetric key should be revoked and
replaced with a new one. Files protected with the old key must
be checked and protected with the new key.

I agree on the fact that HMACs can be avoided for immutable files
but, for mutable files, HMACs could be very useful. Suppose that
a valid HMAC can be applied to a file only when the symmetric key
is available (system is in the expected state) and when the file
is written only by the TCB. Then, you can exclude those files from
measurement (unless the HMAC is invalid) and avoid unknown digests
(the system state remains predictable).

> Assuming you're using a trusted key (TPM based key) to encrypt/decrypt
> the EVM key (trusted key), then such an attack would require root
> privileges with the ability to read kernel memory.  The EVM key is
> never exposed to userspace in the clear.

A malicious admin can launch a new kernel with kexec and dump the key.

The symmetric key can be protected against malicious administrators
if it is generated by the TPM (sensitiveDataOrigin bit must be set)
and is released only after verifying the sealing policy (kexec is
disabled, only good software can be executed, ...).

Roberto

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG