Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1589967 > unrolled thread

Hundreds of null PATH records for *init_module syscall audit logs

Back to article view | Back to linux.kernel

Contents

  Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-01 04:30 +0100
    [PATCH ALT2] audit: don't create PATH records for anonymous parents and their children Richard Guy Briggs <rgb@redhat.com> - 2017-03-01 04:30 +0100
    Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-01 04:50 +0100
      Re: Hundreds of null PATH records for *init_module syscall audit logs Steve Grubb <sgrubb@redhat.com> - 2017-03-01 05:20 +0100
        Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-03 22:30 +0100
          [PATCH ALT5] audit: ignore module syscalls on inode child Richard Guy Briggs <rgb@redhat.com> - 2017-03-03 23:30 +0100
          Re: Hundreds of null PATH records for *init_module syscall audit logs Paul Moore <paul@paul-moore.com> - 2017-03-04 01:30 +0100
            Re: Hundreds of null PATH records for *init_module syscall audit logs Jessica Yu <jeyu@redhat.com> - 2017-03-06 23:40 +0100
              Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-07 04:50 +0100
            Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-07 03:10 +0100
              Re: Hundreds of null PATH records for *init_module syscall audit logs Steve Grubb <sgrubb@redhat.com> - 2017-03-09 14:30 +0100
          Re: Hundreds of null PATH records for *init_module syscall audit logs Steve Grubb <sgrubb@redhat.com> - 2017-03-09 14:30 +0100
      Re: Hundreds of null PATH records for *init_module syscall audit logs Paul Moore <paul@paul-moore.com> - 2017-03-04 01:30 +0100
        Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-07 05:00 +0100
          Re: Hundreds of null PATH records for *init_module syscall audit  logs Steven Rostedt <rostedt@goodmis.org> - 2017-03-07 17:00 +0100
            Re: Hundreds of null PATH records for *init_module syscall audit  logs Steven Rostedt <rostedt@goodmis.org> - 2017-03-07 17:30 +0100
              Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-07 18:50 +0100
                Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-07 19:40 +0100
                  Re: Hundreds of null PATH records for *init_module syscall audit  logs Steven Rostedt <rostedt@goodmis.org> - 2017-03-07 20:20 +0100
                    Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-07 23:30 +0100
                Re: Hundreds of null PATH records for *init_module syscall audit  logs Steven Rostedt <rostedt@goodmis.org> - 2017-03-07 21:50 +0100
            Re: Hundreds of null PATH records for *init_module syscall audit logs Richard Guy Briggs <rgb@redhat.com> - 2017-03-07 17:30 +0100
              Re: Hundreds of null PATH records for *init_module syscall audit logs Steve Grubb <sgrubb@redhat.com> - 2017-03-09 14:40 +0100
        Re: Hundreds of null PATH records for *init_module syscall audit  logs Steven Rostedt <rostedt@goodmis.org> - 2017-03-07 16:40 +0100
    [PATCH ALT4] audit: show fstype:pathname for entries with anonymous parents Richard Guy Briggs <rgb@redhat.com> - 2017-03-01 08:50 +0100
      Re: [PATCH ALT4] audit: show fstype:pathname for entries with  anonymous parents kbuild test robot <lkp@intel.com> - 2017-03-02 14:10 +0100

Page 1 of 2  [1] 2  Next page →

#1589967 — Hundreds of null PATH records for *init_module syscall audit logs

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.

1 - In __audit_inode_child, return immedialy upon detecting TRACEFS and
    DEBUGFS (and potentially other filesystems identified, via s_magic).

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.


- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [next] | [standalone]

#1589968 — [PATCH ALT2] audit: don't create PATH records for anonymous parents and their children

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

Don't create those records when the parent is not found in
that task context's audit names_list.

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 <rgb@redhat.com>
---
 kernel/auditsc.c |   20 +++++++-------------
 1 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 4db32e8..83eb3bc 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1889,6 +1889,10 @@ void __audit_inode_child(struct inode *parent,
 		}
 	}
 
+	if (!found_parent)
+		/* Don't track if parent is "anonymous" */
+		return;
+
 	/* is there a matching child entry? */
 	list_for_each_entry(n, &context->names_list, list) {
 		/* can only match entries that have a name */
@@ -1908,14 +1912,6 @@ void __audit_inode_child(struct inode *parent,
 		}
 	}
 
