Re: [PATCH ghak95] audit: Do not log full CWD path on empty relative paths
On Fri, Aug 24, 2018 at 5:14 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
On Friday, August 24, 2018 11:00:35 AM EDT Paul Moore wrote:
> On Thu, Aug 2, 2018 at 8:03 PM Paul Moore <paul(a)paul-moore.com> wrote:
> > On Thu, Aug 2, 2018 at 7:45 AM Ondrej Mosnacek <omosnace(a)redhat.com>
wrote:
> > > When a relative path has just a single component and we want to emit a
> > > nametype=PARENT record, the current implementation just reports the
> > > full CWD path (which is alrady available in the audit context).
It is supposed to report the parent directory of the object (file). Never
mind about CWD. That tells us where the command was issued from. Sometimes
that is important even if it is already in a PATH record. It is more forensic
information.
Yes, the problem is that if the path is just a file name (say,
"file.txt"), then the kernel assumes that the parent directory is the
CWD and puts its absolute path into the PATH record (probably because
putting in an empty path seemed weird or is not even valid). But with
*at(2) syscalls the parent directory can be some other directory
(specified by the dirfd argument of the syscall), so the assumption is
wrong. In both cases we really should report relative path to the
directory, which is always just ".". This is consistent with how other
relative paths are handled, e.g. "dir/subdir/file.txt" will produce a
parent PATH record with "dir/subdir" (the path stays relative) and a
child record with "file.txt".
> > > This is wrong for three reasons:
> > > 1. Wasting log space for redundant data (CWD path is already in the CWD
> > > record).
A CWD record is always expected for a file system operation. We are not
missing any right now. Just don't want to lose them.
> > > 2. Inconsistency with other PATH records (if a relative PARENT
> > > directory path contains at least one component, only the verbatim
> > > relative path is logged).
> > > 3. In some syscalls (e.g. openat(2)) the relative path may not even be
> > > relative to the CWD, but to another directory specified as a file
> > > descriptor. In that case the logged path is simply plain wrong.
This can be fixed in the reporting tools. The biggest problem is when we have
several PATH records figuring our how they are all related.
Yes, but to enable fixing this, we need to keep relative paths
relative. Only then can we properly do the next step of:
a) adding sufficient information to specify what directory the path is
relative to (basically what GHAK #9 is about),
b) recognizing this information in userspace and converting relative
paths to absolute based on that information.
> > > This patch modifies this behavior to simply report "." in the
> > > aforementioned case, which is equivalent to an "empty" directory
path
> > > and can be concatenated with the actual base directory path (CWD or
> > > dirfd from openat(2)-like syscall) once support for its logging is
> > > added later. In the meantime, defaulting to CWD as base directory on
> > > relative paths (as already done by the userspace tools) will be enough
> > > to achieve results equivalent to the current behavior.
> >
> > I have to ask the obvious question, if we already have the necessary
> > parent path in the CWD record, why do we need a nametype=parent PATH
> > record anyway?
CWD is where the command was issued from. Sometimes it can be used as a
PARENT PATH record. But what if name resolution fails at the parent
directory? That record turns out to be all we get.
> > Can we safely remove it or will that cause problems for Steve's userspace
> > tools?
The PARENT records are used in figuring out what is really happening in
certain cases.
-Steve
--
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.