Arch Linux

There's a very high performance cost for CONFIG_AUDITSYSCALL because it forces all system calls onto the slow path. It can be disabled at runtime but that requires making use of the userspace audit components.

Fedora is disabling it by default at runtime due to the performance hit:

https://fedorahosted.org/fesco/ticket/1311

The bug you linked suggests that not installing auditd solves the problem as well.

I delved a bit into the kernel code and I think that's right. In the case that neither audit=0 nor audit=1 is given, the audit subsystem remains dormant (audit_ever_enabled remains 0) and no task is syscall-audited until there's a request from userspace (auditd) to enable auditing.

Since, unlike Fedora, we do not install auditd by default, I think we're in the clear.

Hm, unfortunately journald unconditionally enables auditing (enable_audit in src/journal/journald-audit.c) even when libaudit support is not compiled into systemd.

Options as I see them:

1. Leave AUDITSYSCALL disabled.
getlogin() and other users of the loginuid/sessionid interface remain broken.
People wanting to use the audit subsystem need to build their own kernel.
Simple and uncomplicated, but if I were satisfied with the status quo, I wouldn't have opened a bug.

2. Enable syscall auditing and take the performance hit.
How expensive is it really? The referenced ticket only provides microbenchmarks.

3. Include parts of audit userspace in base and disable syscall auditing.
An "audit-minimal" package could include just auditctl and libaudit and a static service calling "auditctl -a task,never" at boot.
Enabling libaudit support in systemd could then pull this in.
Probably rightly called bloat, even though we don't need to include auditd and most of the other stuff.

4. Patch the kernel so audit=0 becomes the default.
People wanting to use the audit subsystem need to set audit=1.
A rather small and simple patch, but goes against our principles.

5. Patch journald and remove the audit logging feature.
Not a complicated patch, but goes against our principles.
What about people who actually want this feature?

6. Patch journald to disable syscall auditing at boot.
Probably a pretty daunting task fraught with unforeseen consequences and a dependency on libaudit.

7. Patch the kernel so syscall auditing can be disabled by default.
Likely a complex task and a permanent derivation from upstream.

8. Patch the kernel and disentangle loginuid/sessionid from the rest of auditing.
This would be wonderful, but who is going to do it?

> How expensive is it really? The referenced ticket only provides microbenchmarks.

It moves all system calls from the fast path to the slow path even if they don't block. The cost for niches like an event-based server where a large portion of the time is spent paying for system calls is huge.

> Patch the kernel so audit=0 becomes the default.

Upstream would probably accept a flag for changing the default, so that seems like a good option.

Perhaps something like this, then?

The fast path is gone due to meltdown fixes so performance concerns no longer apply here. As there are no other concersn it can be enabled now.

Meltdown only affected Intel processors so these concerns still apply to kernels running on AMD systems.

If the fast path in question was the SYSCALL64 one that was removed https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21d375b6b34ff511a507de27bf316b3dde6938d9

@Andreaskem: loqs is right, the code was completely removed from the kernel regardless of cpu.

I'll consider following what -hardened does and enabling AUDIT but disabling it by default (via built-in CMDLINE audit=0).

Fair enough. I guess there were enough good reasons aside from PTI to remove the fast path.

@heftig for this approach to work you will need to add one of linux-hardened patches[0] otherwise 'audit=0' isn't overridable.

[0] https://github.com/anthraxx/linux-hardened/commit/deb24e7c223793c96e167acc9aff169748742a38

The current config for 4.18.arch1-1 has
# CONFIG_CMDLINE_BOOL is not set
instead of
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="audit=0"
is that intentional?

Yeah, not sure I'll let it out of testing this way but I forgot what else was objectionable.

I think it was the journal being filled with messages when audit in userspace is not configured, anthrax would know more as linux-hardened ships with audit=0

@loqs linux-hardened shipped that before anthrax was involved and before syscall changes. In fact previous maintainer (thestinger) is the one who raised performance problem here: https://bugs.archlinux.org/task/42954#comment130796 and points to 'audit=0' solution here: https://bugs.archlinux.org/task/42954#comment132286

I think the logging issue was resolved with https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/seccomp.c?id=0ddec0fc8900201c0897b87b762b7c420436662f
@spinka so linux-hardened could remove the flag?

I booted linux 4.18 from testing without userspace audit installed and there are only about dozen audit messages during boot comparing to over thousand of journal messages total. In other words this is rather meaningless, not worth looking for a hacks around that. Everyone can test themselves.

@loqs yes, I don't think there are reasons for keeping audit=0 anymore.

> I think it was the journal being filled with messages when audit in userspace is not configured...

Just stumbled upon this problem after upgrading to 4.18.1.
Probably worth noting that one can stop journald retrieving the audit logs:
`systemctl mask systemd-journald-audit.socket`

Took me a while to find this, maybe it is worth adding this to the wiki.

@t27049215 sure, you can add this to wiki. Can you tell how many audit messages did you get?

I got quite a couple: 2 messages per SSH login, 21 during boot, and another 185 rate-limited ones (e.g. "kauditd_printk_skb: 147 callbacks suppressed").

Are we sure there's no performance impact of this? Historically, CentOS was slower than other distributions, and CONFIG_AUDIT might be a reason.

https://www.phoronix.com/scan.php?page=article&item=5distros-post-spectre&num=1

@lnicola audit is enabled on all tested distros along clearlinux which always win benchmarks, see https://github.com/clearlinux-pkgs/linux/blob/master/config#L82 so I presume CONFIG_AUDIT might NOT be a reason.

@spinka I wasn't aware of that. On Clear Linux, at least, it's only been enabled three weeks ago: https://github.com/clearlinux-pkgs/linux/commit/9a88837b6aa281998d649a0baad6eca09946c4cd#diff-2245023265ae4cf87d02c8b6ba991139.

@lnicola perhaps for the same reason it's now enabled in Arch - the performance concerns are gone. In other distros it was enabled for decades as it's mandatory for selinux and apparmor.

BTW: you can add 'audit=0' to your boot cmdline to suppress messaging.