-	if (!found_parent) {
-		/* create a new, "anonymous" parent record */
-		n = audit_alloc_name(context, AUDIT_TYPE_PARENT);
-		if (!n)
-			return;
-		audit_copy_inode(n, NULL, parent);
-	}
-
 	if (!found_child) {
 		found_child = audit_alloc_name(context, type);
 		if (!found_child)
@@ -1924,11 +1920,9 @@ void __audit_inode_child(struct inode *parent,
 		/* Re-use the name belonging to the slot for a matching parent
 		 * directory. All names for this context are relinquished in
 		 * audit_free_names() */
-		if (found_parent) {
-			found_child->name = found_parent->name;
-			found_child->name_len = AUDIT_NAME_FULL;
-			found_child->name->refcnt++;
-		}
+		found_child->name = found_parent->name;
+		found_child->name_len = AUDIT_NAME_FULL;
+		found_child->name->refcnt++;
 	}
 
 	if (inode)
-- 
1.7.1

[toc] | [prev] | [next] | [standalone]

#1589970

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.
> 
> 1 - In __audit_inode_child, return immedialy upon detecting TRACEFS and
>     DEBUGFS (and potentially other filesystems identified, via s_magic).
> 
> 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.
> 
> 
> - RGB
> 
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

#1589973

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.

[toc] | [prev] | [next] | [standalone]

#1592280

On 2017-02-28 23:15, Steve Grubb wrote:
> 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.

Ok, I was partially able to do this.

If I try and catch it in audit_log_start() which is the common point for
all the record types to be able to limit to just SYSCALL and
KERN_MODULE, there will already be a linked list of hundreds to
thousands of audit_names and will still print a non-zero items count in
the SYSCALL record.  This also sounds like a potentially lazy way to
deal with other record spam (like setuid BRPM_FCAPS).

If I catch it in __audit_inode_child in the same place as I caught the
filesystem type, it is effective for only the PATH record, which is all
that is a problem at the moment.

It touches nine arch-related files, which is a lot more disruptive than
I was hoping.

> > > 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.

Why would this happen?  I would assume it is a mounted filesystem.  Do
you have a sample of the extra records?

This brings me back to the original reaction I had to your suggestion
which is: Are you certain there is never a circumstance where *_module
syscalls never involve a file?  Say, the module itself on loading pulls
in other files from the mounted filesystem?

> -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.

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

#1592317 — [PATCH ALT5] audit: ignore module syscalls on inode child

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

In __audit_inode_child, return immedialy upon detecting module-related
syscalls.

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 <rgb@redhat.com>
---
 kernel/auditsc.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 4db32e8..d7fe943 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1868,6 +1868,12 @@ void __audit_inode_child(struct inode *parent,
 
 	if (!context->in_syscall)
 		return;
+	switch (context->major) {
+	case __NR_init_module:
+	case __NR_delete_module:
+	case __NR_finit_module:
+		return;
+	}
 
 	if (inode)
 		handle_one(inode);
-- 
1.7.1

[toc] | [prev] | [next] | [standalone]

#1592360

On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-02-28 23:15, Steve Grubb wrote:
>> 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.
>
> Ok, I was partially able to do this.
>
> If I try and catch it in audit_log_start() which is the common point for
> all the record types to be able to limit to just SYSCALL and
> KERN_MODULE, there will already be a linked list of hundreds to
> thousands of audit_names and will still print a non-zero items count in
> the SYSCALL record.  This also sounds like a potentially lazy way to
> deal with other record spam (like setuid BRPM_FCAPS).
>
> If I catch it in __audit_inode_child in the same place as I caught the
> filesystem type, it is effective for only the PATH record, which is all
> that is a problem at the moment.
>
> It touches nine arch-related files, which is a lot more disruptive than
> I was hoping.

Blocking PATH record on creation based on syscall *really* seems like
a bad/dangerous idea.  If we want to block all these tracefs/debugfs
records, let's just block the fs.  Although as of right now I'm not a
fan of blocking anything.

-- 
paul moore
www.paul-moore.com

[toc] | [prev] | [next] | [standalone]

#1593785

+++ Richard Guy Briggs [06/03/17 16:49 -0500]:
>On 2017-03-03 19:22, Paul Moore wrote:
>> On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > On 2017-02-28 23:15, Steve Grubb wrote:
>> >> 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.
>> >
>> > Ok, I was partially able to do this.
>> >
>> > If I try and catch it in audit_log_start() which is the common point for
>> > all the record types to be able to limit to just SYSCALL and
>> > KERN_MODULE, there will already be a linked list of hundreds to
>> > thousands of audit_names and will still print a non-zero items count in
>> > the SYSCALL record.  This also sounds like a potentially lazy way to
>> > deal with other record spam (like setuid BRPM_FCAPS).
>> >
>> > If I catch it in __audit_inode_child in the same place as I caught the
>> > filesystem type, it is effective for only the PATH record, which is all
>> > that is a problem at the moment.
>> >
>> > It touches nine arch-related files, which is a lot more disruptive than
>> > I was hoping.
>>
>> Blocking PATH record on creation based on syscall *really* seems like
>> a bad/dangerous idea.  If we want to block all these tracefs/debugfs
>> records, let's just block the fs.  Although as of right now I'm not a
>> fan of blocking anything.
>
>I agree.  What makes me leery of this approach is if a kernel module in
>turn accesses directly other files, or bypasses the load_module call to
>load another module from a file and avoids logging.

AFAIK load_module is *the* entry point for module loading, it is where
all the setup occurs in order for a module to be properly set up and
registered in our internal data structures (e.g the global modules
list). If a module wants another module loaded, it can request for it
to be loaded via request_module(), which punts the request to modprobe
in userspace to load the module in question, but I'm not sure if
that's at all related to this null PATH record issue.

Jessica

[toc] | [prev] | [next] | [standalone]

#1593890

On 2017-03-06 17:30, Jessica Yu wrote:
> +++ Richard Guy Briggs [06/03/17 16:49 -0500]:
> >On 2017-03-03 19:22, Paul Moore wrote:
> >>On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >>> On 2017-02-28 23:15, Steve Grubb wrote:
> >>>> 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.
> >>>
> >>> Ok, I was partially able to do this.
> >>>
> >>> If I try and catch it in audit_log_start() which is the common point for
> >>> all the record types to be able to limit to just SYSCALL and
> >>> KERN_MODULE, there will already be a linked list of hundreds to
> >>> thousands of audit_names and will still print a non-zero items count in
> >>> the SYSCALL record.  This also sounds like a potentially lazy way to
> >>> deal with other record spam (like setuid BRPM_FCAPS).
> >>>
> >>> If I catch it in __audit_inode_child in the same place as I caught the
> >>> filesystem type, it is effective for only the PATH record, which is all
> >>> that is a problem at the moment.
> >>>
> >>> It touches nine arch-related files, which is a lot more disruptive than
> >>> I was hoping.
> >>
> >>Blocking PATH record on creation based on syscall *really* seems like
> >>a bad/dangerous idea.  If we want to block all these tracefs/debugfs
> >>records, let's just block the fs.  Although as of right now I'm not a
> >>fan of blocking anything.
> >
> >I agree.  What makes me leery of this approach is if a kernel module in
> >turn accesses directly other files, or bypasses the load_module call to
> >load another module from a file and avoids logging.
> 
> AFAIK load_module is *the* entry point for module loading, it is where
> all the setup occurs in order for a module to be properly set up and
> registered in our internal data structures (e.g the global modules
> list). If a module wants another module loaded, it can request for it
> to be loaded via request_module(), which punts the request to modprobe
> in userspace to load the module in question, but I'm not sure if
> that's at all related to this null PATH record issue.

Yes, there is a lot going on in that function and by far the easiest way
to be able to load another module, but I'm being a bit paranoid in
suggesting that a rogue module may try and skip some steps listed there
and roll its own, hence the desire to not disable all PATH auxilliary
records for *_module SYSCALL records, but only the filesystem types that
don't pose a threat.

> Jessica

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

#1593856

On 2017-03-03 19:22, Paul Moore wrote:
> On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-02-28 23:15, Steve Grubb wrote:
> >> 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.
> >
> > Ok, I was partially able to do this.
> >
> > If I try and catch it in audit_log_start() which is the common point for
> > all the record types to be able to limit to just SYSCALL and
> > KERN_MODULE, there will already be a linked list of hundreds to
> > thousands of audit_names and will still print a non-zero items count in
> > the SYSCALL record.  This also sounds like a potentially lazy way to
> > deal with other record spam (like setuid BRPM_FCAPS).
> >
> > If I catch it in __audit_inode_child in the same place as I caught the
> > filesystem type, it is effective for only the PATH record, which is all
> > that is a problem at the moment.
> >
> > It touches nine arch-related files, which is a lot more disruptive than
> > I was hoping.
> 
> Blocking PATH record on creation based on syscall *really* seems like
> a bad/dangerous idea.  If we want to block all these tracefs/debugfs
> records, let's just block the fs.  Although as of right now I'm not a
> fan of blocking anything.

I agree.  What makes me leery of this approach is if a kernel module in
turn accesses directly other files, or bypasses the load_module call to
load another module from a file and avoids logging.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

#1596061

On Monday, March 6, 2017 4:49:21 PM EST Richard Guy Briggs wrote:
> > Blocking PATH record on creation based on syscall *really* seems like
> > a bad/dangerous idea.  If we want to block all these tracefs/debugfs
> > records, let's just block the fs.  Although as of right now I'm not a
> > fan of blocking anything.
> 
> I agree.  What makes me leery of this approach is if a kernel module in
> turn accesses directly other files, or bypasses the load_module call to
> load another module from a file and avoids logging.

In this case, we want a second event with that module name. We do not want any 
PATH records.

-Steve

[toc] | [prev] | [next] | [standalone]

#1596066

On Friday, March 3, 2017 4:14:54 PM EST Richard Guy Briggs wrote:
> > > > 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.
> 
> Why would this happen?  I would assume it is a mounted filesystem.  Do
> you have a sample of the extra records?

I can't find them right away. But I've seen them.

> This brings me back to the original reaction I had to your suggestion
> which is: Are you certain there is never a circumstance where *_module
> syscalls never involve a file?  Say, the module itself on loading pulls
> in other files from the mounted filesystem?

We don't care about this. Audit events have to tell a story. They must have a 
subject, action, and object. In this case its "somebody loaded a kernel module 
X". Where X is the module name. Paths are irrelevant to the story and just 
make it hard to understand the event.

-Steve

[toc] | [prev] | [next] | [standalone]

#1592358

On Tue, Feb 28, 2017 at 10:37 PM, Richard Guy Briggs <rgb@redhat.com> 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'm no expert on the tracing system, but my understanding is that it
used to use debugfs but now prefers tracefs so perhaps depending on
the vintage of the kernel/userspace you will see it on either debugfs
or tracefs.  I'm also guessing that module load order may have an
effect, maybe not.

>> 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.

From an audit perspective, I'm generally not a fan of throwing away
information, especially since solution #4 seems to provide some basic
PATH information.  Although I guess the issue is do we care about
tracefs/debugfs PATH records?

>> 1 - In __audit_inode_child, return immedialy upon detecting TRACEFS and
>>     DEBUGFS (and potentially other filesystems identified, via s_magic).

If we decide we want to ignore debugfs/tracefs this may be the best solution.

>> 2 - In __audit_inode_child, return after not finding the parent in that
>>     task context's audit names_list.

This doesn't seem like the right answer.

>> 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.

Similar to door #2, this doesn't seem right to me.

>> 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)

This seems most in keeping with the spirit of audit.

>> 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.
>>
>> - RGB
>>
>> --
>> Richard Guy Briggs <rgb@redhat.com>
>> Kernel Security Engineering, Base Operating Systems, Red Hat
>> Remote, Ottawa, Canada
>> Voice: +1.647.777.2635, Internal: (81) 32635

-- 
paul moore
www.paul-moore.com

[toc] | [prev] | [next] | [standalone]

#1593897

On 2017-03-03 19:19, Paul Moore wrote:
> On Tue, Feb 28, 2017 at 10:37 PM, Richard Guy Briggs <rgb@redhat.com> 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'm no expert on the tracing system, but my understanding is that it
> used to use debugfs but now prefers tracefs so perhaps depending on
> the vintage of the kernel/userspace you will see it on either debugfs
> or tracefs.  I'm also guessing that module load order may have an
> effect, maybe not.

I'm at the same level of understanding.

> >> 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.
> 
> From an audit perspective, I'm generally not a fan of throwing away
> information, especially since solution #4 seems to provide some basic
> PATH information.  Although I guess the issue is do we care about
> tracefs/debugfs PATH records?

From the output I've seen, it doesn't look particularly useful, but it
was useful to finally see the source of those huge numbers of PATH
records.  Here's an fpaste:
	https://paste.fedoraproject.org/paste/UpZoYuokojR0es1ayNdx5l5M1UNdIGYhyRLivL9gydE=/

> >> 1 - In __audit_inode_child, return immedialy upon detecting TRACEFS and
> >>     DEBUGFS (and potentially other filesystems identified, via s_magic).
> 
> If we decide we want to ignore debugfs/tracefs this may be the best solution.

Glad we agree there.

> >> 2 - In __audit_inode_child, return after not finding the parent in that
> >>     task context's audit names_list.
> 
> This doesn't seem like the right answer.

I have another patch that tried to reuse existing entries even if no
struct filename was supplied to __audit_inode, but it didn't seem to
make a difference.  Everything that was working continued to do so and
everything that was broken remained so.

> >> 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.
> 
> Similar to door #2, this doesn't seem right to me.

I did think of supplementing that information with a general
characterization that all the items came from a filesystem that was of
no concern so that there was evidence of what was happenning but that it
wouldn't overwhelm the logs.

> >> 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)
> 
> This seems most in keeping with the spirit of audit.

