lkml.org 
[lkml]   [2017]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectHundreds 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

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