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