Agreed, but looks like too much useless information.

> >> 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.
> >>
> >> - RGB
> 
> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

#1594377 — Re: Hundreds of null PATH records for *init_module syscall audit logs

On Mon, 6 Mar 2017 22:39:54 -0500
Richard Guy Briggs <rgb@redhat.com> wrote:

> >From the output I've seen, it doesn't look particularly useful, but it  
> was useful to finally see the source of those huge numbers of PATH
> records.  Here's an fpaste:
> 	https://paste.fedoraproject.org/paste/UpZoYuokojR0es1ayNdx5l5M1UNdIGYhyRLivL9gydE=/

Those are the files for the module's trace events that are created.

I'm still confused about what the issue is.

-- Steve

[toc] | [prev] | [next] | [standalone]

#1594401 — Re: Hundreds of null PATH records for *init_module syscall audit logs

On Tue, 7 Mar 2017 11:00:27 -0500
Richard Guy Briggs <rgb@redhat.com> wrote:

> On 2017-03-07 10:41, Steven Rostedt wrote:
> > On Mon, 6 Mar 2017 22:39:54 -0500
> > Richard Guy Briggs <rgb@redhat.com> wrote:
> >   
> > > >From the output I've seen, it doesn't look particularly useful, but it    
> > > was useful to finally see the source of those huge numbers of PATH
> > > records.  Here's an fpaste:
> > > 	https://paste.fedoraproject.org/paste/UpZoYuokojR0es1ayNdx5l5M1UNdIGYhyRLivL9gydE=/  
> > 
> > Those are the files for the module's trace events that are created.
> > 
> > I'm still confused about what the issue is.  
> 
> The issue is the audit subsystem being overwhelmed by potentially
> useless information.
> 
> The initial report was "there's a bunch of null PATH records, please
> make them go away", which was anywhere from 500 to 6000 records.

