On Sun, 2012-11-18 at 04:26 +0000, brian m. carlson wrote: > On Sun, Nov 18, 2012 at 01:45:04AM +0000, Debian Bug Tracking System wrote: > > On Sat, 2012-11-17 at 23:05 +0000, brian m. carlson wrote: > > > Package: src:linux > > > Version: 3.6.6-1~experimental.1 > > > Severity: normal > > > > > > As you can see in the logs below, the audit subsystem logs entirely too > > > many audit messages. Since this is built into the kernel, I cannot > > > unload the module to prevent it from logging. Since I use chrome, which > > > uses seccomp (apparently), this makes lots of useless noise in the logs, > > > preventing me from seeing important messages. Earlier versions of the > > > kernel were not so verbose; please revert whatever change made the audit > > > subsystem so chatty. > > [...] > > > > This is a bug in Chrome, please report it there. > > Last I checked, Chrome did not write to the kernel ring buffer. The > kernel does not need to log every audit failure any more than it needs > to log every time a process tries to read a file that it does not have > permission to read or every segfault that occurs or every packet > dropped.
It's rate-limited. > At the very least, there should be a file in procfs or sysfs > that allows people to turn this off if they don't want their logs filled > with useless crap. All sorts of unexpected behaviors are blocked on > operating systems; very few of them deserve an entry in the kernel log. There's a good reason Chrome has a sandbox, and a reason why you should know if it looks like something's trying to escape from it. (Though I think this is more likely to be a simple bug than a blocked attack.) Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson
signature.asc
Description: This is a digitally signed message part
