From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: possible "comm" Date: Mon, 04 Aug 2008 17:18:17 -0500 Message-ID: <1217888297.30693.403.camel@homeserver> References: <1217538082.30693.135.camel@homeserver> <200808041631.45386.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200808041631.45386.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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