I don't know the audit system and exactly what it is looking for. How
does it deal with other virtual filesystems like procfs? Why is tracefs
different?

-- Steve

[toc] | [prev] | [next] | [standalone]

#1594460

On 2017-03-07 11:20, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 11:00:27 -0500
> Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> > On 2017-03-07 10:41, Steven Rostedt wrote:
> > > On Mon, 6 Mar 2017 22:39:54 -0500
> > > Richard Guy Briggs <rgb@redhat.com> wrote:
> > >   
> > > > >From the output I've seen, it doesn't look particularly useful, but it    
> > > > was useful to finally see the source of those huge numbers of PATH
> > > > records.  Here's an fpaste:
> > > > 	https://paste.fedoraproject.org/paste/UpZoYuokojR0es1ayNdx5l5M1UNdIGYhyRLivL9gydE=/  
> > > 
> > > Those are the files for the module's trace events that are created.
> > > 
> > > I'm still confused about what the issue is.  
> > 
> > The issue is the audit subsystem being overwhelmed by potentially
> > useless information.
> > 
> > The initial report was "there's a bunch of null PATH records, please
> > make them go away", which was anywhere from 500 to 6000 records.
> 
> I don't know the audit system and exactly what it is looking for. How
> does it deal with other virtual filesystems like procfs? Why is tracefs
> different?

