possible "comm"

possible "comm"

[LC Bruzenak]

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@magitekltd.com

Re: possible "comm"

[Steve Grubb]

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

Re: possible "comm"

[LC Bruzenak]

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@magitekltd.com

Re: possible "comm"

[Steve Grubb]

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