Re: [Linux-ima-user] Clarification requested. Comments about some info in the wiki.

[Mimi Z. <zo...@li...>]

On Fri, 2015-01-09 at 12:19 -0700, Curtis Veit wrote: 
> Mimi,
> 
> Thanks for the answers to my questions. 
> 
> On Fri, Jan 09, 2015 at 09:32:58AM -0500, Mimi Zohar wrote:
> > On Thu, 2015-01-08 at 13:08 -0700, Curtis Veit wrote:
> 
> > > 1. How do I write a policy that ensures that the digital signature
> > > approach is required for specific groups of files?
> > 
> > Yes, on the policy rule requiring signatures add
> > "appraise_type:=imasig".

The above line should have been "appraise_type=imasig".

> > > 2. Do I understand correctly that if I am using the hash (no digital
> > > signature), if a malicious user or executable "updates" a file, the
> > 
> > Right, immutable files should be labeled with file signatures.  Mutable
> > files by definition change, requiring the security.ima xattr to change
> > to reflect the file data.
> > 
> > >     ... If the hashes are in the log is
> > > that log file protected from tampering? How?
> > 
> > The measurement log is stored in memory and can be attested to, so that
> > a remote host can verify the integrity of the system.
> 
> So, in the system I am working with there is no TPM and no requirement to
> attest for the various files.
> There is a requirement to ensure that executables, libraries and system
> config files have not been tampered with. 

Executables and libraries can be appraised using the BPRM_CHECK and
MMAP_CHECK hooks.  Unfortunately there isn't a specific
measurement/appraisal hook only for configuration files.  All files
opened for read can be appraised using the FILE_CHECK hook.  To
differentiate between files in policy from those that are not, the
policy rules can be written in terms of LSM labels.

> It sounds to me like I should skip measurement and just sign everything that
> must be treated as immutable.  (I will try this out based on my current 
> understanding.)

> Does that mean I can skip "ima_tcb" on the command like and just use
> "ima_appraise_tcb" ?

Before dismissing the need for measurement, read the initial white paper
"Overview of the linux-integrity subsystem".  It's a bit dated, but it
is a good place to start.

> Some additional questions: 
> What does "ima_template=ima-sig" do? is there any relationship to 
> this approach?

"ima_template=" refers to the measurement log format.  The default
ima-ng template includes a file hash and pathname.  In addition to the
ima-ng fields, the ima-sig contains the file signature stored in the
xattr, if available.

> I am currently on the 3.13 kernel (ubuntu 14.04) so I do not need to 
> worry about adding a key to the keyring. but is best practice to
> compile the kernel with a key or is there another approach to get that
> first "valid" signing key in the keyring for 3.17 and beyond?

Redhat has some patches, which I don't think have been upstreamed, that
add UEFI and Machine Owner Keys(MOK) db to the system keyring.  Either
build the local-ca key into the kernel or add it to the UEFI or MOK db.

> Is there a reference for policy syntax? (other than the end of the wiki)

The current version is in the kernel build tree
Documentation/ABI/testing/ima_policy.

> I am keeping notes and hope (eventually) to provide some reference material 
> that you could add to the wiki.

thanks :)

Mimi