Re: [RFC PATCH ghak9 0/3] audit: Record the path of FDs passed to *at(2) syscalls
On Wed, Jul 25, 2018 at 2:48 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wednesday, July 25, 2018 3:44:07 AM EDT Ondrej Mosnacek wrote:
> On Wed, Jul 25, 2018 at 3:11 AM Steve Grubb <sgrubb(a)redhat.com> wrote:
> > On Tuesday, July 24, 2018 6:15:54 PM EDT Paul Moore wrote:
> > > On Tue, Jul 24, 2018 at 10:12 AM Ondrej Mosnacek
<omosnace(a)redhat.com>
> > >
> > > > Beyond that, there is really no information in the records that
would
> > > > allow reconstructing which PARENT path belongs to which
CREATE/DELETE
> > > > path... (Intuitively you can guess that src will come before dst,
but
> > > > that is not very reliable.) I think a "parent inode" field
in the
> > > > PATH
> > > > records could fix this, but maybe there is a better solution...
> > >
> > > I have my suspicions, but I would be curious to hear from Steve how
> > > the reconstruction is typically handled.
> >
> > For any *at function when the dirfd is not AT_FDCWD, it goes badly. If
> > its a old style syscall without the dirfd, then if the first character
> > is '/' use that. Otherwise concatonate cwd and path and pass it to
> > realpath to sort out.
>
> In that case it seems the best fix for openat() et al. would be to
> somehow always force outputting the full path when dirfd != AT_FDCWD.
> Hopefully that won't require too much hacking around...
What is asked for is the full path that dirfd was opened with. I can take
care of everything else.
But where/how should that path be logged? In case of renameat(), for
example, we have 6 (!) path components:
<src_dir>/<src_parent>/<src_child> and
<dst_dir>/<dst_parent>/<dst_child>
(I am assuming the child paths always represent just the last path
component based on the observed inodes of the parent/child records.)
Current record format can distinguish between PARENT and child
(DELETE/CREATE), but there is no nametype for the dirfd path. That's
why I am leaning towards just logging the full "<*_dir>/<*_parent>"
path in the PARENT record. Or do you prefer that we add a new nametype
for the dirfd path?
--
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.