The audit subsystem is looking, via sysadmin-crafted rules to notice
situations of interest, for details that could affect the integrity of
the system

This situation is specifically for syscall auditing.  Various syscalls
have expected numbers of accompanying PATH records, for example open(2)
would have directory and file PATH records, while rename(2) would have 2
directory and 2 file PATH records.  An open call on a file in /proc
could trigger a rule that was formulated to catch that type of activity
that lists its directory and its file PATH records, which would be fine.

We normally don't expect the init_module syscall to have any PATH
records associated with it, so when a few of them had hundreds or more
this was surprising.

If there is a way that debugfs or tracefs could be abused during an
init_module call (or any other syscall for that matter), we want to be
aware of it.  This is why simply ignoring those PATH records is making
two of us nervous.

> -- Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

#1594507

On 2017-03-07 13:04, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 12:39:55 -0500
> Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> > We normally don't expect the init_module syscall to have any PATH
> > records associated with it, so when a few of them had hundreds or more
> > this was surprising.
> 
> Hmm, how does the syscall get a path associated to it? Just by its
> creation? That is, by calling init_module() which would load a module,
> would indeed create a path. Some modules do create their own debugfs
> files, which would explain why debugfs is shown too.

My understanding is that a module binary blob is already acquired from
some source and then handed to the init_module (or finit_module) syscall
to add to the running kernel.  Some add functionality in /proc or /sys,
but these would not be exercised until they are called by name from
another syscall (such as open).

