Re: Integrity auditing

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

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

Re: Integrity auditing

[Steve Grubb]

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

Re: Integrity auditing

[Mimi Zohar]

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

Re: Integrity auditing

[Steve Grubb]

On Monday 10 September 2007 16:16:23 Mimi Zohar wrote:
> > 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=

How about:

pid= uid= auid= subj= op= comm= res=

pid, uid, comm are not really required, but they are nice to have.

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

For the last 3 messages op=setup hash=

But in a way, this really sounds like you need 2 event types. One for IMA and 
one for hash selection. This is because they are doing fundamentally 
different things.

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

Sure. optionally, you could put uid= right before auid=. The selinux labels 
are missing. So, I'd suggest an order like this:

 pid= uid= auid= subj= op= comm= name= dev= inode= obj= 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.

OK

> For integrity_audit_pcr, the op would be:
>         op=invalidate_pcr(ToMToU)
>         op=invalidate_pcr(open_writers)

what you have in parenthesis should probably be name=value.

>         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

Again, this sounds like you need 3 audit event types since the messages are 
trying to express something different. 

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

We just went through an LSPP certification of the Linux kernel. We have labels 
on everything. We really need to keep the standard since its a lot of trouble 
to hunt these all down and fix next time the kernel goes through a common 
criteria certification. I don't know enough about your subsystem to say who 
should do it. But we should have the labels in a portable fashion. What we 
were doing is something like this:

                        struct audit_aux_data_ipcctl *axi = (void *)aux;
                        audit_log_format(ab,
                                 "ouid=%u ogid=%u mode=%x",
                                 axi->uid, axi->gid, axi->mode);

^^^ This would be the normal part that is for CAPP. The next part optionally 
does the obj if selinux is enabled:

                        if (axi->osid != 0) {
                                char *ctx = NULL;
                                u32 len;
                                if (selinux_ctxid_to_string(
                                                axi->osid, &ctx, &len)) {
                                        audit_log_format(ab, " osid=%u",
                                                        axi->osid);
                                        call_panic = 1;
                                } else 
                                        audit_log_format(ab, " obj=%s", ctx);
                                kfree(ctx);
                        }

By doing this, people that have selinux get the labels, the people without 
selinux do not have wasted space in the audit logs.

Thanks,
-Steve