IPC hooks [Re: Another slab size-32 leak 2.6.16-rc4-mm2]

[Klaus Weidner]

On Tue, Mar 07, 2006 at 08:55:46AM -0500, Stephen Smalley wrote:
> On Mon, 2006-03-06 at 13:13 -0600, Klaus Weidner wrote:
> > 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...

The "FSP mapping" document used for Linux CAPP evaluations classifies
syscalls as security relevant or not.

The evaluator used it as one of the inputs to determine if test coverage
(including audit) was complete. The published ones I'm aware of are the
following for RHEL3 and SLES9, maybe someone could publish newer ones?
(hint, hint):

http://www.ibm.com/developerworks/library/os-ltc-security/
ftp://www6.software.ibm.com/software/developer/library/os-ltc-security/sles_eal4_fsp.PDF
ftp://www6.software.ibm.com/software/developer/library/os-ltc-security/RHEL_EAL3_Functional_Specs.pdf

It doesn't specifically examine sub-operations of syscalls separately,
such as SHM_LOCK, so it may not be sufficient in this case. CAPP
obviously didn't care about labels, and the syscall itself was always
audited. So I guess this would need some case by case analysis :-(
It would be preferable to have a central point that guarantees that the
audit record will always be complete.

This gets us back to the discussion in October that Amy already referred
to. I had mentioned the *_checkid() and *get() functions which looked
like promising candidates for hooks since they always need to be called
before doing something to an object:

https://www.redhat.com/archives/linux-audit/2005-October/msg00041.html

I don't know the code well enough to know if that works or would have bad
side effects, any comments?

-Klaus