[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]