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