Integrity auditing

[Mimi Zohar]

On Wed, 2007-09-05 at 11:11 -0400, Steve Grubb wrote:
> On Wednesday 05 September 2007 09:46:06 Mimi Zohar wrote:
> > On Wed, 2007-07-18 at 08:05 -0700, Steve G wrote:
> > > MRPP places some requirements on intergrity checking. Maybe it tells you
> > > more information about what's required. More info:
> > >
> > > http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm?id=PP_OS_ML_MR2.0_V1.91
> 
> This ^^^ spells out some requirements for INTEGRITY checks.
> 
> 
> > > Might ought to be an integrity audit record type rather than avc. This
> > > way aureport can separate it out for its summary report. In
> > > /usr/include/linux/audit.h is this note:
> > >
> > >  * 1800 - 1999 future kernel use (maybe integrity labels and related
> > > events)
> > >
> > > So, we could assign the 1800 block to kernel integrity checking. I think
> > > we'd need information access decision, creation, modification, and
> > > deletion of integrity information/labels. We also probably need the
> > > ability to audit by integrity, too. For a detailed audit discussion, I'd
> > > recommend linux-audit mail list or at least cc'ing it
> >
> > I would assume that the integrity label would be managed by the LIM
> > provider itself. In which case, does it make sense to audit the LIM
> > provider's creation, modification or deletion of the integrity label stored
> > as an xattr?
> 
> Yes. That is required per section FMT_MSA.1(4), assuming this hardware 
> assisted integrity checking code needs to go through any kind of 
> certification.

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?

> > IMA, a LIM provider, implements integrity_measure, which does not require
> > an integrity label. It is, however, important to log/audit PCR invalidation
> > errors.  I propose adding the following audit numbers for integrity.
> >
> > 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.  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.  There 
were two ways of labeling the system, during installation or post install 
using a labeling fixup program.

> > Add to integrity.h:
> > void integrity_audit(char *function, const unsigned char *fname, char
> > *cause); void integrity_audit_pcr(const unsigned char *fname, char *cause);
> > void integrity_audit_err(char *cause);
> 
> Actually, it would be nice to see the messages being generated to see if they 
> have everything needed and that they conform to audit system specs.

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"

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"

Mimi Zohar