From: Steve Grubb <sgrubb@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH] audit: fix event coverage of AUDIT_ANOM_LINK
Date: Mon, 03 Dec 2012 14:39:32 -0500 [thread overview]
Message-ID: <5113631.iXCyjqx8K6@x2> (raw)
In-Reply-To: <CAGXu5jJdBM=EAj9T1tCeVXNBWK8f0Pb0x6N+6=KEp-jLRHcH=g@mail.gmail.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
prev parent reply other threads:[~2012-12-03 19:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-28 22:57 [PATCH] audit: fix event coverage of AUDIT_ANOM_LINK Kees Cook
2012-11-29 15:10 ` Steve Grubb
2012-11-29 19:02 ` Kees Cook
2012-12-03 16:25 ` Steve Grubb
2012-12-03 19:24 ` Kees Cook
2012-12-03 19:39 ` Steve Grubb [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5113631.iXCyjqx8K6@x2 \
--to=sgrubb@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox