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@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. 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
