5:18 p.m.
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=?)'
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
12:03 p.m.
On Tuesday 16 March 2010 06:18:26 pm LC Bruzenak wrote:
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=?)'
----
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
1:49 p.m.
On 03/17/2010 01:03 PM, Steve Grubb wrote:
On Tuesday 16 March 2010 06:18:26 pm LC Bruzenak wrote:
> 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=?)'
> ----
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?
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
1:57 p.m.
On Wednesday 17 March 2010 02:49:38 pm John Dennis wrote:
> 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.
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.
When did quotes get added?
Back around 2005.
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.
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
2:15 p.m.
On Wed, 2010-03-17 at 14:57 -0400, Steve Grubb wrote:
> 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.
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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
3:15 p.m.
On Wednesday 17 March 2010 03:15:30 pm LC Bruzenak wrote:
On Wed, 2010-03-17 at 14:57 -0400, Steve Grubb wrote:
> 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.
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.
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
5439
days inactive
5440
days old
linux-audit@lists.linux-audit.osci.io
5 comments
3 participants
participants (3)
-
John Dennis -
LC Bruzenak -
Steve Grubb