Getting the program name in audit messages

[Stephen Smalley]

On Fri, 2005-04-01 at 12:39 +0100, David Woodhouse wrote:
> On Thu, 2005-03-31 at 16:30 -0500, Steve Grubb wrote:
> > @@ -556,39 +555,6 @@ void avc_audit(u32 ssid, u32 tsid,
> >         audit_log_format(ab, "avc:  %s ", denied ? "denied" :
> > "granted");
> >         avc_dump_av(ab, tclass,audited);
> >         audit_log_format(ab, " for ");
> > -       if (a && a->tsk)
> > -               tsk = a->tsk;
> > -       if (tsk && tsk->pid) {
> > -               struct mm_struct *mm;
> > -               struct vm_area_struct *vma;
> > -               audit_log_format(ab, " pid=%d", tsk->pid);
>  ...
> 
> What replaces this information for the normal callers of avc_audit()?

Whenever avc_audit() generates a log message via audit_log*, the
auditable flag is enabled, so audit_log_exit() will be called upon
syscall exit and the exe= and comm= information will then be provided at
that time, and can be correlated with the avc message using the
timestamp and serial number.  That will mean that people will need to
start enabling syscall auditing when using SELinux if they want to
retain the same set of information, but that is preferable to
duplicating the information in both avc_audit and audit_log_exit IMHO.
Note that avc_audit still generates the security context information, so
it still has everything needed to map a denial back to policy rules.   

Note that the change also has side benefits for SELinux:
1) By determining the executable path (exe=) upon syscall exit rather
than within avc_audit, we can collect it more reliably.  Note that the
current avc_audit code has to do an down_read_trylock on the mmap sem
because some callers of avc_audit may already have write locked it (e.g.
from mmap/mprotect hooks); audit_log_exit doesn't have this problem.

2) By moving all of the task-related audit generation to audit_log_exit,
we ensure that we don't include this information incorrectly for avc
denials that aren't in process context.  At present, you can end up with
avc denials with bogus pid and exe information that has no relationship
to the actual denial because the denial occurred in non-process context
(e.g. for network permission checks, for sigio delivery).  This often
confuses users.

I think we should also look into migrating some of the avc_audit
processing for object information to audit_log_exit (via the auxiliary
item list), but this will need to be done carefully based on whether
avc_audit can perform blocking allocation for the permission checks in
question and naturally not for any of the avc_audit processing of
permission checks that are not in process context.

-- 
Stephen Smalley <sds at tycho.nsa.gov>
National Security Agency