Another slab size-32 leak 2.6.16-rc4-mm2

[Klaus Weidner]

On Mon, Feb 27, 2006 at 07:06:56PM -0500, Amy Griffis wrote:
> On Mon, Feb 27, 2006 at 05:03:28PM -0600, Dustin Kirkland wrote:
> > > However, it was intended to collect labels for
> > > message queues during calls to msgget(), msgrcv(), msgsnd(), etc.  The
> > > audit_ipc_perms() hook is only collecting labels (and attempted perm
> > > settings) from IPC_SET operations.
> > 
> > I talked to Klaus about this and I expect him to pipe in right here...
> > 
> > In a nutshell, I was advised back in October that for certification
> > purposes, we're only required to audit ipc operations involving
> > security-relevant permissions checks (similar to our certification
> > requirements on syscall auditing).
> 
> The calls msgget(), msgrcv(), msgsnd(), etc. are doing permission
> checks.  How are these not security-relevant?
> 
> Klaus, if you could explain this I would appreciate it.

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