Re: [redhat-lspp] Re: [PATCH] change lspp inode auditing
On Wed, 2006-03-29 at 14:15 -0500, Steve Grubb wrote:
In that case, the patch writes out the sid number. Given a sid, is
there a way
to find it in the policy on disk? If not, that might be useful to have.
SIDs aren't persistent identifiers. Just runtime values generated on
demand. There is no persistent mapping of them to contexts. That is by
design.
If we record the sid number, do we really need to call audit_panic?
See above. The SID is useless for off-line analysis, and you'd have to
inspect kernel memory to even map it to a context - kernel SIDs aren't
exported to userspace. Again, by design.
Yes, I copy and pasted and changed the name based on a suggestion
from Darrel.
What is the status of that API? Did it go into 2.6.17 tree? I'd like to code
to that API if it were available.
I assumed that Darrel's patch was feeding into the audit tree. It
looked sane to me, but I assumed that there would be a final resolution
on integrating it with Tim's patch and with Amy's work, and a final
version of the patch would then be posted?
Agreed, that was messy.
I think that the existing hook interfaces were based on the existing
pattern for proc and xattrs, where the caller always supplied a buffer,
as those were the initial users of those hooks. But I would prefer the
normal SELinux model of allocating the buffer internally and returning
it to the caller.
I'll make changes as you suggested and we can try this again. Is
there a place
I can grab James' iptables SE Linux interface to patch the lspp kernel with?
I'd like to use that if its accepted/done. It'll make merging Tim's patch
easier.
James' patches are still considered experimental as they rely on
infrastructure changes to iptables that aren't likely to get in very
soon. So I'd just go with Darrel's patch, try to merge with Tim's work,
and use that.
--
Stephen Smalley
National Security Agency