Re: Integrity auditing
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