[redhat-lspp] Re: [PATCH] change lspp inode auditing

Serge E. Hallyn serue at us.ibm.com
Thu Mar 30 15:21:42 UTC 2006


Quoting Stephen Smalley (sds at tycho.nsa.gov):
> On Wed, 2006-03-29 at 13:18 -0600, Serge E. Hallyn wrote:
> > 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.
> 
> People seem to constantly forget that SIDs aren't persistent and that
> kernel SIDs aren't exported to userspace.  So it doesn't help much to
> augment them with a policy version.

I wasn't suggesting exporting the sid to userspace.

I was suggesting a way to help ensure we never do.

> However, that does bring up a separate issue beyond the inability to
> allocate the context; the SID may be invalidated by a policy load, at

That was what I was addressing.

> which point you'll get back the unlabeled context upon subsequent
> attempts to map it to a context.  Hence, if you have a policy reload

You couldn't end up with a completely wrong context this way?

> between the time you collect the SID and the time you generate the
> context, you could "lose" the actual context information.  But I think
> that is mostly a documentation/procedural issue - don't ever remove
> labels from the policy upon policy updates.

-serge




More information about the Linux-audit mailing list