I'm sure this suggestion will annoy people. Please disable CONFIG_AUDITSYSCALL. The feature is of dubious utility. The code quality is not so good. And merely enabling it adds considerable overhead to every single system call. I would argue that a general-purpose system should *not* have this feature enabled unless and until someone fixes it to be truly low-overhead and to be less scary.
Andy, your claims are pretty vauge. Do you have numbers? Eric, Richard, want to weigh in here?
Discussion: https://www.redhat.com/archives/linux-audit/2014-May/msg00101.html
Potential solution: https://www.redhat.com/archives/linux-audit/2014-May/msg00098.html
We grabbed that patch this morning via a CVE bug. I'm more curious on the take about it being horrible and something that should be disabled than the specific bug instance here.
I put the description back. CVE-2014-3917 has its own bug. On my laptop, syscall(SYS_getpid) takes 241.65 ns if syscall auditing is on (even with no rules) and and 70-ish ns if syscall auditing is off. On my desktop, getpid takes ~65.5 ns on a default Fedora configuration (I think -- this system has been through a few upgrades), but if I do auditctl -a task,never (which is a hack that Oleg Nesterov rigged up fairly recently), getpid goes down to 40.37 ns. Given the general scariness of the audit code and that, as far as I can tell, most of the value of auditing is the normal audit path as opposed to syscall auditing, I'd advocate for turning this thing off by default. I suppose that changing the default rules to the equivalent of '-a task,never' might have a similar effect, but I don't know the impact on normal auditing will be. FWIW, Eric Paris seems to have just added a patch to his tree to prevent CONFIG_AUDITSYSCALL from being configured in if x32 is enabled. This isn't an issue right now for Fedora (x32 is off), but it might be in the future. The test code I'm using is here: https://gitorious.org/linux-test-utils/linux-clock-tests/source/master: I'm running ./timing_test_64 10 getpid
Wasn't there a thread on the devel list about this a couple of months ago? I seem to recall this is enabled because SELinux wants to see the syscall info in AVCs. I also recall that if you don't have auditd installed, then it shouldn't have any impact at all? The gettid numbers are interesting, but we're talking a difference of a rounded worst case 200 ns. Is that even noticable in real world workloads, or would it be swallowed by noise elsewhere? (Sure, every tick counts in terms of performance, but if you're really worried at that level you aren't running Fedora kernel builds...) x32 is not a concern for Fedora. I very much doubt we'll ever enable support for it.
There was. I tried briefly and failed to come up with an example where the AVC denial message is unhelpful and the syscall audit record helps. Maybe other people know of real examples. I suspect that 200 extra ns per syscall is rather bad for some network-heavy workloads. auditd is installed by default, so I think that saying there's no impact if it's not there is a bit silly. I can ask the audit people to change the default rules to -a task,never -- maybe they'll go for that.
On brief inspection, it looks like the added attack surface from CONFIG_AUDITSYSCALL=y is rather low if there's a '-a task,never' rule. I'll close this in favor of bug 1102868. Feel free to reopen if anyone disagrees.
Saying there's no impact isn't silly. The proper thing to do would be to bring this overhead to FESCo and get them to evaluate how important auditd is and whether it needs to be installed by default. Doing an end-around that by asking this to be disabled in the kernel isn't very transparent, which makes me doubly hesitant to just turn it off. You can try the -a task,never route too I guess, but if you really are concerned then discussing it with FESCo would be the best option.
Fair enough. I do think that having auditd installed by default makes sense -- setroubleshootd needs it. I think that setroubleshootd works just fine without syscall auditing, though. In general, I don't really know when the right time to ask package maintainers things vs asking FESCo is.
Simple rule of thumb: if a change impacts multiple packages, or the default installation, it's probably at least a good idea to run it past FESCo. Worst case, you'll be told it's not a big deal and to work with the package maintainers.