From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH] audit: fix event coverage of AUDIT_ANOM_LINK Date: Mon, 03 Dec 2012 14:39:32 -0500 Message-ID: <5113631.iXCyjqx8K6@x2> References: <20121128225744.GA11697@www.outflux.net> <16520996.L0klPuef56@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Kees Cook Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday, December 03, 2012 11:24:31 AM Kees Cook wrote: > >> type=UNKNOWN[1702] msg=audit(1354215561.568:5): op=follow_link > >> ppid=1972 pid=1988 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > >> sgid=0 fsgid=0 ses=1 tty=pts0 comm="cat" exe="/bin/cat" res=0 > > > > The problem is that this is too much like a syscall record. You should > > delete all duplicated fields so that we don't waste disk space. But if we > > do that, the only field left is "op=follow_link". The other possibility > > for op is linkat. So, wouldn't those be determinable by the syscall > > associated with event? So, that means that the record identifier is the > > only thing of value. Normally, we give events some meaning by using a > > different key to be associated with the event so that it can be grouped > > for the threat that it is. > > Without the duplicated information it doesn't correlate. I tried > leaving out task_info dump, and the search returned nothing. Correlation is done by the timestamp and the serial number within the millisecond - its between the parenthesis in second field. Ausearch knows how to keep the auxiliary records aligned with the main record, which is syscall. > > What I'd really suggest that we do is see how we can detect this with the > > current rule matching engine so that we can detect this condition without > > the need for special purpose event. > > I'm happy to do whatever you suggest. I have this feeling that -F filetype=symlink is not working as it probably should. I'll have to do some digging around to see how we can fix that. -Steve > >> type=PATH msg=audit(1354215561.568:5): item=0 name="/tmp/evil" > >> inode=19 dev=fd:01 mode=0120777 ouid=1000 ogid=1000 rdev=00:00 > >> type=SYSCALL msg=audit(1354215561.568:5): arch=c000003e syscall=2 > >> success=no exit=-13 a0=7fffba5b7955 a1=0 a2=0 a3=7fffba5b5940 items=0 > >> ppid=1972 pid=1988 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > >> sgid=0 fsgid=0 ses=1 tty=pts0 comm="cat" exe="/bin/cat" key=(null) > > -Kees