Re: [PATCH] audit: fix event coverage of AUDIT_ANOM_LINK
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