Re: Integrity auditing

[Steve Grubb <sgrubb@redhat.com>]

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.

> > > 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?

> 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?

> 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. If selinux is enabled, this event should also have obj= and 
the selinux context. The subj should be likewise recorded.


> 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.

Thanks,
-Steve