On 7 June 2013 23:33, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen wrote:
> On 7 June 2013 12:29, Matthew Garrett <mjg59@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. 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.


I believe we are discussing past each other. I don't mean to say that filtering audit records is not a reasonable thing to do. It is however usually a site (the hospital, the business, the military base etc) specific decision versus one that the OS or program can determine before hand. In this case audit has a mechanism to conform with that site specific decision by being able to filter it out. But it has to be manually added because it has to be the decision of the local organization whether or not they consider X to be significant or not. 

The process at the site for determining whether or not a program is doing the right thing or not is usually outside of the skill set of the people at the site. So they will have to open a ticket with some company, that company will have to audit the code, determine whether the accesses can be filtered safely or not and then either tell the person to put in an audit skip message or put in a patch to make the program not do something as "loudly" as it was before. In most of the cases it is where a program is trying to open every file in a directory versus having any sort of filtering (which pulseaudio does have already) or by sticking stuff down a tree that is owned by the userid so that the number of files is shortened (which int he case of /tmp files is usually done) or some other step. 

In the end this sort of work is a lot more expensive than if someone goes through various audit items early on and says "hey this is triggering a lot more than it used to, can we fix it..." which is sort of what happened here before various ancient feuds and personalities took over the conversations.



--
Stephen J Smoogen.