Another slab size-32 leak 2.6.16-rc4-mm2

Dustin Kirkland dustin.kirkland at us.ibm.com
Tue Feb 28 23:37:40 UTC 2006


On Tue, 2006-02-28 at 14:27 -0600, Klaus Weidner wrote:
> The discussion in this thread by Stephan Mueller and Stephen Smalley
> covers this already, here's my two cents.
> 
> We have the following separate requirements:
> 
> a) [CAPP and LSPP]: audit the object identity - this happens always since
> it's an integer argument to the IPC call and automatically saved by
> syscall audit.
> 
> b) [CAPP and LSPP]: save additional data from system call pointer
> arguments - this is only needed for *ctl() calls that change permissions
> or other security attributes. I think that was the topic of discussion
> back in October.
> 
> c) [LSPP]: save the subject label - I think this also happens
> automatically.
> 
> d) [LSPP]: save the object label - that's what all the extra hooks are
> needed for, since that's required for all operations on IPC objects.
> (Also information flow decisions but that is mostly equivalent here).
> 
> I like Stephen's proposal to handle (d) from the SELinux hook, since
> that's relevant for LSPP systems only, and this way it avoids intrusive
> changes to the IPC code. (a) and (b) should still keep working in CAPP
> systems without SELinux enabled.

Klaus- are you calling the audit_ipc_perms() calls in ipc/*c too
intrusive?  Does this recommendation gel with the current popular
opinion?  Does this mean that the current audit_ipc_perms() calls in
ipc/*c should be moved into the SELinux code, or rather that additional
code is required in the SELinux code?  

As I understand it, the code as it stands in Viro's git tree performs
all of (a), (b), (c), and (d) sufficiently for collecting the context
of IPC objects, as well as the subject contexts of the initiating
syscalls for LSPP certification.

At this point, I'm trying to understand if there are additional to-do's
beyond the memory leak patch submitted by Steve Grubb and ack'ed by me
earlier in this thread.  If there are, please specify, and if not,
please apply the memory leak patch and let's move on.  I'd like to hear
Al's opinion on the matter, as the audit tree is his now and it's up to
him whether or not to push on to Andrew.



:-Dustin




More information about the Linux-audit mailing list