Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751612AbdITQwg (ORCPT ); Wed, 20 Sep 2017 12:52:36 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:34577 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499AbdITQwf (ORCPT ); Wed, 20 Sep 2017 12:52:35 -0400 X-Google-Smtp-Source: AOwi7QBV/ISzCWzIM8IH1/I6TrIC+ZP4j5IznBaUGDKE2lUkI9oYmPpqAivfizKgS2Uu2Z2vCcDiDUdnUDLBve0zHfI= MIME-Version: 1.0 X-Originating-IP: [108.49.102.27] In-Reply-To: References: From: Paul Moore Date: Wed, 20 Sep 2017 12:52:32 -0400 Message-ID: Subject: Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents To: Richard Guy Briggs Cc: linux-kernel@vger.kernel.org, linux-audit@redhat.com, Steven Rostedt Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v8KGqgmU012647 Content-Length: 5925 Lines: 119 On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs wrote: > Tracefs or debugfs were causing hundreds to thousands of null PATH > records to be associated with the init_module and finit_module SYSCALL > records on a few modules when the following rule was in place for > startup: > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load > > This happens because the parent inode is not found in the task's > audit_names list and hence treats it as anonymous. This gives us no > information other than a numerical device number that may no longer be > visible upon log inspeciton, and an inode number. > > Fill in the filesystem type, filesystem magic number and full pathname > from the filesystem mount point on previously null PATH records from > entries that have an anonymous parent from the child dentry using > dentry_path_raw(). > > Make the dentry argument of __audit_inode_child() non-const so that we > can take a reference to it in the case of an anonymous parent with > dget() and dget_parent() to be able to later print a partial path from > the host filesystem rather than null. > > Since all we are given is an inode of the parent and the dentry of the > child, finding the path from the mount point to the root of the > filesystem is more challenging that would involve searching all > vfsmounts from "/" until a matching dentry is found for that > filesystem's root dentry. Even if one is found, there may be more than > one mount point. At this point the gain seems marginal since > knowing the filesystem type and path are a significant help in tracking > down the source of the PATH records and being to address them. > > Sample output: > type=PROCTITLE msg=audit(1488317694.446:143): proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 > type=PATH msg=audit(1488317694.446:143): item=797 name=tracefs(74726163):/events/nfs4/nfs4_setclientid/format inode=15969 dev=00:09 mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=CREATE > type=PATH msg=audit(1488317694.446:143): item=796 name=tracefs(74726163):/events/nfs4/nfs4_setclientid inode=15964 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT > ... > type=PATH msg=audit(1488317694.446:143): item=1 name=tracefs(74726163):/events/nfs4 inode=15571 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=CREATE > type=PATH msg=audit(1488317694.446:143): item=0 name=tracefs(74726163):/events inode=119 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT > type=UNKNOWN[1330] msg=audit(1488317694.446:143): name="nfsv4" > type=SYSCALL msg=audit(1488317694.446:143): arch=c000003e syscall=313 success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod" subj=system_u:system_r:insmod_t:s0 key="mod-load" > > See: https://github.com/linux-audit/audit-kernel/issues/8 > Test case: https://github.com/linux-audit/audit-testsuite/issues/42 > > Signed-off-by: Richard Guy Briggs > > --- > v3: > fix audit_buffer leak and dname error allocation leak audit_log_name > only put audit_name->dentry if it is being replaced > > v2: > minor cosmetic changes and support fs filter patch > --- > include/linux/audit.h | 8 ++++---- > kernel/audit.c | 19 +++++++++++++++++++ > kernel/audit.h | 1 + > kernel/auditsc.c | 8 +++++++- > 4 files changed, 31 insertions(+), 5 deletions(-) ... > diff --git a/kernel/audit.c b/kernel/audit.c > index 59e60e0..d6e6e4e 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -72,6 +72,7 @@ > #include > #include > #include > +#include > > #include "audit.h" > > @@ -2047,6 +2048,10 @@ void audit_copy_inode(struct audit_names *name, const struct dentry *dentry, > name->gid = inode->i_gid; > name->rdev = inode->i_rdev; > security_inode_getsecid(inode, &name->osid); > + if (name->dentry) { > + dput(name->dentry); > + name->dentry = NULL; > + } > audit_copy_fcaps(name, dentry); > } > > @@ -2088,6 +2093,20 @@ void audit_log_name(struct audit_context *context, struct audit_names *n, > audit_log_n_untrustedstring(ab, n->name->name, > n->name_len); > } > + } else if (n->dentry) { > + char *fullpath; > + const char *fullpathp = NULL; > + > + fullpath = kmalloc(PATH_MAX, GFP_KERNEL); > + if (fullpath) > + fullpathp = dentry_path_raw(n->dentry, fullpath, PATH_MAX); > + if (IS_ERR(fullpathp)) { > + fullpathp = NULL; > + kfree(fullpath); > + } > + audit_log_format(ab, " name=%s(0x%lx):%s", > + n->dentry->d_sb->s_type->name ?: "?", > + n->dentry->d_sb->s_magic, fullpathp ?: "?"); > } else > audit_log_format(ab, " name=(null)"); While looking this over one more time before merging I realized that you are missing the curly braces in the "if (fullpath)" if-statement above. This is an easy fix, and appears to be the Right Thing, so I'm just going to fix up the patch while merging; take a look at the result in the audit/next tree and if you have any objections let me know so I can back it out. I'm also only merging this patch right now, patch 2/2 needs to wait until the corresponding userspace is ready so we can test/verify it. -- paul moore www.paul-moore.com