From: Steve Grubb <sgrubb@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: zohar@us.ibm.com, safford@watson.ibm.com,
James Morris <jmorris@namei.org>, Steve G <linux_4ever@yahoo.com>,
linux-audit@redhat.com
Subject: Re: Integrity auditing
Date: Wed, 12 Sep 2007 09:25:51 -0400 [thread overview]
Message-ID: <200709120925.53001.sgrubb@redhat.com> (raw)
In-Reply-To: <1189455383.5809.50.camel@localhost.localdomain>
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
prev parent reply other threads:[~2007-09-12 13:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <604663.1384.qm@web51501.mail.re2.yahoo.com>
[not found] ` <1188999967.5563.2.camel@localhost.localdomain>
2007-09-05 15:11 ` Integrity auditing Steve Grubb
2007-09-05 19:26 ` Mimi Zohar
2007-09-06 17:07 ` Steve Grubb
2007-09-10 20:16 ` Mimi Zohar
2007-09-12 13:25 ` Steve Grubb [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200709120925.53001.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=jmorris@namei.org \
--cc=linux-audit@redhat.com \
--cc=linux_4ever@yahoo.com \
--cc=safford@watson.ibm.com \
--cc=zohar@linux.vnet.ibm.com \
--cc=zohar@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox