From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve Grubb <sgrubb@redhat.com>
Subject: Re: [RFC PATCH ghak9 0/3] audit: Record the path of FDs passed to
	*at(2) syscalls
Date: Wed, 25 Jul 2018 09:11:38 -0400
Message-ID: <3419384.Sre6EZm1hc@x2>
References: <20180712113633.10687-1-omosnace@redhat.com>
	<5402595.goYXf9ZsuL@x2>
	<CAFqZXNsz1xZBXyjWqKZrE2YDPSg7CrZPQ3KCTY4FOmoJx1GZNQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
In-Reply-To: <CAFqZXNsz1xZBXyjWqKZrE2YDPSg7CrZPQ3KCTY4FOmoJx1GZNQ@mail.gmail.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, Linux-Audit Mailing List <linux-audit@redhat.com>
List-Id: linux-audit@redhat.com

On Wednesday, July 25, 2018 9:02:50 AM EDT Ondrej Mosnacek wrote:
> On Wed, Jul 25, 2018 at 2:48 PM Steve Grubb <sgrubb@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@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@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?

You could make a new nametype so that we can make sense of it. But do you 
have all of the required information for a PATH record? I thought that you 
were making a new record type since you have abbreviated information.

-Steve