11:54 a.m.
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.
Since cups is generating audit messages on behalf of the user the uid
and auid fields in the record are those of cupsd and not the user who
submitted the print job.
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.
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.
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? Does ausearch always have to look into the message string to
see if there is a (a)uid there to match on? Can a trusted program be
trusted to pass in the auid and uid to audit? 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?
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.
Don't we need an audit interface to support that?
-matt
12:28 p.m.
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
1:15 p.m.
> 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.
I was wondering about the case where the cron job generates an
audit record but I just tried an experiment and crond uses pam to
set the auid for the cron job so any audit records issued by the cron
job have an auid that matches the user's uid. I wonder if cups
could/should do something similar.
-- ljk
1:33 p.m.
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
1:46 p.m.
On Monday 13 February 2006 14:33, Matt Anderson 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 still don't think this is such a big deal. So far there is only ausearch and
aureport, both of which share parsing code.
>>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?
I was careful with what I was saying. ;)
SEL is a problem. The only high performance way of doing this that I know of
would be to make a new structure to pass this message and the suid & sauid
would be passed. Then we could do the matching on it. Parsing strings in the
kernel does not sound good to me.
Setting the loginuid as Linda suggested would probably be the best answer if
you could do that instead. You'd need to set it at the start of a job saving
away the original and then reset it back upon completion.
>>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?
I'm going to create a library that these other tools can use. This way if we
change to a binary record, the third party tools do not need to be
re-written.
-Steve
6886
days inactive
6886
days old
linux-audit@lists.linux-audit.osci.io
5 comments
3 participants
participants (3)
-
Linda Knippers -
Matt Anderson -
Steve Grubb