Integrity auditing

[Mimi Zohar]

On Thu, 2007-09-06 at 13:07 -0400, Steve Grubb wrote: 
> On Wednesday 05 September 2007 15:26:22 Mimi Zohar wrote:
> > On Wed, 2007-09-05 at 11:11 -0400, Steve Grubb wrote:
> > > On Wednesday 05 September 2007 09:46:06 Mimi Zohar wrote:
> > Ok. For now, we are not releasing a LIM provider, which implements either
> > integrity_verify_metadata()/data().  Would it be better to define the
> > auditing msgs for monitoring the creation, deletion, modification of
> > integrity information/labels now or when we submit a LIM provider, which
> > implements these functions?
> 
> I suspect later.

agreed.

> > > > Add to audit.h:
> > > > #define AUDIT_INTEGRITY         1800    /* Integrity verify
> > > > success/failure */ #define AUDIT_INTEGRITY_ERR     1801    /* Internal
> > > > integrity errors */ #define AUDIT_INTEGRITY_PCR     1802    /* PCR
> > > > invalidation errors */
> > >
> > > What about configuration changes to it? Can you select the hash algorithm
> > > used? What about enable/disable of checking? Does this integrity scheme
> > > cover only objects or does it also cover subjects? What does a typical
> > > integrity label look like? Is there anything like a mass relabel after
> > > installation? Are there any self-tests for the hardware or keys stored
> > > within it?
> >
> > There are two IMA boot parameters.  The option "ima=" permits IMA to be
> > enabled/disabled.  The option "ima_hash=" is used to change the default
> > hash method from SHA1 to MD5.  There is no runtime mechanism to disable
> > integrity_measurements or to change the type of hash value used to extend
> > the PCR register.
> 
> I wonder if these should be emitted as an audit event?

Ok.  Instead of only logging the boot parameter errors, we will audit them.
The format will be: integrity: pid= auid= comm= op=

where op is one of:
	op=ima_enabled	
	op=ima_not_enabled

	op=hash_setup(sha1)
	op=hash_setup(md5)
	op=hash_setup(invalid_hash_type)

> > An LSM module determines which files to measure.  For SElinux, this
> > determination is based on policy.  The LSM module calls integrity_measure()
> > to extend the PCR value with the hash of the file. 
> >
> > As previously mentioned, IMA does not have an integrity label.  EVM, which
> > was previously in the -mm tree, did implement
> > integrity_verify_metadata/data. EVM stored the HMAC, the integrity label,
> > as an extended attribute called security.evm.hmac. The HMAC was on the
> > file's metadata, which based on configuration, included the file's hash,
> > the LSM xattr data, etc.
> 
> If that is being accepted into mainline, I think it needs some auditing work, 
> too.
>
> > There were two ways of labeling the system, during installation or post
> > install using a labeling fixup program.
> 
> Shouldn't that be an auditable event?

Ok.  For now, we decided to first work on an IMA-only solution, which does not
require labeling.  Once IMA is accepted and upstreamed, we will go back and add 
the EVM functionality and the additional auditing msgs.  

> > The first msg was generated by a test program attempting to read a file
> > that was already open for write.  The second msg was generated by a test
> > program attempting to write a file that was already open for read, thus
> > previously measured.
> >
> > integrity_audit_pcr() msgs:
> > Aug 23 17:29:02 L3X098X kernel: audit(1187904542.211:2): integrity:
> > invalidate pcr(measured file has writers) for pid=5864 comm="tt_read1"
> > name="/tmp/hello"
> 
> The linux audit system has to fulfill some basic audit requirements. Its 
> required for each event to answer some basic questions like: who initiated 
> the event, what were they doing, what resource was involved, and were they 
> successful? Because we store millions of records, it has to as short as 
> possible.
> 
> Typically, we know what is happening by the record type. Where that need 
> further explaining, we usually have "op=something". But its kept to 1 or two 
> word separated by a hyphen if its important for the parsers to be able to 
> associate the words with an op.
> 
> The above message needs to have auid so that we know who initiated the action.  
> It also should have res=0 or res=1 at the end to indicate success or failure. 
> 0 being failure and 1 being success. Also, this audit record has only a file 
> name in it. Because mount points can change the names of things, you should 
> also probably include the device and inode to help identify what is really 
> being reported. 

Ok. Based on your comments, would the following format be acceptable?

	integrity: pid= auid= comm= name= dev= inode= op= res=

Although both integrity_audit() and integrity_audit_pcr() would have 
the same format, integrity_audit() would be used to report the results
of integrity_verify_metadata()/data(), while integrity_audit_pcr()
would report the results of extending the PCR register.

For integrity_audit_pcr, the op would be:
	op=invalidate_pcr(ToMToU)
	op=invalidate_pcr(open_writers)
	
	op=add_measure(ENOMEM)
	op=add_measure(null_hash)
	op=add_measure(long_digest)
	op=add_measure

For integrity_audit(), the op would probably be something similar to:
	op=verify_metadata
	op=verify_data

> If selinux is enabled, this event should also have obj= and 
> the selinux context. The subj should be likewise recorded.

This brings us back to the original question as to who should be emitting 
the integrity audit msgs.  If the LIM provider is emitting the audit msg, 
then shouldn't it be LSM agnostic?

> > Aug 23 17:29:14 L3X098X kernel: audit(1187904554.964:3): integrity:
> > invalidate pcr(ToMToU violation) for pid=5870 comm="tt_write1"
> > name="/tmp/hello"
> 
> What about examples of the other message types? This looks like its the same 
> kind as the above.

There are now two message types as described above.

Mimi Zohar