4:01 p.m.
While looking through some audit events in the audit-viewer I saw what I
thought might be a display error (see below "comm="), however when I
look at the event using ausearch I see the same thing:
# ausearch -ts recent -i -a 50457
----
type=SOCKADDR msg=audit(07/31/2008 15:37:43.602:50457) : saddr=inet
host:127.0.0.1 serv:16001
type=SYSCALL msg=audit(07/31/2008 15:37:43.602:50457) : arch=x86_64
syscall=connect success=no exit=-111(Connection refused) a0=10
a1=2f96d30 a2=10 a3=7fff13ee75dc items=0 ppid=22794 pid=23014 auid=root
uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
fsgid=root tty=pts3 ses=818 comm=/usr/share/audi exe=/usr/bin/python
subj=root:auditadm_r:auditadm_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(07/31/2008 15:37:43.602:50457) : avc: denied
{ recvfrom } for pid=23014 comm=/usr/share/audi saddr=127.0.0.1
src=16001 daddr=127.0.0.1 dest=58356 netif=lo
scontext=root:auditadm_r:auditadm_t:s15:c0.c1023
tcontext=root:auditadm_r:auditadm_t:s15:c0.c1023 tclass=association
The
exe=/usr/bin/python.
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
3:31 p.m.
On Thursday 31 July 2008 17:01:22 LC Bruzenak wrote:
While looking through some audit events in the audit-viewer I saw
what I
thought might be a display error (see below "comm="), however when I
look at the event using ausearch I see the same thing:
# ausearch -ts recent -i -a 50457
----
type=SOCKADDR msg=audit(07/31/2008 15:37:43.602:50457) : saddr=inet
host:127.0.0.1 serv:16001
type=SYSCALL msg=audit(07/31/2008 15:37:43.602:50457) : arch=x86_64
syscall=connect success=no exit=-111(Connection refused) a0=10
a1=2f96d30 a2=10 a3=7fff13ee75dc items=0 ppid=22794 pid=23014 auid=root
uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
fsgid=root tty=pts3 ses=818 comm=/usr/share/audi exe=/usr/bin/python
subj=root:auditadm_r:auditadm_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(07/31/2008 15:37:43.602:50457) : avc: denied
{ recvfrom } for pid=23014 comm=/usr/share/audi
You are referring to comm ^^ ?
http://lxr.linux.no/linux/include/linux/sched.h#L201
The define is 16 characters long. This is to give you a hint about what it is
that the interpreter might be executing. When its full path, you only get the
first 16 chars, when someone just uses the command name and lets the shell
find it, its more likely what you wanted.
comm is not 100% trustworthy but it helps you figure out what was being
interpreted. My guess would be audit-viewer in this case.
-Steve
5:18 p.m.
On Mon, 2008-08-04 at 16:31 -0400, Steve Grubb wrote:
On Thursday 31 July 2008 17:01:22 LC Bruzenak wrote:
> While looking through some audit events in the audit-viewer I saw what I
> thought might be a display error (see below "comm="), however when I
> look at the event using ausearch I see the same thing:
>
> # ausearch -ts recent -i -a 50457
> ----
> type=SOCKADDR msg=audit(07/31/2008 15:37:43.602:50457) : saddr=inet
> host:127.0.0.1 serv:16001
> type=SYSCALL msg=audit(07/31/2008 15:37:43.602:50457) : arch=x86_64
> syscall=connect success=no exit=-111(Connection refused) a0=10
> a1=2f96d30 a2=10 a3=7fff13ee75dc items=0 ppid=22794 pid=23014 auid=root
> uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
> fsgid=root tty=pts3 ses=818 comm=/usr/share/audi exe=/usr/bin/python
> subj=root:auditadm_r:auditadm_t:s15:c0.c1023 key=(null)
> type=AVC msg=audit(07/31/2008 15:37:43.602:50457) : avc: denied
> { recvfrom } for pid=23014 comm=/usr/share/audi
You are referring to comm ^^ ?
http://lxr.linux.no/linux/include/linux/sched.h#L201
The define is 16 characters long. This is to give you a hint about what it is
that the interpreter might be executing. When its full path, you only get the
first 16 chars, when someone just uses the command name and lets the shell
find it, its more likely what you wanted.
comm is not 100% trustworthy but it helps you figure out what was being
interpreted. My guess would be audit-viewer in this case.
-Steve
Steve,
I apologize for the poorly-worded email; thanks for the answer. You did
a good job figuring out what I was asking about. :)
Since the audit-viewer script has:
exec /usr/bin/python -O /usr/share/audit-viewer/main.py "$@"
I'd guess that you were pointing in the right direction.
But I would prefer that the comm field be more trustworthy.
In reality, the /usr/bin/audit-viewer executable script really called
the python exec which then interpreted the main.py script...I think. I'm
not getting that from this event, however.
Maybe if I go examine the other events before there I'd get a better
picture to correlate the viewer launch.
I guess the real issue here (as you pointed out) is that we have
different entities - interpreted script/interpreter executable as
opposed to command/resulting executable, but the same structure is used
for each.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
5:45 p.m.
On Monday 04 August 2008 18:18:17 LC Bruzenak wrote:
Since the audit-viewer script has:
exec /usr/bin/python -O /usr/share/audit-viewer/main.py "$@"
I'd guess that you were pointing in the right direction.
But I would prefer that the comm field be more trustworthy.
I don't know how to make it more trustworthy without making it bigger. That
item lives in the task struct and is copied at every fork and rewritten on
exec. using kmalloc would add some overhead and picking anything bigger might
not be acceptable upstream.
Al, do you have any suggestions here?
In reality, the /usr/bin/audit-viewer executable script really
called
the python exec which then interpreted the main.py script...I think. I'm
not getting that from this event, however.
Its almost there. :) You have to make some assumptions which may or may not
be palatable. For one, you have to assume that no one has written anything
you don't know about. And you have to asume that they have not added
directories that you don't know about. Given those boundaries, you can
sometimes guess what it is when full paths are used.
I guess the real issue here (as you pointed out) is that we have
different entities - interpreted script/interpreter executable as
opposed to command/resulting executable, but the same structure is used
for each.
Well, we have 2 models...interpreter + script and just executable. We fit both
into the same structuire as the interpreter is the executable while the
script is the command. When you have an elf binary, the command and the
executable are the same thing.
-Steve
5983
days inactive
5987
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
LC Bruzenak -
Steve Grubb