Bad file access on the rise

Matthew Garrett mjg59 at srcf.ucam.org
Sat Jun 8 05:33:11 UTC 2013


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.

> The problem is that the issue is a social one and not a technical one which
> is why i think there is so much hostility towards auditing. You can't fix
> it with a technical fix, you have to fix it via social methods and a lot of
> time. In this case, the general rule is "Audit all failed accesses."
> Programs and methods which allow for automatic getting around that get
> rejected by higher ups ( I have seen several teams fight that mountain over
> the years).

POSIX doesn't provide a way for you to guarantee that you can open a 
file other than actually attempting to open that file. That's not a 
social problem. That's a technical limitation of the OS that we develop. 
If our existing audit system can't cope with that then that's a problem.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the devel mailing list