Re: [redhat-lspp] Re: [PATCH] change lspp inode auditing
Quoting Stephen Smalley (sds(a)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