[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH] change lspp inode auditing



Quoting Stephen Smalley (sds 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]