Re: RFC: Make it practical to ship EVM signatures

From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: 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: Fri, 29 Sep 2017 16:01:44 -0400	[thread overview]
Message-ID: <1506715304.5691.151.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACdnJuvYNnePfz4H-D=DGMHbrbmZ52JWFoLqX120ALV=o4wwcw@mail.gmail.com>

On Fri, 2017-09-29 at 12:17 -0700, Matthew Garrett wrote:

> > The original understanding was that IMA/EVM would enforce integrity
> > and not enforce mandatory access control (MAC).  The LSMs (eg.
> > SELinux) would be responsible for MAC.  Separation of duties.
> 
> The kernel's security track record isn't sufficient to be able to
> assert that any kernel secrets can be kept secret, so we're left
> wanting integrity guarantees without relying on that.
> 
> > With that understanding, if the LSM allows a file to be "dropped" onto
> >  the file system of a running system, IMA/EVM will hash and hmac the
> > permitted file.
> >
> > I don't understand where you're going with this train of thought.  If
> > you're trying to make a case for EVM to run with only security.evm
> > signatures, then you wouldn't refer to the HMAC benefits.  If you're
> > trying to make a case for EVM signatures, with the inode they're not
> > portable, without the inode, they are susceptible to a cut and paste
> > attack.
> 
> I'm arguing that (for our case at least) the only way we can use IMA
> is to rely on using a digital signature - we can either have that
> digital signature be in security.ima, or we can have it in
> security.evm. Since we need that signature in any case, we derive no
> benefit from having security.evm be an hmac - our two reasonable
> choices are:
> 
> 1) security.ima as a digital signature, security.evm as an hmac
> 2) security.ima as a hash, security.evm as a digital signature

There's a major difference between security.ima containing a file hash
vs a signature.  A signature, assuming the file_check hook is in
policy, prevents the file from being modified, making the file
"immutable".

> I'm not really clear on what attacks are prevented by using the inode
> number. If I'm able to preserve all the other security metadata when
> copying a file, I can just create a hardlink to the original instead
> and have the same outcome.

The issue is the ability of having different security metadata, not
the same security metadata. (I need to refresh my memory as to hard
links, and whether they can have different security metadata.)

Originally the UUID was not included in the HMAC calculation.  Perhaps
the patch description of commit 74de668 "evm: add file system uuid to
EVM hmac" will help clarify the reasoning for including the inode and
uuid in the hmac calculation.

Mimi