Problem meeting FAU_SEL with trusted programs

[Steve Grubb]

On Monday 13 February 2006 12:54, Matt Anderson wrote:
> After posting my patch last week I got some feedback about a problem
> with FAU_SEL.1 Selectable Audit and FAU_SAR.3 Selectable Audit Review.

> type=USER_LABELED_EXPORT msg=audit(1139496671.166:828):
>  user pid=20396 uid=0 auid=4294967295
>  msg='job=21 user="mra" printer="localp" with labels "secret" "secret":
>   exe="/usr/sbin/cupsd" (hostname=orb.zko.hp.com, addr=16.116.96.203,
>   terminal=pts/1 res=success)'
>
> Even if the audit message string was changed to include 'uid=500' there
> would still be a discrepancy between the various fields of the record.

You should use suid for sender user id and sauid for sender audit (login) user 
id.

> I mentioned this on #audit and Steve said he could add the ability to
> ausearch to look for the uid= substring in the message, but I'm not sure
> that meets the first requirement.

Sure it does. The SAR part means ausearch needs to match on that field.

> If we have two uid and auid fields in all of these trusted program
> generated messages is it always the one in the message string that is
> correct? 

We don't have 2 of each in all messages generated by trusted apps. Its only a 
couple applications that have the problem that you do. I think cups, dbus, 
and nscd are the only ones that come to mind with this problem. Dbus and nscd 
get into this problem because they are user space object managers and need to 
create avc denials. When this gets logged, we ultimately want to attribute 
the avc to the user that made the request that generated the avc.

> Does ausearch always have to look into the message string to 
> see if there is a (a)uid there to match on?

This is not a problem. If it doesn't it will. :)

> Can a trusted program be trusted to pass in the auid and uid to audit?

I would say suid & sauid. There's not much else you can do.

> If it can then there would be only one uid and auid in the record, do we
> need the identification information about the trusted program which passed
> this data to the kernel?

We already have it. The kernel generates the actual uid & auid, not the 
trusted app. suid & sauid would be generated in user space. I don't see any 
easy way to do anything different.

> It seems like other trusted programs (at least cron) will also have this
> problem of a server generating messages on behalf of a user and needing
> to pass audit records into the kernel with that user's information.

Cron doesn't generate any messages to the kernel. The kernel observes any 
violation and records it with the right credentials.

> Don't we need an audit interface to support that?

Not sure what you would mean.

-Steve