IPC auditing (Was: Re: Another slab size-32 leak 2.6.16-rc4-mm2)

Stephan Mueller smueller at atsec.com
Tue Feb 28 15:30:01 UTC 2006


On Tuesday 28 February 2006 16:26, Stephen Smalley wrote:
> On Tue, 2006-02-28 at 16:12 +0100, Stephan Mueller wrote:
> > On Tuesday 28 February 2006 16:01, Stephen Smalley wrote:
> > > It sounds like the functionality should actually be expanded based on
> > > the above.  Possibly even calling audit_ipc_context() from the SELinux
> > > hooks themselves to capture all cases.
> >
> > Sorry, I cannot comment on that as I am a bit unfamiliar with SELinux
> > atm. But as said above: subjects and objects must be listed in the audit
> > trail at any case (as long as there is a corresponding object and/or
> > subject).
>
> The reason I suggested it is that we already (hopefully) have complete
> coverage of all security-relevant IPC operations in the set of LSM
> hooks, so if we insert an audit_ipc_context() call into each of the
> SELinux IPC hooks (except for selinux_ipc_permission, as that would
> yield redundant collection), then we should have collection for all
> cases without needing to insert new hooks in the IPC code itself.  Note
> that SELinux itself will already generate an audit record with the
> subject and object contexts if there is a MAC denial, but IIUC, then you
> want the collection to occur always even for success or other forms of
> failure (e.g. DAC denial, general error).

Well, FAU_GEN.1.2 in conjunction with FAU_SAR.3 and FAU_SEL.1 from LSPP are 
quite specific: you are always required to audit the subject/object labels, 
no matter who caused the audit entry (even if it is a DAC related or general 
audit entry - of course, if there is no related subject/object to an audit 
entry, you cannot specify any labels, but if there is, you must list their 
labels in the audit trail).

Regarding the question when an audit entry needs to be produced: FAU_GEN.1.1 
is also quite unambiguous: "All decisions on requests for information flow" 
means that all MAC decisions need to be subject to audit (positive and 
negative).

Ciao
Stephan




More information about the Linux-audit mailing list