Another slab size-32 leak 2.6.16-rc4-mm2

[Stephen Smalley]

On Mon, 2006-03-06 at 13:13 -0600, Klaus Weidner wrote:
> On Mon, Mar 06, 2006 at 10:20:05AM -0500, Stephen Smalley wrote:
> > But ipcperms() isn't called on every IPC operation, in particular not
> > for the ones that apply uid ownership or capability tests rather than
> > mode checks, e.g. SHM_LOCK/UNLOCK.  Compare the coverage of the
> > security_* hooks in the ipc code against the audit-related hooks.
> 
> SHM_LOCK/UNLOCK doesn't look like an "operation on an object" from the
> LSPP point of view (it doesn't read, write, create, destroy, change
> permissions, or similar things), so I don't see a need to audit that one.
> There may be a need to add new hooks for specific functions if they turn
> out to require auditing, but offhand I'm not aware of any.

Ok, I haven't seen any specific analysis document (or just a writeup)
that goes through the IPC operations and categorizes them in this way
for audit, which is why I've been a bit puzzled by (seeming) arbitrary
choices in the audit hooks.  Not to say that such documents / writeups
don't exist, but I haven't seen them...

> Keep in mind that LSPP requires audit records (including object labels)
> for unsuccessful operations, and as far as I know an access request
> that's rejected by DAC permissions won't call the selinux hook.

True, so that does mean that we can't just leverage the SELinux hooks
for that purpose.  Pity.

-- 
Stephen Smalley
National Security Agency