public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: rgb@redhat.com, linux-audit@redhat.com
Subject: Re: [PATCH ghak95] audit: Do not log full CWD path on empty relative paths
Date: Fri, 24 Aug 2018 11:14:06 -0400	[thread overview]
Message-ID: <1831216.TGRH1GiodL@x2> (raw)
In-Reply-To: <CAHC9VhS-hGUs3C=+e801ovOh7ag_MTWj7eKYnD-N8tGMOA4Ukw@mail.gmail.com>

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@paul-moore.com> wrote:
> > On Thu, Aug 2, 2018 at 7:45 AM Ondrej Mosnacek <omosnace@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.

> > > 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.

> > > 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

  reply	other threads:[~2018-08-24 15:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 11:44 [PATCH ghak95] audit: Do not log full CWD path on empty relative paths Ondrej Mosnacek
2018-08-02 13:29 ` Richard Guy Briggs
2018-08-02 22:24 ` Paul Moore
2018-08-03  7:08   ` Ondrej Mosnacek
2018-08-24 14:09     ` Paul Moore
2018-08-27 13:00       ` Ondrej Mosnacek
2018-09-13 13:57         ` Ondrej Mosnacek
2018-09-13 14:13           ` Paul Moore
2018-09-19  1:35             ` Paul Moore
2018-09-19 11:01               ` Ondrej Mosnacek
2018-09-19 15:44                 ` Paul Moore
2018-10-31  8:54                   ` Ondrej Mosnacek
2018-11-05 23:30                     ` Paul Moore
2018-11-06  8:08                       ` Ondrej Mosnacek
2018-11-06 20:19                         ` Paul Moore
2018-11-13 15:25                           ` Ondrej Mosnacek
2018-11-13 16:30                             ` Paul Moore
2018-12-01 16:50                               ` Steve Grubb
2018-12-04  0:17                                 ` Paul Moore
2018-12-04  8:07                                 ` Ondrej Mosnacek
2018-12-04 22:19                                   ` Paul Moore
2018-08-03  0:03 ` Paul Moore
2018-08-24 15:00   ` Paul Moore
2018-08-24 15:14     ` Steve Grubb [this message]
2018-08-27 12:42       ` Ondrej Mosnacek
2018-08-24 12:59 ` Ondrej Mosnacek
2018-08-24 14:28   ` 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=1831216.TGRH1GiodL@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=rgb@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