Syscall auditing is interested in the resources/details of *one* syscall
event at a time (from audit_syscall_entry to audit_syscall_exit),
logging the subject attributes of a process (who) doing what (which
syscall) to what (frequently a file).  Depending on the syscall, there
could be any number of auxilliary records to that event that help fill
in the whole picture that interests us.

So which file are you talking about that "would indeed create a path"?

> > If there is a way that debugfs or tracefs could be abused during an
> > init_module call (or any other syscall for that matter), we want to be
> > aware of it.  This is why simply ignoring those PATH records is making
> > two of us nervous.
> 
> If there's a bug in the kernel code, then I'm sure there's probably a
> way to abuse it.
> 
> I also don't believe it should be ignored, which is why I'm asking
> these questions. I want to know what exactly is being looked at, and
> what is considered "OK" and what isn't.

That one is harder to answer and depends on the syscall and its
potential to influence system behaviour, or to exfiltrate information.

> Now loading modules can indeed create files and directories. Is this
> something that the audit system needs to understand?

Does it create them immediately in that syscall?  Or does it make that
path available for other operations later?

> -- Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

#1594554 — Re: Hundreds of null PATH records for *init_module syscall audit logs

On Tue, 7 Mar 2017 13:34:47 -0500
Richard Guy Briggs <rgb@redhat.com> wrote:

> On 2017-03-07 13:04, Steven Rostedt wrote:
> > On Tue, 7 Mar 2017 12:39:55 -0500
> > Richard Guy Briggs <rgb@redhat.com> wrote:
> >   
> > > We normally don't expect the init_module syscall to have any PATH
> > > records associated with it, so when a few of them had hundreds or more
> > > this was surprising.  
> > 
> > Hmm, how does the syscall get a path associated to it? Just by its
> > creation? That is, by calling init_module() which would load a module,
> > would indeed create a path. Some modules do create their own debugfs
> > files, which would explain why debugfs is shown too.  
> 
> My understanding is that a module binary blob is already acquired from
> some source and then handed to the init_module (or finit_module) syscall
> to add to the running kernel.  Some add functionality in /proc or /sys,
> but these would not be exercised until they are called by name from
> another syscall (such as open).
> 
> Syscall auditing is interested in the resources/details of *one* syscall
> event at a time (from audit_syscall_entry to audit_syscall_exit),
> logging the subject attributes of a process (who) doing what (which
> syscall) to what (frequently a file).  Depending on the syscall, there
> could be any number of auxilliary records to that event that help fill
> in the whole picture that interests us.
> 
> So which file are you talking about that "would indeed create a path"?

