Re: [RFC][PATCH 0/2] ima: preserve integrity of dynamic data

From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	linux-integrity@vger.kernel.org
Subject: Re: [RFC][PATCH 0/2] ima: preserve integrity of dynamic data
Date: Mon, 23 Oct 2017 07:01:39 -0400	[thread overview]
Message-ID: <1508756499.3639.53.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171020154138.23635-1-roberto.sassu@huawei.com>

On Fri, 2017-10-20 at 17:41 +0200, Roberto Sassu wrote:
> One of the most challenging tasks for remote attestation is how to
> handle the measurement of dynamic data (mutable files). When the default
> policy is selected, IMA measures files accessed by root processes (TCB).

Agreed.  The original ima_policy="appraise_tcb" (formerly known as
"ima_appraise_tcb") is a builtin policy, which can be and normally is
replaced by a custom policy.  This builtin IMA policy starts
immediately and is normally replaced after the LSMs have been
initialized, allowing for a finer grain policy.

> However, if a file was previously modified by another process, the digest
> included in the new measurement list is unknown, and verifiers must assume,
> during a remote attestation, that the system was compromised, because they
> don't know if that file was written by a process in the TCB or not.
> 
> The goal of this patch set is to enforce an integrity policy on appraised
> files, to avoid reporting measurements of dynamic data after they have been
> modified. Only the initial state should be reported (e.g. the file
> signature, or a digest list).
> 
> In order to properly enforce an integrity policy, it is necessary to
> specify in the IMA policy process credentials rather than file attributes.
> 
> For example, the rule:
> 
> appraise fowner=0
> 
> could be replaced with:
> 
> appraise uid=0
> appraise euid=0

The difference between these two policies is the ability to know which
files must be hashed/signed apriori.  In the first case, only those
files owned by root must be hashed/signed, while in the latter case
all files on the file system must be hashed/signed.

When making changes, please keep in mind the bigger picture of who is
doing what and how the integrity subsystem is currently being used.
 Adding new functionality or extending the existing subsystem is all
good, but these changes cannot break existing systems or change its
meaning.

Mimi