[PATCH 2/8] integrity: IMA as an integrity service provider

[Mimi Zohar]

On Mon, 2009-02-09 at 09:51 -0500, Steve Grubb wrote: 
> On Sunday 08 February 2009 09:42:42 pm Mimi Zohar wrote:
> > > > diff --git a/security/integrity/ima/ima_audit.c
> > > > b/security/integrity/ima/ima_audit.c new file mode 100644
> > > > index 0000000..8a0f1e2
> > > > --- /dev/null
> > > > +++ b/security/integrity/ima/ima_audit.c
> > > > +void integrity_audit_msg(int audit_msgno, struct inode *inode,
> > > > +			 const unsigned char *fname, const char *op,
> > > > +			 const char *cause, int result, int audit_info)
> > > > +{
> > > > +	struct audit_buffer *ab;
> > > > +
> > > > +	if (!ima_audit && audit_info == 1) /* Skip informational messages */
> > > > +		return;
> > > > +
> > > > +	ab = audit_log_start(current->audit_context, GFP_KERNEL,
> > > > audit_msgno);
> > >
> > > Is this a standalone event or would it be an auxiliary record added to a
> > > syscall record? IOW, if I have a watch on the same file as was being
> > > measured, would the event have the same serial number?
> >
> > Having it as an auxiliary record to syscall seems appropriate. 
> 
> OK. There are are three options then. 
> 
> 1) The first is to just supplement the syscall record whether its there or 
> not. This is kind of what AVCs do. In that case, everything you are logging 
> is fine. 
> 2) Change the audit event really be an auxiliary record that is output at 
> syscall exit only if an audit event has triggered the event. This is more 
> like what the PATH, CWD, or EXECVE records do.
> 3) The last approach is to cause a syscall audit record to be emitted. This is 
> what the MAC_STATUS does. For this case and #2 above, we could shorten the 
> data collected since the syscall record duplicates many fields.

Seems like the first option is applicable here. 

> > There seems to be different behavior if you stop auditd and if it isn't
> > enabled at boot.  In the former case the syscall message still goes
> > to /var/log/messages, while in the latter case it doesn't.
> 
> It all depends on if the audit system is enabled. If its enabled, events go to 
> either the daemon or syslog. If the audit system is not enabled, then the 
> admin didn't want any notification.
> 
> > > If you are depending on a syscall record, it will record much of what's
> > > recorded here for itself and you won't need this much. If you wanted this
> > > to be standalone, I think the call to audit_ log_start has NULL as the
> > > first param so that it cannot be associated with a syscall.
> >
> > yes that works. Some of the messages don't need the syscall info, like
> > in ima_parse_rules().
> 
> The perhaps you want 2 logging functions? Or maybe pass something to the 
> function that determines if it should be related to an existing event or its 
> entirely async.

Ok, I've added a new integrity audit message type for policy rules.  The
individual policy rules don't require the syscall information.  If the
policy contains an invalid rule, in addition to the auditing the policy
rule, audit integrity status and syscall messages are emitted.

> > > > +	audit_log_task_context(ab);
> > > > +	switch (audit_msgno) {
> > > > +	case AUDIT_INTEGRITY_DATA:
> > > > +	case AUDIT_INTEGRITY_METADATA:
> > > > +	case AUDIT_INTEGRITY_PCR:
> > > > +		audit_log_format(ab, " op=%s cause=%s", op, cause);
> > > > +		break;
> > > > +	case AUDIT_INTEGRITY_HASH:
> > > > +		audit_log_format(ab, " op=%s hash=%s", op, cause);
> > > > +		break;
> > > > +	case AUDIT_INTEGRITY_STATUS:
> > > > +	default:
> > > > +		audit_log_format(ab, " op=%s", op);
> > > > +	}
> > > > +	audit_log_format(ab, " comm=");
> > > > +	audit_log_untrustedstring(ab, current->comm);
> > > > +	if (fname) {
> > > > +		audit_log_format(ab, " name=");
> > > > +		audit_log_untrustedstring(ab, fname);
> >
> > Sure would be nice to be able to print the full pathname.
> 
> There is an AUDIT_PATH record that should have the whole path. Its an 
> auxiliary record emitted with the syscall.

Yes, I'm seeing them now.  I had forgotten to add a auditctl syscall
rule. Thanks.

> Maybe we should talk a little about when the different events would be 
> emitted. Would it be just on creation of the hash? Would it be just on a 
> miscompare? IOW, how many records are likely to be created during a typical 
> session?
> 
> Thanks,
> -Steve

IMA measures files, maintains a list of these measurements, and extends
the PCR.  These measurements are not audited, only failure to calculate
the measurement, add an entry to the measurement list, or extend the PCR
is audited. 

Other audit messages include, runtime kernel options, updating the
measurement policy, and measurement violations. The measurement
violations are caused either by opening a file for write, that is
already open for read (ToMToU), or by opening a file for read, that is
already open for write (open_writer).  The number of these errors is
application dependent.

Mimi