[PATCH] audit: audit on the future execution of a binary.

[Richard Guy Briggs]

On Sun, Jul 07, 2013 at 03:41:41PM -0700, Peter Moody wrote:
> 
> On Wed, Jul 03 2013 at 19:48, Richard Guy Briggs wrote:
> > On Thu, Aug 23, 2012 at 12:24:00PM -0700, Peter Moody wrote:
> >> This adds the ability audit the actions of a not-yet-running process,
> >> as well as the children of a not-yet-running process.
> >
> > Hi Peter,
> >
> > I've gone back over the discussion of this feature and some of the
> > background in the past couple of years on this list...
> >
> > We've got a kernel deadline coming up in the next month if we want to
> > get something included in RHEL7 if you have the interest and time to
> > evolve this patch (the userspace patch can follow...).
> >
> > As has been discussed, passing in an inode reference is incomplete,
> > since it would need to be qualified by a device reference at minimum.
> > And even then, it isn't atomic and could change by the time the kernel
> > even sees this rule request.
> >
> > So, the next step is to convert the path to a device/inode in the kernel.  If
> > this is done at the time of registering the filter rule, if/when the
> > rule is invalidated then the rule would be dropped, logged.  It also
> > means that anything else also hardlinked to it would be acted upon.
> >
> > Going one step further, if instead we can arrange an fsnotify() hook on
> > rule registration, we could act on that path when it is executed,
> > renamed, unlinked (and destroyed if the refcount goes to zero), etc.
> >
> > So, it should be passed as a path, logging the rule addition with path
> > only at first.  When the rule is triggered then log the requested path,
> > effective path, device/inode along with the user context.
> >
> > The user, carefully crafting other rules can give other information.
> >
> > A watch on the containing directory (/usr/bin) could help in case that
> > executable pathname disappears and re-appears since the containing
> > directory is less likely to go away, but it will be noisy.
> >
> > Does all this make sense?
> 
> Hey Richard,
> 
> Sorry for the late reply, we had a short week last week.

No worries.

> This makes a lot of sense, yes. Unfortunately I think it's unlikely that
> I'll have a chance to work on this in time for your freeze b/c my wife
> is due on Friday and as much as I'd like to thin that I'll be able to
> get some free time during paternity leave to do some kernel hacking,
> everyone tells me I'm crazy to think that.

A bit delusional, yes.  First child, I gather.  Welcome to parenting.
It is quite a ride.  It can be a lot of fun.  :)

> I *think* I'm the only one who's been asking for this feature, so
> hopefully my not getting to it won't be putting anyone out.

What's your timeline and availability?

> Cheers,
> peter
> 
> > Let's deal later with namespaces, containers, mounts, chroots, bind
> > mounts, etc...

- RGB

--
Richard Guy Briggs <rbriggs at redhat.com>
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545