The files in /sys/kernel{/debug}/tracing/events/*

A module may connect "trace events" to parts of its code. When a module
gets loaded, virtual directories and files are created with respect to
the events within the module. When the module is unloaded, those files
are removed.

> 
> > > If there is a way that debugfs or tracefs could be abused during an
> > > init_module call (or any other syscall for that matter), we want to be
> > > aware of it.  This is why simply ignoring those PATH records is making
> > > two of us nervous.  
> > 
> > If there's a bug in the kernel code, then I'm sure there's probably a
> > way to abuse it.
> > 
> > I also don't believe it should be ignored, which is why I'm asking
> > these questions. I want to know what exactly is being looked at, and
> > what is considered "OK" and what isn't.  
> 
> That one is harder to answer and depends on the syscall and its
> potential to influence system behaviour, or to exfiltrate information.
> 
> > Now loading modules can indeed create files and directories. Is this
> > something that the audit system needs to understand?  
> 
> Does it create them immediately in that syscall?  Or does it make that
> path available for other operations later?

Not sure what you mean here. The files are created, but to use them,
another process needs to do an open and write to them.

The inodes and dentrys are created. But the process should not have any
file descriptors created associated with them.

-- Steve

[toc] | [prev] | [next] | [standalone]

#1594700

On 2017-03-07 14:09, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 13:34:47 -0500
> Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> > On 2017-03-07 13:04, Steven Rostedt wrote:
> > > On Tue, 7 Mar 2017 12:39:55 -0500
> > > Richard Guy Briggs <rgb@redhat.com> wrote:
> > >   
> > > > We normally don't expect the init_module syscall to have any PATH
> > > > records associated with it, so when a few of them had hundreds or more
> > > > this was surprising.  
> > > 
> > > Hmm, how does the syscall get a path associated to it? Just by its
> > > creation? That is, by calling init_module() which would load a module,
> > > would indeed create a path. Some modules do create their own debugfs
> > > files, which would explain why debugfs is shown too.  
> > 
> > My understanding is that a module binary blob is already acquired from
> > some source and then handed to the init_module (or finit_module) syscall
> > to add to the running kernel.  Some add functionality in /proc or /sys,
> > but these would not be exercised until they are called by name from
> > another syscall (such as open).
> > 
> > Syscall auditing is interested in the resources/details of *one* syscall
> > event at a time (from audit_syscall_entry to audit_syscall_exit),
> > logging the subject attributes of a process (who) doing what (which
> > syscall) to what (frequently a file).  Depending on the syscall, there
> > could be any number of auxilliary records to that event that help fill
> > in the whole picture that interests us.
> > 
> > So which file are you talking about that "would indeed create a path"?
> 
> The files in /sys/kernel{/debug}/tracing/events/*

These appear to be the null PATHs I'm looking for.

So these appear to be the PATH records that are being seen, mounted on
/sys/kernel{/debug}/tracing/, but showing up as anonymous because the
path to the mount point is unknown or unavailable in the audit_names
list at the time of the syscall.

Could that tracefs instance have been populated but not yet mounted at
the time the module was loaded on boot? (fs-nfs4, nfsv4)

> A module may connect "trace events" to parts of its code. When a module
> gets loaded, virtual directories and files are created with respect to
> the events within the module. When the module is unloaded, those files
> are removed.

Can the availability of debug or trace points in a module be forced off
by a user to avoid or limit the problem?

Is the availability of these trace points a build time or run time switch?

Is there any security liability to having those trace points available
in the filesystem in terms of control or information leakage?  (Sounds
like yes.)

> > > > If there is a way that debugfs or tracefs could be abused during an
> > > > init_module call (or any other syscall for that matter), we want to be
> > > > aware of it.  This is why simply ignoring those PATH records is making
> > > > two of us nervous.  
> > > 
> > > If there's a bug in the kernel code, then I'm sure there's probably a
> > > way to abuse it.
> > > 
> > > I also don't believe it should be ignored, which is why I'm asking
> > > these questions. I want to know what exactly is being looked at, and
> > > what is considered "OK" and what isn't.  
> > 
> > That one is harder to answer and depends on the syscall and its
> > potential to influence system behaviour, or to exfiltrate information.
> > 
> > > Now loading modules can indeed create files and directories. Is this
> > > something that the audit system needs to understand?  
> > 
> > Does it create them immediately in that syscall?  Or does it make that
> > path available for other operations later?
> 
> Not sure what you mean here. The files are created, but to use them,
> another process needs to do an open and write to them.

Ok, so I think I've concluded that these are the same files.

So the system is working as intended.  The next question is how do we
address the issue, perhaps by answering the three questions above.

> The inodes and dentrys are created. But the process should not have any
> file descriptors created associated with them.

It doesn't need to.  I assume a module could open a file from within the
kernel to read it or write it and then close it, all within the module's
init routine and be done by the time the syscall finishes.

> -- Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web