FS#42954 - [linux] 4.2.x Reenable CONFIG_AUDITSYSCALL

Attached to Project: Arch Linux
Opened by Jan Alexander Steffens (heftig) - Saturday, 29 November 2014, 15:20 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 19 August 2018, 23:03 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Can we reenable CONFIG_AUDITSYSCALL? This would restore /proc/self/loginuid, which is needed for getlogin() to work for processes that have no terminal, such as in display-managed sessions.

As I understand, it was originally disabled because of an incompatibility with containers, but as of kernel 3.14 this can be solved and at least systemd-nspawn is patched since http://cgit.freedesktop.org/systemd/systemd/commit/?id=db999e0f923ca6c2c1b919d0f1c916472f209e62 .
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Sunday, 19 August 2018, 23:03 GMT
Reason for closing:  Implemented
Additional comments about closing:  linux 4.18.arch1-1
Comment by Daniel Micay (thestinger) - Tuesday, 16 December 2014, 02:04 GMT
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
Comment by Jan Alexander Steffens (heftig) - Sunday, 08 February 2015, 22:01 GMT
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.
Comment by Jan Alexander Steffens (heftig) - Monday, 09 February 2015, 00:24 GMT
Hm, unfortunately journald unconditionally enables auditing (enable_audit in src/journal/journald-audit.c) even when libaudit support is not compiled into systemd.
Comment by Jan Alexander Steffens (heftig) - Monday, 09 February 2015, 01:24 GMT
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?
Comment by Daniel Micay (thestinger) - Monday, 09 February 2015, 01:39 GMT
> 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.
Comment by Jan Alexander Steffens (heftig) - Monday, 09 February 2015, 02:10 GMT
Perhaps something like this, then?
Comment by Tommy Schmitt (spinka) - Sunday, 12 August 2018, 14:16 GMT
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.
Comment by AK (Andreaskem) - Sunday, 12 August 2018, 17:53 GMT
Meltdown only affected Intel processors so these concerns still apply to kernels running on AMD systems.
Comment by loqs (loqs) - Sunday, 12 August 2018, 18:28 GMT Comment by Tommy Schmitt (spinka) - Sunday, 12 August 2018, 20:25 GMT
@Andreaskem: loqs is right, the code was completely removed from the kernel regardless of cpu.
Comment by Jan Alexander Steffens (heftig) - Sunday, 12 August 2018, 20:29 GMT
I'll consider following what -hardened does and enabling AUDIT but disabling it by default (via built-in CMDLINE audit=0).
Comment by AK (Andreaskem) - Monday, 13 August 2018, 06:07 GMT
Fair enough. I guess there were enough good reasons aside from PTI to remove the fast path.
Comment by Tommy Schmitt (spinka) - Monday, 13 August 2018, 10:24 GMT
@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
Comment by loqs (loqs) - Monday, 13 August 2018, 21:54 GMT
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?
Comment by Jan Alexander Steffens (heftig) - Monday, 13 August 2018, 22:02 GMT
Yeah, not sure I'll let it out of testing this way but I forgot what else was objectionable.
Comment by loqs (loqs) - Monday, 13 August 2018, 22:30 GMT
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
Comment by Tommy Schmitt (spinka) - Monday, 13 August 2018, 23:25 GMT
@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
Comment by loqs (loqs) - Monday, 13 August 2018, 23:42 GMT
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?
Comment by Tommy Schmitt (spinka) - Tuesday, 14 August 2018, 13:54 GMT
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.
Comment by t27049215 (t27049215) - Saturday, 18 August 2018, 07:46 GMT
> 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.
Comment by Tommy Schmitt (spinka) - Saturday, 18 August 2018, 11:09 GMT
@t27049215 sure, you can add this to wiki. Can you tell how many audit messages did you get?
Comment by Laurențiu Nicola (lnicola) - Saturday, 18 August 2018, 15:30 GMT
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
Comment by Tommy Schmitt (spinka) - Saturday, 18 August 2018, 15:35 GMT
@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.
Comment by Laurențiu Nicola (lnicola) - Saturday, 18 August 2018, 15:38 GMT
@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.
Comment by Tommy Schmitt (spinka) - Saturday, 18 August 2018, 15:42 GMT
@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.
Comment by Tommy Schmitt (spinka) - Saturday, 18 August 2018, 16:05 GMT
BTW: you can add 'audit=0' to your boot cmdline to suppress messaging.

Loading...