Bad file access on the rise

[Steve Grubb]

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 at 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