Re: [PATCH] change lspp inode auditing
Quoting Stephen Smalley (sds(a)tycho.nsa.gov):
On Wed, 2006-03-29 at 13:28 -0500, Steve Grubb wrote:
> Hi,
>
> This is a first draft patch to change the auditing of inodes for lspp.
> Previously, we were gathering the context instead of the sid. Now in this patch,
> we gather just the sid and convert to context only if an audit event is being
> output. This patch makes no effort to account for policy_load. It also inserts
> some functions that are likely going upstream via Se Linux kernel people. So,
> that will need to be resolved before this patch is final. In any event its
> good enough to test with. This patch brings the performance hit from
> 146% down to 11%. We need a similar patch for IPC syscall auditing.
Not that I disagree with this change in approach, but I think that when
it has come up in the past, there has been concern expressed about the
fact that we could end up not being able to generate the context from
the SID when the audit record is being emitted (due to OOM condition),
and the operation has already occurred at that point. Of course, there
are also other potential failure cases at the point, so I'm not sure it
is crucial, as long as audit_panic is called as appropriate. Just
wanted to make sure that this point was understood by everyone. But I
agree that pre-allocating the contexts is insane.
Maybe this is a silly idea... but what about just somehow hashing on
(sid,policy_version), where uint policy_version is incremented on each
selinux policy load?
The audit code would fill in an entry for au_ctx_hash(sid,policy_version),
if it isn't already filled in, when the context would previously have been
preallocated. But it stores (sid, policy_version) in the audit record,
and grabs the value from the table when it's time to actually log the
entry, i.e. where Steve's current patch fills in the string.
I guess whether this is worth it depends on how likely we are to lose
information with this current patch on a live system.
Anyway, just a thought.
-serge