On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen wrote: > On 7 June 2013 12:29, Matthew Garrett <mjg59@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
