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
