[PATCH] LSPP audit enablement: storing selinux ocontext and scontext

[Stephen Smalley]

On Mon, 2005-08-29 at 17:57 -0400, Steve Grubb wrote:
> I still think it calls audit_panic too easy. How does SE Linux AVC messages 
> get handled when it fails looking up something? Does it call audit_panic or 
> try to output the number? I think they should both match.

Originally, avc_audit was calling printk and assumed that it would
always succeed.  Now, avc_audit uses the audit_log* functions and just
returns silently if audit_log_start fails, consistent with the current
audit system interface to the rest of the kernel.  Failures upon other
audit_log* functions give no indication that anything went wrong to the
caller.  It would take a fairly major reworking of the audit system code
and its interface to propagate errors up the entire call chain to even
reach avc_audit rather than just calling audit_log_lost/audit_panic and
proceeding.  If you were going to do that, I'd think you would want a
new failure mode in audit_panic that causes it to optionally printk a
warning message and return an error code, and alter audit_panic and all
callers to propagate error codes up the call chain.  

For failures outside of the audit system, avc_audit falls back to
logging numeric values if it cannot map to a string (for both access
vectors in avc_dump_av and for SIDs/contexts in avc_dump_query, although
the latter is problematic as SIDs are private to the kernel and have no
meaning in userspace).  For files it always logs the device and inode
information regardless of whether it can log a path, as you want that
information in all cases.

If avc_audit received errors from the audit system, it could also be
changed to return errors to its callers, most of which go through
avc_has_perm. avc_has_perm could then be changed to propagate an error
from either avc_has_perm_noaudit or avc_audit to the caller (the hook
function), which typically propagates errors from avc_has_perm already.

-- 
Stephen Smalley
National Security Agency