3:16 p.m.
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