Received: by 10.223.164.202 with SMTP id h10csp237949wrb; Wed, 8 Nov 2017 15:31:32 -0800 (PST) X-Google-Smtp-Source: ABhQp+QAGsPEbO5yoRuHgiaUm7syNJQDv5vTSOLpWd1NW/bF1XZr24KOlHlzYnvQ41Sb3Toutb5i X-Received: by 10.98.204.157 with SMTP id j29mr2092674pfk.236.1510183892839; Wed, 08 Nov 2017 15:31:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510183892; cv=none; d=google.com; s=arc-20160816; b=TH6DzIbj6Frw9yrelK1gFmk75epZ+h1sIxFcAN3ARS/wQE3Q3U2kXYzfGLti0vHKu4 tEd7nxSHhRM6HIQgC3qQQ/IA48BZ9CiHeZwjSoYZbAXeFsmkMc4XptqvGNOKXFRNispV Z9cSppHG463OH+I6higp4f1AtZPnw7j1lIPlyznvHCfm4uzcwZqeecFm2U0VIvZhJRKR tVrVfFhrgxMSxpKpaQ0jyQUPX+24k8Wl2bUZoihZ93R6TrCJpAvNR0vOrRTPXrbNLIRd oNWIZHbpcbPCalxHjDFTkg3g7bMfROuF4pjscNqE0wgVU/xuO2rLPAwJ5JS2/GI+Tn5d 6uFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from:arc-authentication-results; bh=eaBM6Wl0JnMyICi07m3K0v9wgpdSOA2g+ZTyYxPhaWk=; b=QJNkBYfsNJThoXO+WisGIfsT6mfwZjh1UNbygiwBZGBltW26eOmjrNef/ivLlBSKqK vumeZv0Ajo+ERGKw/RXL0c9egH82F1kxZVghJd1Gaf6lZHc/Zcuai2RLMf++wA5qo69b qCi5T/dA0osN6SgCjIHw2GaDZms3oND5RzelaJgpHalBsNdqxzuqa1igwDNjJWvJCQAt 8/iYtwaNjalc+n94sc3BW2+xvtPBvVhsziZje6oLpIKyftq6Mgceh0VnmKLq4mCd16kb kJ7QtQi2q5yqhwgya0od5Brr64Ew/gAQPDvo81rIh7nNtuqERaRNljV64dNv9prYJ3Fl vN7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z126si4695003pgb.555.2017.11.08.15.31.21; Wed, 08 Nov 2017 15:31:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753173AbdKHXaA (ORCPT + 84 others); Wed, 8 Nov 2017 18:30:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54164 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752882AbdKHX37 (ORCPT ); Wed, 8 Nov 2017 18:29:59 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 364C74E90F; Wed, 8 Nov 2017 23:29:59 +0000 (UTC) Received: from x2.localnet (ovpn-122-56.rdu2.redhat.com [10.10.122.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5DF845D9CA; Wed, 8 Nov 2017 23:29:51 +0000 (UTC) From: Steve Grubb To: linux-audit@redhat.com Cc: Paul Moore , Richard Guy Briggs , linux-kernel@vger.kernel.org, Steven Rostedt Subject: Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents Date: Wed, 08 Nov 2017 18:29:48 -0500 Message-ID: <5662600.QY0GDuKsRv@x2> Organization: Red Hat In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 08 Nov 2017 23:29:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, September 20, 2017 12:52:32 PM EST Paul Moore wrote: > 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(). Late reply...but I just noticed that this changes the format of the "name" field - which is undesirable. Please put the file system type in a field all by itself called "fstype". You can just leave it as the hex magic number prepended with 0x and user space can do the lookup from there, It might be simplest to just apply a corrective patch over top of this one so that you don't have to muck about with git branches and commit messages. -Steve > > 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. From 1581013811445819052@xxx Thu Oct 12 01:37:45 +0000 2017 X-GM-THRID: 1576519731154696149 X-Gmail-Labels: Inbox,Category Forums