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/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249179 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, bu= t it is now falling apart at the seams. Even the briefest attempts at working wi= th 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 a= re 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 nothi= ng) - 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-249179-227>