Fact checking
Fact checking
Posted May 30, 2014 6:50 UTC (Fri) by bnorris (subscriber, #92090)Parent article: Who audits the audit code?
$ grep CONFIG_AUDIT /boot/config-`uname -r`
CONFIG_AUDIT_ARCH=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
> (look for a running kauditd thread)
None here.
> even though few of them are using it. These systems take a performance penalty just for having audit enabled, and they are vulnerable to any issues that may be found in the audit code.
I'm not an expert on the kaudit subsystem (in fact, I just learned of it), but it looks like kauditd is only spawned in response to a user-space request for it (e.g. from SELinux auditd). See kernel/audit.c:
static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
{
[...]
/* As soon as there's any sign of userspace auditd,
* start kauditd to talk to it */
if (!kauditd_task) {
kauditd_task = kthread_run(kauditd_thread, NULL, "kauditd");
[...]
}
So it looks like my Ubuntu system doesn't have any overhead from kauditd; just the overhead of listening (likely low?).
Now, I don't know what other kinds of overhead CONFIG_AUDIT* might have besides kauditd, but I am at least doubtful of these claims now.
Posted May 30, 2014 13:03 UTC (Fri)
by alonz (subscriber, #815)
[Link] (1 responses)
Posted May 30, 2014 18:07 UTC (Fri)
by bnorris (subscriber, #92090)
[Link]
Posted May 30, 2014 17:16 UTC (Fri)
by luto (guest, #39314)
[Link] (7 responses)
To be clear: I don't really object to CONFIG_AUDIT -- it's just CONFIG_AUDITSYSCALL. Once audit has been enabled, you're stuck with syscall auditing overhead until the next reboot. There's a workaround:
# auditctl -a task,never
I'm currently lobbying for Fedora to turn off syscall auditing in their default configuration:
Posted Jun 1, 2014 5:13 UTC (Sun)
by dirtyepic (guest, #30178)
[Link] (6 responses)
Posted Jun 1, 2014 5:21 UTC (Sun)
by luto (guest, #39314)
[Link]
I have no clue what loginuid and sessionid (which appears to be completely unrelated to the POSIX session id) have to do with syscall auditing. It would be easy to split that out from CONFIG_AUDITSYSCALL, since it seems to be almost completely unrelated to syscall auditing, other than the fact that syscall auditing logs the loginuid and sessionid.
Posted Jun 3, 2014 19:48 UTC (Tue)
by zdzichu (guest, #17118)
[Link] (4 responses)
Posted Jun 4, 2014 4:24 UTC (Wed)
by dirtyepic (guest, #30178)
[Link] (3 responses)
Posted Jun 14, 2014 9:19 UTC (Sat)
by Duncan (guest, #6647)
[Link] (2 responses)
But no sign of kauditd. I might just try disabling CONFIG_AUDIT or at least CONFIG_AUDITSYSCALL next time I do a kernel build and see if systemd can run properly with it disabled. I've wondered why I actually needed it ever since I first enabled it. At least that way if I have to actually reenable it, I'll know exactly what I was unbreaking by doing so.
Posted Jun 14, 2014 13:56 UTC (Sat)
by Duncan (guest, #6647)
[Link] (1 responses)
Still don't know what systemd "requires" it for, but it's off now and doesn't seem to hurt me, so... I'm leaving it off.
Posted Jun 16, 2014 11:13 UTC (Mon)
by cortana (subscriber, #24596)
[Link]
According to the posting by Andy, the effect of CONFIG_AUDITSYSCALLS is
Fact checking
It forces all syscalls into the slow path and it can do crazy things
like building audit contexts just in case actual handling of the
syscall triggers an audit condition so that the exit path can log the
syscall. That's way worse than a single branch.
Try it: benchmark getpid on Fedora and then repeat the experiment with
syscall auditing fully disabled. The difference is striking.
Fact checking
Fact checking
Fact checking
Fact checking
Fact checking
Fact checking
Fact checking
Fact checking
Fact checking