From: Eric Paris <eparis@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com
Subject: Re: [PATCH] audit: log on the future execution of a path
Date: Tue, 06 May 2014 10:57:30 -0400 [thread overview]
Message-ID: <1399388250.7627.15.camel@flatline.rdu.redhat.com> (raw)
In-Reply-To: <20140505171007.3d9d15f8@ivy-bridge>
On Mon, 2014-05-05 at 17:10 -0400, Steve Grubb wrote:
> On Mon, 5 May 2014 16:41:53 -0400
> Richard Guy Briggs <rgb@redhat.com> wrote:
>
> > Only problem is, it doesn't work. What assumptions am I making that
> > aren't valid about the approach in this kernel code?
> >
> > I also considered adding the path string pointer to the struct
> > audit_field.
> >
> > Any suggestions?
>
> What I was thinking about is that it should work a lot like a watch for
We agree up to this point.
> execution except when the watch triggers, it actually fills in a pid
> field for a syscall rule and loads it instead of emitting an event.
And now we disagree.
> For example, suppose you had this rule:
> -a exit,always -F arch=b64 -S socket -F 'a0!=1' -F exe=/bin/bash -F
> success=1
>
> It could be started as this:
> -a exit,always -F path=/bin/bash -F perm=x
>
> Then when it triggers, it loads this:
> -a exit,always -F arch=b64 -S socket -F 'a0!=1' -F success=1 -F pid=##
>
> Where ## is the pid known to the kernel. Then when the program exits for
> any reason, the rules it created for that pid are all removed.
>
> It would also need to handle execve/clone/fork/vfork sanely once a
> rule was created.
Please no. Do not dynamically create/delete rules. That's not how the
kernel filter architecture is built and we don't have a need to change
that now.
Instead we want to do what watches do. Insert an fsnotify watch on the
parent directory. If the executable exists, we add the device+inode to
a list of 'watched inodes'. At filter time we'd match similar to
audit_watch_compare using current->mm->exe_file->f_inode
If the executable does not exist when the rule is added, add the
fsnotify watch and do nothing else. Every time you get notification of
the watch check to see if it was about the right file being created and
add the new executable to the 'watched inodes' list.
Obviously you need to watch the fsnotify for the execuable being deleted
and remove it from the 'watched inodes'.
Exactly the same as watches, if the parent directory is removed, we log
that the rule is lost.
Maybe i'll get a couple of minutes this afternoon to code it up...
-Eric
next prev parent reply other threads:[~2014-05-06 14:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 20:41 [PATCH] audit: log on the future execution of a path Richard Guy Briggs
2014-05-05 20:41 ` [PATCH] audit: audit on the future execution of a binary Richard Guy Briggs
2014-05-05 21:10 ` [PATCH] audit: log on the future execution of a path Steve Grubb
2014-05-06 14:57 ` Eric Paris [this message]
2014-05-06 15:10 ` Steve Grubb
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=1399388250.7627.15.camel@flatline.rdu.redhat.com \
--to=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=rgb@redhat.com \
--cc=sgrubb@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