[PATCH ghak95] audit: Do not log full CWD path on empty relative paths

[Ondrej Mosnacek]

On Tue, Nov 6, 2018 at 9:19 PM Paul Moore <paul at paul-moore.com> wrote:
> On Tue, Nov 6, 2018 at 3:09 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> > On Tue, Nov 6, 2018 at 12:30 AM Paul Moore <paul at paul-moore.com> wrote:
> > > Let's reset this discussion a bit ... if we abolish relative paths and
> > > make everything absolute, is there even a need to log PARENT?
> >
> > If there ever was such need, then this won't change when we switch to
> > absolute paths. The PATH records contain some fields (inode, dev, obj,
> > ...) that can be different for the child and parent and I would say
> > these are the only new information that the PARENT records provide
> > over the corresponding CREATE/DELETE records.
>
> Sigh.  Of course the inode information is going to be different
> between the object in question and the parent, they are different
> filesystem objects.  Ask your self the bigger question: does the
> PARENT record provide me any security relevant information related to
> the filesystem object that is being accessed?

I would say it does. Consider e.g. the "mode" and "obj" fields. When
you move (rename) a file from one directory to another (which is the
main, if not the only, case when a PARENT record is emitted), then you
are usually more interested in the values for the parent directory
than the file itself (that's what determines if you can move the
file).

For example, assume you have a rule that logs whenever some sensitive
file gets moved. You do not expect that to happen because you set the
file/directory permissions and labels so that it can't be done by
anyone unauthorized. But something goes wrong, the permissions/labels
get changed somehow and a bad actor leverages the situation to move
the file. Then later you want to investigate this security incident
and as part of it you want to know what permissions were set on the
directories involved that had allowed the file to be moved, because
this may give you a useful lead. With PARENT records, you get such
information, without them you don't.

>
> With the messed up state of path name auditing, the PARENT records are
> useful when trying to recreate the full path used by the process to
> access a given filesystem object (transient as it may be, the path
> name can still be useful after the fact).  If we switch to always
> recording absolute path names, why do we care about recording the
> PARENT filesystem object at all (both the path and the inode
> information)?

I disagree with your assumption that the PARENT record somehow helps
to determine the full path of the (child) filesystem object, in the
sense that it provides more information than what is already contained
in the corresponding CREATE/DELETE record. (Please correct me if
that's not what you were trying to say.) When we log the paths as we
do now, you either get a relative path in both PARENT and
CREATE/DELETE records (the PARENT path just being one element shorter)
or you get a full path in both records (again both will be the same
except the PARENT path will have the last component stripped),
depending on whether the user passed a relative or absolute path to
the syscall [*]. If we switch to always logging full paths, we simply
eliminate the first case (both paths will be always absolute).

Whether we switch to always logging absolute paths or not, the value
of the "path" field of the PARENT record is somewhat redundant (but I
don't see that as a problem).

[*] Disregarding the occasional glitch of getting the (full) path of
current directory as PARENT path when the child path is relative with
just a single component, a.k.a. GHAK #95...

--
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.