[PATCH] audit: fix event coverage of AUDIT_ANOM_LINK

[Steve Grubb]

On Thursday, November 29, 2012 11:02:21 AM Kees Cook wrote:
> On Thu, Nov 29, 2012 at 7:10 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > On Wednesday, November 28, 2012 02:57:44 PM Kees Cook wrote:
> >> The userspace audit tools didn't like the existing formatting of the
> >> AUDIT_ANOM_LINK event. It needed to be expanded to emit an AUDIT_PATH
> >> event as well, so this implements the change. The bulk of the patch is
> >> moving code out of auditsc.c into audit.c and audit.h for general use.
> >> It expands audit_log_name to include an optional "struct path" argument
> >> for the simple case of just needing to report a pathname. This also makes
> >> audit_log_task_info available when syscall auditing is not enabled so
> >> an admin can make sense of the audit report (which would have only shown
> >> path information, not process information).
> >> 
> >> Reported-by: Steve Grubb <sgrubb at redhat.com>
> >> Signed-off-by: Kees Cook <keescook at chromium.org>
> 
> Hrm, I actually had to unconditionally add the task_info call, and
> that fixed things for me. I can send a v2 if this looks right to you.
> 
> > Do you have a sample record I could check?
> > 
> > ausearch  --start today  -m 1702  --raw  --just-one
> 
> # ausearch  --start today  -m 1702  --raw  --just-one

Thanks for sending a sample...


> 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.

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.

Thanks,
-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