Re: IPC auditing (Was: Re: Another slab size-32 leak 2.6.16-rc4-mm2)
On Tuesday 28 February 2006 16:01, Stephen Smalley wrote:
On Tue, 2006-02-28 at 15:20 +0100, Stephan Mueller wrote:
> [...]
>
> error_path:
> kfree(ctx);
> audit_panic("error in audit_ipc_context");
>
> You free ctx although it has not been allocated - I do not like that ;-)
Common convention is to initialize ctx to NULL upon declaration, and
then such kfree() calls are safe on the error path.
uh, I see. Nevermind :-)
> Please tell me if I misunderstand anything: The question for you
> is whether to keep this function. This function is about to collect
> labels for IPC functions. If this function is gone, you cannot audit any
> labels for the IPC functions any more?!
IIUC, they are asking about which IPC functions/operations require
collection of the labels, not whether the labels should be audited at
all. At present, audit_ipc_context is being called indirectly via
audit_ipc_perms from various IPC_SET operations and directly from
ipcperms() (but the latter is being proposed for removal). I think that
there is some confusion here because in the CAPP case, the basic syscall
auditing provides much of the required information and you therefore
don't need additional hooks except in the IPC_SET case? Whereas in the
LSPP case we need to always be collecting the label information?
Indeed, the LSPP audit always needs the labels of the involved parties:
subjects and objects. There is no exception to this rule.
> If this is the case, then this function needs to stay, because:
>
> - syscalls msg*, sem*, shm* (except shmdt) do DAC checks - now, they also
> perform MAC checks by calling appropriate SELinux hooks (as required by
> the ST as IPC mechanisms are subject to MAC - I think shmdt now must also
> be subject to MAC at least), then these syscalls must perform audit
shmdt merely detaches a previously attached segment from the address
space of the calling process - there is nothing new to check there, and
the real work is all deferred anyway until the close method is called.
If the process was authorized to shmat() the object in the first place,
then it should be allowed to shmdt() it from its own address space.
I was not sure of that for shmdt - but based on your description, no audit
would be required.
> - the audit requirement for IPC calls is specified in FAU_GEN.1.1 LSPP in
> the table: "All decisions on requests for information flow" must be
> audited
>
> - FAU_SAR.3 LSPP requires that subject and object sensitivity labels are
> to be audited.
>
> Ergo, the functionality in question must stay.
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).
Ciao
Stephan