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

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.

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

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

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