From: Steve Grubb <sgrubb@redhat.com> To: Richard Guy Briggs <rgb@redhat.com> Cc: Linux-Audit Mailing List <linux-audit@redhat.com>, LKML <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Al Viro <viro@zeniv.linux.org.uk>, Eric Paris <eparis@redhat.com>, Paul Moore <pmoore@redhat.com> Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs Date: Tue, 28 Feb 2017 23:15:38 -0500 [thread overview] Message-ID: <2137861.7RBAWtfTXJ@x2> (raw) In-Reply-To: <20170301033704.GU18258@madcap2.tricolour.ca> On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote: > Sorry, I forgot to include Cc: in this cover letter for context to the 4 > alt patches. > > On 2017-02-28 22:15, Richard Guy Briggs wrote: > > The background to this is: > > https://github.com/linux-audit/audit-kernel/issues/8 > > > > In short, audit SYSCALL records for *init_module were occasionally > > accompanied by hundreds to thousands of null PATH records. > > > > I chatted with Al Viro and Eric Paris about this Friday afternoon and > > they seemed to vaguely recall this issue and didn't have any solid > > recommendations as to what was the right thing to do (other than the > > same suggestion from both that I won't print here). > > > > It was reproducible on a number of vintages of distributions with > > default kernels, but triggering on very few of the many modules loaded > > at boot time. It was reproduced with fs-nfs4 and nfsv4 modules on > > tracefs, but there are reports of it also happening with debugfs. It > > was triggering only in __audit_inode_child with a parent that was not > > found in the task context's audit names_list. > > > > I have four potential solutions listed in my order of preference and I'd > > like to get some feedback about which one would be the most acceptable. 0.5 - Notice that we are in *init_module & delete_module and inhibit generation of any record type except SYSCALL and KERN_MODULE ? There are some classification routines for -F perms=wrxa that might be used to create a new class for loading/deleting modules that sets a flag that we use to suppress some record types. > > 1 - In __audit_inode_child, return immedialy upon detecting TRACEFS and > > > > DEBUGFS (and potentially other filesystems identified, via s_magic). XFS creates them too. Who knows what else. -Steve > > 2 - In __audit_inode_child, return after not finding the parent in that > > > > task context's audit names_list. > > > > 3 - In __audit_inode_child, mark the parent and its child as "hidden" > > > > when the parent isn't found in that task context's audit names_list. > > This will still result in an "items=" count that does not match the > > number of accompanying PATH records for that SYSCALL record, which > > may upset userspace tools but would still indicate suppressed > > records. > > > > 4 - In __audit_inode_child, when the parent isn't found, store the > > > > child's dentry in the child's (new or not) audit_names structure > > (properly refcounted with dget) and store the parent's dentry in its > > newly created audit_names structure (via dget_parent), then if the > > name isn't available at PATH record generation time, use that stored > > value (with dentry_path_raw and released with dput) > > > > Is there another more elegant solution that I've missed that catches > > things before they get anywhere near audit_inode_child (called from > > tracefs' notifiers)? > > > > I'll thread onto this message tested patches for all four solutions.
WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb@redhat.com> To: Richard Guy Briggs <rgb@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, LKML <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Linux-Audit Mailing List <linux-audit@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, Ingo Molnar <mingo@redhat.com> Subject: Re: Hundreds of null PATH records for *init_module syscall audit logs Date: Tue, 28 Feb 2017 23:15:38 -0500 [thread overview] Message-ID: <2137861.7RBAWtfTXJ@x2> (raw) In-Reply-To: <20170301033704.GU18258@madcap2.tricolour.ca> On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote: > Sorry, I forgot to include Cc: in this cover letter for context to the 4 > alt patches. > > On 2017-02-28 22:15, Richard Guy Briggs wrote: > > The background to this is: > > https://github.com/linux-audit/audit-kernel/issues/8 > > > > In short, audit SYSCALL records for *init_module were occasionally > > accompanied by hundreds to thousands of null PATH records. > > > > I chatted with Al Viro and Eric Paris about this Friday afternoon and > > they seemed to vaguely recall this issue and didn't have any solid > > recommendations as to what was the right thing to do (other than the > > same suggestion from both that I won't print here). > > > > It was reproducible on a number of vintages of distributions with > > default kernels, but triggering on very few of the many modules loaded > > at boot time. It was reproduced with fs-nfs4 and nfsv4 modules on > > tracefs, but there are reports of it also happening with debugfs. It > > was triggering only in __audit_inode_child with a parent that was not > > found in the task context's audit names_list. > > > > I have four potential solutions listed in my order of preference and I'd > > like to get some feedback about which one would be the most acceptable. 0.5 - Notice that we are in *init_module & delete_module and inhibit generation of any record type except SYSCALL and KERN_MODULE ? There are some classification routines for -F perms=wrxa that might be used to create a new class for loading/deleting modules that sets a flag that we use to suppress some record types. > > 1 - In __audit_inode_child, return immedialy upon detecting TRACEFS and > > > > DEBUGFS (and potentially other filesystems identified, via s_magic). XFS creates them too. Who knows what else. -Steve > > 2 - In __audit_inode_child, return after not finding the parent in that > > > > task context's audit names_list. > > > > 3 - In __audit_inode_child, mark the parent and its child as "hidden" > > > > when the parent isn't found in that task context's audit names_list. > > This will still result in an "items=" count that does not match the > > number of accompanying PATH records for that SYSCALL record, which > > may upset userspace tools but would still indicate suppressed > > records. > > > > 4 - In __audit_inode_child, when the parent isn't found, store the > > > > child's dentry in the child's (new or not) audit_names structure > > (properly refcounted with dget) and store the parent's dentry in its > > newly created audit_names structure (via dget_parent), then if the > > name isn't available at PATH record generation time, use that stored > > value (with dentry_path_raw and released with dput) > > > > Is there another more elegant solution that I've missed that catches > > things before they get anywhere near audit_inode_child (called from > > tracefs' notifiers)? > > > > I'll thread onto this message tested patches for all four solutions.
next prev parent reply other threads:[~2017-03-01 4:15 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-01 3:15 Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs 2017-03-01 3:24 ` [PATCH ALT1] audit: ignore tracefs and debugfs on inode child Richard Guy Briggs 2017-03-01 3:26 ` [PATCH ALT3] audit: hide PATH records of anonymous parents and their children Richard Guy Briggs 2017-03-01 3:29 ` [PATCH ALT2] audit: don't create PATH records for " Richard Guy Briggs 2017-03-01 3:29 ` [PATCH ALT4] audit: show fstype:pathname for entries with anonymous parents Richard Guy Briggs 2017-03-01 3:29 ` Richard Guy Briggs 2017-03-02 12:58 ` kbuild test robot 2017-03-02 12:58 ` kbuild test robot 2017-03-01 3:37 ` Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs 2017-03-01 3:37 ` Richard Guy Briggs 2017-03-01 4:15 ` Steve Grubb [this message] 2017-03-01 4:15 ` Steve Grubb 2017-03-03 21:14 ` Richard Guy Briggs 2017-03-03 21:14 ` Richard Guy Briggs 2017-03-03 22:24 ` [PATCH ALT5] audit: ignore module syscalls on inode child Richard Guy Briggs 2017-03-04 0:22 ` Hundreds of null PATH records for *init_module syscall audit logs Paul Moore 2017-03-04 0:22 ` Paul Moore 2017-03-06 21:49 ` Richard Guy Briggs 2017-03-06 21:49 ` Richard Guy Briggs 2017-03-06 22:30 ` Jessica Yu 2017-03-07 3:46 ` Richard Guy Briggs 2017-03-09 13:25 ` Steve Grubb 2017-03-09 13:24 ` Steve Grubb 2017-03-09 13:24 ` Steve Grubb 2017-03-04 0:19 ` Paul Moore 2017-03-07 3:39 ` Richard Guy Briggs 2017-03-07 3:39 ` Richard Guy Briggs 2017-03-07 15:41 ` Steven Rostedt 2017-03-07 15:41 ` Steven Rostedt 2017-03-07 16:00 ` Richard Guy Briggs 2017-03-07 16:00 ` Richard Guy Briggs 2017-03-07 16:20 ` Steven Rostedt 2017-03-07 16:20 ` Steven Rostedt 2017-03-07 17:39 ` Richard Guy Briggs 2017-03-07 17:39 ` Richard Guy Briggs 2017-03-07 18:04 ` Steven Rostedt 2017-03-07 18:04 ` Steven Rostedt 2017-03-07 18:34 ` Richard Guy Briggs 2017-03-07 19:09 ` Steven Rostedt 2017-03-07 19:09 ` Steven Rostedt 2017-03-07 22:00 ` Richard Guy Briggs 2017-03-07 22:00 ` Richard Guy Briggs 2017-03-09 13:33 ` Steve Grubb 2017-03-09 13:33 ` Steve Grubb 2017-03-07 15:37 ` Steven Rostedt 2017-03-07 15:37 ` Steven Rostedt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2137861.7RBAWtfTXJ@x2 \ --to=sgrubb@redhat.com \ --cc=eparis@redhat.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-audit@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=pmoore@redhat.com \ --cc=rgb@redhat.com \ --cc=rostedt@goodmis.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.