[redhat-lspp] security context in audit records (audit.39 kernel)

[Daniel H. Jones]

Stephen Smalley wrote:
> On Tue, 2005-05-17 at 15:17 -0500, Daniel H. Jones wrote:
> 
>>Changes of significance ...
>>new audit_set_selinux_xattr_name function. (please review)
> 
> 
> - I wouldn't explicitly name the function or variable "selinux"; that
> defeats the purpose of having such a function (generality).  Call it
> lspp or mac instead to reflect the notion that any module that
> implements a labeled MAC model can register as such for use by the audit
> framework.
> 
> - Don't make the variable global; keep it static and if necessary,
> define a get function for accessing it outside of the file.  I'd put it
> into auditsc.c rather than audit.c, since that is what uses it, and make
> it static to that file.  Not clear that anyone else needs to access it
> except for setting it by SELinux.  Also can be a const char *.
> 
check ...
> 
>>allocating page for security_getprocattr call.
>>added calls in ipc code to create AUDIT_SECURITY_CONTEXT type records.
> 
> 
> At present, you only deal with the IPC_SET case for the *ctl calls.
> Don't you want to collect the context on all IPC operations?
> 
Right. I did that because audit_ipc_perms only seems to care about 
IPC_SET. I questioned it as well at the time and the answer I received 
is that this is the only interesting operation from a CAPP audit point 
of view because it is the operation that affects the security attributes 
of the object. LSPP merely extends that requirement to include the 
security context in the audit records.

> On a memory allocation failure, I think you need to call audit_panic()
> before returning, which will then handle it depending on the audit
> settings (silently ignoring it, printing a message about it via printk,
> or calling the real panic).  Likewise for errors from the security hook
> other than an error that indicates that the module doesn't implement the
> hook (e.g. for SELinux-disabled kernels), which would be -EINVAL for
> getprocattr and -EOPNOTSUPP for inode_getsecurity.  Any other error,
> like -ENOMEM, from the hook should likely be handled via a call to
> audit_panic() prior to returning as well.
> 
check ...

-- 
Thanks,
Dan Jones
IBM Linux Technology Center, Security
512-838-1794 (T/L 678-1794)
hotrats at us.ibm.com