On Mon, Dec 3, 2012 at 8:25 AM, Steve Grubb <[email protected]> wrote: > On Thursday, November 29, 2012 11:02:21 AM Kees Cook wrote: >> On Thu, Nov 29, 2012 at 7:10 AM, Steve Grubb <[email protected]> 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 <[email protected]> >> >> Signed-off-by: Kees Cook <[email protected]> >> >> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
