lkml.org 
[lkml]   [2017]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Hundreds of null PATH records for *init_module syscall audit logs
    Date
    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.

    \
     
     \ /
      Last update: 2017-03-01 05:16    [W:7.202 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site