From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ondrej Mosnacek Subject: Re: [PATCH ghak95] audit: Do not log full CWD path on empty relative paths Date: Mon, 27 Aug 2018 14:42:43 +0200 Message-ID: References: <20180802114436.1209-1-omosnace@redhat.com> <1831216.TGRH1GiodL@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx11.extmail.prod.ext.phx2.redhat.com [10.5.110.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E1DBBA239A for ; Mon, 27 Aug 2018 12:42:56 +0000 (UTC) Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1FAD030842AA for ; Mon, 27 Aug 2018 12:42:56 +0000 (UTC) Received: by mail-oi0-f71.google.com with SMTP id w185-v6so14593377oig.19 for ; Mon, 27 Aug 2018 05:42:56 -0700 (PDT) In-Reply-To: <1831216.TGRH1GiodL@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Richard Guy Briggs , Linux-Audit Mailing List List-Id: linux-audit@redhat.com On Fri, Aug 24, 2018 at 5:14 PM Steve Grubb 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 wrote: > > > On Thu, Aug 2, 2018 at 7:45 AM Ondrej Mosnacek > 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 Associate Software Engineer, Security Technologies Red Hat, Inc.