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@xxxxxxxxxxxxxxxxxx> 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
