Closed pcmoore closed 5 years ago
See issue #7 as a related issue.
@pcmoore The title of this issue mentions debugfs kernel nodule. I see no such module in several distros but is appears to be a builtin. What distro exhibits this behaviour and how did you trace it to the debugfs kernel module? I am seeing this unwanted behaviour with the modprobe command on fs-nfs4 and nfsv4 services, but they are in use and am trying to figure out a way to trigger this behaviour on demand rather than depending on a reboot.
@pcmoore I guess this also begs the larger question about the audit-testsuite being able to do reboot tests.
Push a preliminiary commit to my fork for RFC: https://github.com/rgbriggs/audit-testsuite/commit/1b00d163f0c1a1cea56acb94972b78a373e59bda
@rgbriggs This is an old bug report taken from the Red Hat Bugzilla. I believe it originally came from @stevegrubb, perhaps he has more information he could share.
@pcmoore I guess this also begs the larger question about the audit-testsuite being able to do reboot tests.
To follow up on our offline conversation - tests that doesn't easily fit within the automated audit-testsuite can be places in a _testsmanual directory in the audit-testsuite.
@pcmoore Here's an update moved to tests_manual with a readme: https://github.com/rgbriggs/audit-testsuite/commit/045c23950a533b25b402afa5cab80a804cd75f17
One more comment, let's just call it "syscall_module_path", we don't need the "spam" part at the end ;)
Anything else?
Did you see the comments I made to the patch?
To be clear, the comments were attached to https://github.com/rgbriggs/audit-testsuite/commit/045c23950a533b25b402afa5cab80a804cd75f17.
My previous comments about the rules still applies (comment added inline).
Ok, updated https://github.com/rgbriggs/audit-testsuite/commit/ab2bb3f95047371f89a0338823893f82b18e97a3 It will be of limited use on RHEL6 due to missing PROCTITLE record, but will still detect bug. A more deterministic way of expressing the date/time to ausearch would help.
@rgbriggs the test looks reasonable, want to create a audit-testuite PR?
Ugh, I just noticed that is is based on my ghak7 test, so I'll rebase it to HEAD first.
Ok, untangled from ghak7 test case... https://github.com/linux-audit/audit-testsuite/pull/42
Kernel patch posted upstream: https://www.redhat.com/archives/linux-audit/2017-April/msg00011.html https://www.redhat.com/archives/linux-audit/2017-April/msg00012.html
Userspace issue created: https://github.com/linux-audit/audit-userspace/issues/15 Userspace patch posted upstream: https://www.redhat.com/archives/linux-audit/2017-April/msg00009.html
Discussion about enabling DebugFS and TraceFS by default on production distributions. https://github.com/linux-audit/audit-documentation/wiki/TraceFS-and-DebugFS-on-production-distributions
Userspace patch v3 posted upstream: https://www.redhat.com/archives/linux-audit/2017-June/msg00071.html Update feature bitmap macro to reflect the filter name change. https://www.redhat.com/archives/linux-audit/2017-June/msg00072.html
Kernel patch ALT4 V3 posted upstream: https://www.redhat.com/archives/linux-audit/2017-August/msg00073.html
Merged patch 1/2 via 41e1f7b7776be704906742120db908b8d34e10ff
Tests brought up to date. First test patch tests first kernel patch, second test patch tests second kernel patch: https://github.com/linux-audit/audit-testsuite/pull/42
upstream in git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git next 41e1f7b audit: show fstype:pathname for entries with anonymous parents 3d7810b audit: filter PATH records keyed on filesystem magic
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, Also, put it at the end of the record and it's OK if this field appears and disappears based on file system type. In general, this field will rarely appear and we can suppress the event generation with audit rules.
The first problem is that this should be an untrusted field, so switch from audit_log_format() to audit_log_untrustedstring() would fix that.
I'm fine with creating and appending a field called fstype.
This still leaves us with a relative path that appears to be an absolute path which is arguably less correct. One way to be less misleading is to remove the leading "./" or "/" so that it isn't explicitly anchored on root or CWD and instead use another special symbol (this is essentially what the original patch does). Another suggestion was made to use the nametype field, instead of "NORMAL", make it "RELA", "NOMOUNT" or "NOMNTPT".
Posted patchset v4 to add partial pathname, filesystem type and new file types to indicate anonymous entries, also fix memleak and don't trust filename: https://lkml.org/lkml/2018/2/12/1 https://www.redhat.com/archives/linux-audit/2018-February/msg00020.html
Since one of the two parts of the solution has been accepted upstream, I'm closing this issue to indicate the filter is done and pushing the other solution (giving a name to the anonymous PATH records) into a new issue to indicate partial completion. See: https://github.com/linux-audit/audit-kernel/issues/108
I don't have permission to close issues. Please close this issue.
All we really want is the kernel module name. Reproducer is below: