Re: Problem meeting FAU_SEL with trusted programs
Steve Grubb wrote:
You should use suid for sender user id and sauid for sender audit
(login) user
id.
I can do that, but your still suggesting that the data be contained
inside a string in the audit record. It seems like this is not what we
want since then all of the tools will need to look at that string in
addition to the audit fields where the information is always reported.
>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.
I know you can make ausearch meet the FAU_SAR requirement, but I don't
see how the kernel side can do selective audits based on a substring
match of the message, and isn't that what FAU_SEL requires?
>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.
Thats what I want to do as well, make sure the record is attributed to
the user that caused the event.
>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. :)
You don't think its a problem for your tool, but any other tools that
would be built to do log reduction or analysis now have to deal with
matching those strings. That doesn't sound bad to you?
>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.
>Don't we need an audit interface to support that?
Not sure what you would mean.
Something like:
audit_log_message_from_user(int audit_fd, int type, const char *message,
const char *hostname, const char *tty, uid_t uid, uid_t auid)
So that the audit record fields reference the subject of message and not
the trusted program.
-matt