Re: Another slab size-32 leak 2.6.16-rc4-mm2
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