Integrity auditing

[Steve Grubb]

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.


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


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

Thanks,
-Steve