[PATCH] audit: fix event coverage of AUDIT_ANOM_LINK

[Kees Cook]

On Mon, Dec 3, 2012 at 8:25 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> 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.

Without the duplicated information it doesn't correlate. I tried
leaving out task_info dump, and the search returned nothing.

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

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

-- 
Kees Cook
Chrome OS Security