Date: Mon, 07 Sep 2020 20:52:06 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 249179] Several audit framework/tool issues Message-ID: <bug-249179-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249179 Bug ID: 249179 Summary: Several audit framework/tool issues Product: Base System Version: 12.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: ltning-freebsd@anduin.net We use the audit framework extensively across our fleet. The configuration is relatively simple, so it has kept working reasonably well for >10 years, but it is now falling apart at the seams. Even the briefest attempts at working with it will reveal a number of problems; I'm listing some here but providing examples is difficult while reproducing should be very simple: - all events (at least those in jails) seem to have 'naflags' as opposed to 'flags' applied, even if an audit identifier is available (user names/IDs are shown and correct in the audit log) - all execve() calls are logged as failures (return,failure: Unknown error: 201,4294967295), regardless of their actual result - auditreduce cannot select events by class (specifying -c XX returns nothing) - auditreduce cannot invert its search (-v causes all events to be shown, including those that match) See also issue 248025 - it appears as if detaching from or attaching to the audit pipe (bsmtrace) migth be causing this. My audit_control, which is the only part of the configuration that has been modified: dir:/var/audit dist:off flags:lo,aa,ad,ex minfree:5 naflags:lo,aa,ad,ex policy:cnt,argv filesz:0 host:foo.tld expire-after:90d -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-249179-227>