On Saturday, June 08, 2013 06:33:11 AM Matthew Garrett wrote:
On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen
wrote:
> On 7 June 2013 12:29, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > So why not add a mechanism to permit applications to indicate that
> > certain accesses they make should be ignored by audit?
>
> Just so people know, this is like one of the the oldest auditing argument
> in the world. I have had programmers say that since the 1990's. [The
> standard counter story is that user program X says "don't audit anything I
> do in /etc." The programmer counters with adding in a black list of
> directories that can't be audited, this gets countered by something else
> and eventually you have a process where programs that have a GPG signature
> that has been accepted as valid by the audit program can say which of the
> white listed files it wants opened without audit are dealt with... and
> then
> some other programmer comes in and shows the 20,000 lines of need to be
> audited code replaces 40 lines of C code in the programs that were causing
> the problem.]
Well,
http://www.stigviewer.com/check/V-29067 implies that filtering of
audit records is a reasonable thing to do.
What this requirement is talking about is that we must provide something like
ausearch. OK, we do that. What I am telling you is that the OS has changed in
a bad way in the last year or two. It has _never_ been this noisy for
auditing. Look at this:
# aureport --start this-week --key --summary
Key Summary Report
===========================
total key
===========================
73520 access
562 module-load
149 module-unload
135 bypass
132 system-locale
132 container-config
113 time-change
110 identity
100 data-injection
88 container-create
88 export
58 register-injection
44 code-injection
29 power-abuse
22 modules-del
22 modules-add
22 MAC-policy
The bad access events dominate the event log.
I have no expectation that arbitrary user applications should be able
to do
whatever they want without leaving an audit trail, but I don't see what that
has to do with system applications. Root has the ability to modify the
selinux policy, so root (and packages installed by root) should have the
ability to modify the set of behaviours that trigger audit records.
Its not quite like this. What I need is the OS to be well behaved under normal
conditions so that when problems come along they are easily spotted. Fedora
has been a fairly well behaved OS over the years. I have had to get a few apps
fixed in the past and the maintainers have always been accommodating. But this
time I am finding we have a serious problem worse than in the past.
Thanks,
-Steve