ausearch results differ with "-i" flag
I am doing an ausearch and noticed that with the "-i" flag the "comm=" field appears to lose the data.
The bad thing is that this appears inside the "msg=" string, and I feel that it shouldn't be interpreting those values anyway.
I saw that the audit-viewer does parse out the "comm=" field correctly when I look at the same event.
First the event without the "-i" flag:
----time->Tue Mar 16 21:53:50 2010
node=jcdx type=USER_AVC msg=audit(1268776430.236:6808): user pid=2835 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc: denied { write } for request=X11:PolyRectangle comm=MLTracks resid=5d restype=WINDOW scontext=user_u:user_r:user_t:s6:c0.c511 tcontext=system_u:object_r:xdm_rootwindow_t:s0-s15:c0.c1023 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
----
Same event appears to lose the "comm" field with the "-i" flag:
----
node=jcdx type=USER_AVC msg=audit(03/16/2010 21:53:50.236:6808) : user pid=2835 uid=root auid=unset ses=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc: denied { write } for request=X11:PolyRectangle comm=(null) resid=5d restype=WINDOW scontext=user_u:user_r:user_t:s6:c0.c511 tcontext=system_u:object_r:xdm_rootwindow_t:s0-s15:c0.c1023 tclass=x_drawable : exe=/usr/bin/Xorg (sauid=root hostname=?, addr=?, terminal=?)'
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 8 lines · LC Bruzenak
I am doing an ausearch and noticed that with the "-i" flag the "comm=" field appears to lose the data.
The bad thing is that this appears inside the "msg=" string, and I feel that it shouldn't be interpreting those values anyway.I saw that the audit-viewer does parse out the "comm=" field correctly when I look at the same event.
Quoted 12 lines
First the event without the "-i" flag:
----time->TueMar 16 21:53:50 2010
node=jcdx type=USER_AVC msg=audit(1268776430.236:6808): user pid=2835 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc: denied { write } for request=X11:PolyRectangle comm=MLTracks resid=5d restype=WINDOW scontext=user_u:user_r:user_t:s6:c0.c511 tcontext=system_u:object_r:xdm_rootwindow_t:s0-s15:c0.c1023 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
----
comm's value should be in double-quotes unless it has special characters and then it should be hex encoded. The reason being is comm could have a white space in its name .
-Steve
Quoted 22 lines · Steve Grubb
Quoted 8 lines · LC Bruzenak
I am doing an ausearch and noticed that with the "-i" flag the "comm=" field appears to lose the data.
The bad thing is that this appears inside the "msg=" string, and I feel that it shouldn't be interpreting those values anyway.I saw that the audit-viewer does parse out the "comm=" field correctly when I look at the same event.
Quoted 12 lines
First the event without the "-i" flag:
----time->TueMar 16 21:53:50 2010
node=jcdx type=USER_AVC msg=audit(1268776430.236:6808): user pid=2835 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc: denied { write } for request=X11:PolyRectangle comm=MLTracks resid=5d restype=WINDOW scontext=user_u:user_r:user_t:s6:c0.c511 tcontext=system_u:object_r:xdm_rootwindow_t:s0-s15:c0.c1023 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
----
Quoted 3 lines
comm's value should be in double-quotes unless it has special characters and then it should be hex encoded. The reason being is comm could have a white space in its name .
Why would white space inside a quoted string cause it to be hex encoded?
Maybe my memory is fuzzy and I haven't been carefully tracking the audit changes lately. String values never used to be quoted, right? When did quotes get added? Did we add quotes around strings but preserve the hex encoding for strings? That would mean even though strings are marked as strings by virtue of being quoted you still need a hard coded list of what fields are strings so you can test for unadorned hex encoding if the quote is absent. If quotes were added then the unadorned hex encoding format could have dropped because standard string escapes could have been used inside a quoted string. What happened to the position that changing audit output from the kernel was verboten?
Signature · 4 lines
John Dennis <[email protected]> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Quoted 5 lines · John Dennis
Quoted 3 lines
comm's value should be in double-quotes unless it has special characters and then it should be hex encoded. The reason being is comm could have a white space in its name .
Why would white space inside a quoted string cause it to be hex encoded?
Because someone could start a log injection attack. Comm is controlled by the user which is untrusted. Although they are limited to 15 characters, it might be enough to throw parsing off.
Quoted 2 lines
Maybe my memory is fuzzy and I haven't been carefully tracking the audit changes lately. String values never used to be quoted, right?
When they are controlled by users, yes.
Quoted 1 line
When did quotes get added?
Back around 2005.
Quoted 1 line
Did we add quotes around strings but preserve the hex encoding for strings?
If the string starts with ", then its safe to parse as is. If not, it is assumed to be hex-encoded.
Quoted 2 lines
What happened to the position that changing audit output from the kernel was verboten?
This particular avc originates from user space. The application needs to follow the rules correctly so it doesn't mess up the logs.
-Steve
Quoted 7 lines · Steve Grubb
Quoted 2 lines
What happened to the position that changing audit output from the
kernel was
Quoted 1 line
verboten?
This particular avc originates from user space. The application needs to follow the rules correctly so it doesn't mess up the logs.
User space, yes, but from the Xorg server. Because X controls accesses internally it apparently audits stuff using the USER_AVC in this way. My confusion is that I thought any freetext should be allowed inside the "msg=" field and not interpreted by ausearch.
I remember a while back though you told me why this can happen...so I need to look back and see. I suspect because the parse libs work as I think and the ausearch/aureport doesn't use those.?.
Thx,
LCB.
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 8 lines · LC Bruzenak
Quoted 2 lines · Steve Grubb
This particular avc originates from user space. The application needs to follow the rules correctly so it doesn't mess up the logs.
User space, yes, but from the Xorg server. Because X controls accesses internally it apparently audits stuff using the
USER_AVCin this way. My confusion is that I thought any freetext should be allowed inside the "msg=" field and not interpreted by ausearch.
It depends on the name of the field. If they use comm, then it has to be properly encoded as any other provider of the comm field's value has to do it.
Quoted 3 lines
I remember a while back though you told me why this can happen...so I need to look back and see. I suspect because the parse libs work as I think and the ausearch/aureport doesn't use those.?.
I'm not sure why you are getting a difference in output. But the field's value is not encoded correctly.
-Steve