Bad file access on the rise

[Stephen John Smoogen]

On 7 June 2013 23:33, Matthew Garrett <mjg59 at 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 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. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130608/a0f04774/attachment.html>