audit: always enable syscall auditing when supported and audit is enabled
PATCH 1/1 audit: always enable syscall auditing when supported and audit is enabled
To the best of our knowledge, everyone who enables audit at compile time also enables syscall auditing; this patch simplifies the Kconfig menus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.
--- init/Kconfig | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)
init/Kconfig +3 -8
@@ -299,20 +299,15 @@ config AUDIT help Enable auditing infrastructure that can be used with another kernel subsystem, such as SELinux (which requires this for - logging of avc messages output). Does not do system-call - auditing without CONFIG_AUDITSYSCALL. + logging of avc messages output). System call auditing is included + on architectures which support it. config HAVE_ARCH_AUDITSYSCALL bool config AUDITSYSCALL - bool "Enable system-call auditing support" + def_bool y depends on AUDIT && HAVE_ARCH_AUDITSYSCALL - default y if SECURITY_SELINUX - help - Enable low-overhead system-call auditing infrastructure that - can be used independently or with another kernel subsystem, - such as SELinux. config AUDIT_WATCH def_bool y
Quoted 6 lines · Paul Moore
To the best of our knowledge, everyone who enables audit at compile time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>
ACK.
Quoted 34 lines
--- init/Kconfig | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)init/Kconfig +3
-9@@ -299,20 +299,15 @@ config AUDIT help Enable auditing infrastructure that can be used with another kernel subsystem, such as SELinux (which requires this for - logging of avc messages output). Does not do system-call - auditing without CONFIG_AUDITSYSCALL. + logging of avc messages output). System call auditing is included + on architectures which support it. config HAVE_ARCH_AUDITSYSCALL bool config AUDITSYSCALL - bool "Enable system-call auditing support" + def_bool y depends on AUDIT && HAVE_ARCH_AUDITSYSCALL - default y if SECURITY_SELINUX - help - Enable low-overhead system-call auditing infrastructure that - can be used independently or with another kernel subsystem, - such as SELinux. config AUDIT_WATCH def_bool y --
Quoted 3 lines
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <[email protected]>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
Hello Paul,
Quoted 6 lines · Paul Moore
To the best of our knowledge, everyone who enables audit at compile time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>
this patch is responsible for massive performance degradation for those who used only CONFIG_SECURITY_APPARMOR.
And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/s
(with some particular CPU frequencies).
Should we revert this patch?
Quoted 39 lines
--- init/Kconfig | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-auditinit/Kconfig +3
-8@@ -299,20 +299,15 @@ config AUDIT help Enable auditing infrastructure that can be used with another kernel subsystem, such as SELinux (which requires this for - logging of avc messages output). Does not do system-call - auditing without CONFIG_AUDITSYSCALL. + logging of avc messages output). System call auditing is included + on architectures which support it. config HAVE_ARCH_AUDITSYSCALL bool config AUDITSYSCALL - bool "Enable system-call auditing support" + def_bool y depends on AUDIT && HAVE_ARCH_AUDITSYSCALL - default y if SECURITY_SELINUX - help - Enable low-overhead system-call auditing infrastructure that - can be used independently or with another kernel subsystem, - such as SELinux. config AUDIT_WATCH def_bool y
Signature · 2 lines
Best regards, Alexander Sverdlin.
Quoted 13 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 6 lines · Paul Moore
To the best of our knowledge, everyone who enables audit at compile time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.
Quoted 6 lines
And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/s
Hi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl -l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,task
If you are using Fedora/CentOS/RHEL, or a similarly configured system, you can find this configuration in the /etc/audit/audit.rules file (be warned, that file is automatically generated based on /etc/audit/rules.d).
Signature · 2 lines
paul moore www.paul-moore.com
Hello Paul,
Quoted 10 lines · Paul Moore
Quoted 10 lines
Quoted 5 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
Quoted 8 lines
Quoted 4 lines
dd if=/dev/zero of=/dev/null count=2M
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
Quoted 7 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in the
/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).
I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Signature · 2 lines
Best regards, Alexander Sverdlin.
Hello Paul,
Quoted 23 lines · Paul Moore
Quoted 9 lines
Quoted 6 lines
To the best of our knowledge, everyone who enables audit at compile time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.Quoted 6 lines
And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl -l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
Quoted 6 lines
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system, you can find this configuration in the
/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).
here are some perf reports for your reference:
Linux fct-0a 4.9.144-xxx armv7l armv7l armv7l GNU/Linux
# Overhead Command Shared Object Symbol
# ........ ....... ................. ............................
#
14.32% dd [kernel.kallsyms] [k] vector_swi
13.70% dd libc-2.28.so [.] __libc_do_syscall
8.42% dd [kernel.kallsyms] [k] current_kernel_time64
5.65% dd [kernel.kallsyms] [k] arm_clear_user
5.65% dd [kernel.kallsyms] [k] __fget_light
5.54% dd [kernel.kallsyms] [k] __audit_syscall_entry
3.79% dd [kernel.kallsyms] [k] fsnotify
2.97% dd libc-2.28.so [.] memcpy
2.94% dd [kernel.kallsyms] [k] __audit_syscall_exit
2.67% dd [kernel.kallsyms] [k] __fsnotify_parent
2.43% dd [kernel.kallsyms] [k] vfs_read
2.24% dd [kernel.kallsyms] [k] __vfs_read
2.23% dd [kernel.kallsyms] [k] vfs_write
1.96% dd [kernel.kallsyms] [k] syscall_trace_exit
1.71% dd [kernel.kallsyms] [k] syscall_trace_enter
1.23% dd [kernel.kallsyms] [k] rw_verify_area
1.22% dd libc-2.28.so [.] read
1.14% dd [kernel.kallsyms] [k] security_file_permission
1.07% dd [kernel.kallsyms] [k] iov_iter_zero
1.01% dd [kernel.kallsyms] [k] __sys_trace_return
0.88% dd libc-2.28.so [.] __GI___libc_write
0.85% dd dd.coreutils [.] 0x00003c48
0.84% dd [kernel.kallsyms] [k] read_iter_zero
0.79% dd [kernel.kallsyms] [k] unroll_tree_refs
0.75% dd [kernel.kallsyms] [k] __vfs_write
0.68% dd [kernel.kallsyms] [k] __fdget_pos
0.64% dd dd.coreutils [.] 0x000013a4
0.59% dd [kernel.kallsyms] [k] dput
0.57% dd [kernel.kallsyms] [k] kfree
0.56% dd [kernel.kallsyms] [k] path_put
0.52% dd [kernel.kallsyms] [k] ret_to_userLinux fctj-0a 4.4.167-g4220c09-xxx armv7l GNU/Linux
# Overhead Command Shared Object Symbol
# ........ ....... ................. ...............................
#
23.91% dd [kernel.kallsyms] [k] vector_swi
19.57% dd libc-2.28.so [.] __libc_do_syscall
5.67% dd [kernel.kallsyms] [k] arm_clear_user
4.25% dd libc-2.28.so [.] memcpy
4.22% dd [kernel.kallsyms] [k] fsnotify
3.93% dd [kernel.kallsyms] [k] __fget_light
3.10% dd [kernel.kallsyms] [k] read_iter_zero
2.51% dd [kernel.kallsyms] [k] vfs_write
2.06% dd [kernel.kallsyms] [k] ret_fast_syscall
1.97% dd [kernel.kallsyms] [k] __fsnotify_parent
1.66% dd libc-2.28.so [.] read
1.65% dd [kernel.kallsyms] [k] __vfs_read
1.63% dd [kernel.kallsyms] [k] mmioset
1.61% dd [kernel.kallsyms] [k] vfs_read
1.47% dd libc-2.28.so [.] __GI___libc_write
1.39% dd [kernel.kallsyms] [k] rw_verify_area
1.39% dd [kernel.kallsyms] [k] security_file_permission
1.34% dd [kernel.kallsyms] [k] iov_iter_init
1.34% dd [kernel.kallsyms] [k] iov_iter_zero
1.20% dd [kernel.kallsyms] [k] local_restart
0.89% dd [kernel.kallsyms] [k] sys_read
0.89% dd [kernel.kallsyms] [k] _cond_resched
0.86% dd [kernel.kallsyms] [k] __fdget_pos
0.85% dd [kernel.kallsyms] [k] sys_write
0.77% dd dd [.] 0x00003df0
0.72% dd [kernel.kallsyms] [k] __vfs_write
0.61% dd dd [.] 0x00003946
0.55% dd dd [.] 0x000038ee
0.51% dd dd [.] 0x00003ca8 Signature · 2 lines
Best regards, Alexander Sverdlin.
Quoted 15 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 12 lines · Paul Moore
Quoted 12 lines
Quoted 5 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 11 lines
Quoted 7 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 6 lines
Quoted 3 lines
you can find this configuration in the
/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
Signature · 2 lines
paul moore www.paul-moore.com
Hello Paul,
Quoted 36 lines · Paul Moore
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 5 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 7 lines
Quoted 7 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
Quoted 8 lines
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in the
/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Quoted 8 lines
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my x86_64 PC and got the following results:
1. empty rules list:
perf record dd if=/dev/zero of=/dev/null count=2M 2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.69685 s, 633 MB/s
perf report:
# Overhead Command Shared Object Symbol
# ........ ....... ................. ..................................
#
14.26% dd [kernel.kallsyms] [k] entry_SYSCALL_64
11.33% dd [kernel.kallsyms] [k] __clear_user
5.00% dd [kernel.kallsyms] [k] fsnotify
4.92% dd libc-2.28.so [.] read
4.80% dd [kernel.kallsyms] [k] __audit_syscall_exit
4.60% dd [kernel.kallsyms] [k] syscall_return_via_sysret
4.24% dd libc-2.28.so [.] __GI___libc_write
3.84% dd [kernel.kallsyms] [k] __indirect_thunk_start
3.82% dd libc-2.28.so [.] __memcpy_ssse3_back
3.04% dd [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe
2.98% dd [kernel.kallsyms] [k] __fget_light
2.97% dd [kernel.kallsyms] [k] do_syscall_64
2.33% dd [kernel.kallsyms] [k] vfs_write
2.32% dd [kernel.kallsyms] [k] __audit_syscall_entry
2.31% dd [kernel.kallsyms] [k] iov_iter_zero
2.22% dd [kernel.kallsyms] [k] syscall_trace_enter
1.89% dd [kernel.kallsyms] [k] syscall_slow_exit_work
1.56% dd [kernel.kallsyms] [k] __fsnotify_parent
1.52% dd [kernel.kallsyms] [k] __x64_sys_write
1.42% dd [kernel.kallsyms] [k] __vfs_read
1.34% dd [kernel.kallsyms] [k] __x64_sys_read
1.30% dd [kernel.kallsyms] [k] vfs_read
1.16% dd [kernel.kallsyms] [k] ksys_write
1.05% dd [kernel.kallsyms] [k] security_file_permission2. auditctl -a never,task
perf record dd if=/dev/zero of=/dev/null count=2M 2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.29384 s, 830 MB/s
perf report:
# Overhead Command Shared Object Symbol
# ........ ....... ................. ...................................
#
16.90% dd [kernel.kallsyms] [k] entry_SYSCALL_64
14.24% dd [kernel.kallsyms] [k] __clear_user
6.00% dd [kernel.kallsyms] [k] fsnotify
5.35% dd [kernel.kallsyms] [k] syscall_return_via_sysret
5.26% dd [kernel.kallsyms] [k] __indirect_thunk_start
4.85% dd libc-2.28.so [.] read
4.81% dd libc-2.28.so [.] __GI___libc_write
4.09% dd libc-2.28.so [.] __memcpy_ssse3_back
3.92% dd [kernel.kallsyms] [k] __fget_light
3.43% dd [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe
3.07% dd [kernel.kallsyms] [k] iov_iter_zero
2.93% dd [kernel.kallsyms] [k] do_syscall_64
2.45% dd [kernel.kallsyms] [k] vfs_write
2.07% dd [kernel.kallsyms] [k] __vfs_read
2.02% dd [kernel.kallsyms] [k] __fsnotify_parent
1.42% dd [kernel.kallsyms] [k] vfs_read
1.34% dd [kernel.kallsyms] [k] ksys_read
1.18% dd [kernel.kallsyms] [k] ksys_write
1.18% dd [kernel.kallsyms] [k] read_iter_zero
1.10% dd [kernel.kallsyms] [k] __vfs_writeWhich brings me to an idea, that the subject patch should have been accompanied by a default "never,task" rule inside the kernel, otherwise you require an extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance levels.
Signature · 2 lines
Best regards, Alexander Sverdlin.
Quoted 49 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 36 lines · Paul Moore
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 5 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 7 lines
Quoted 7 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
Quoted 8 lines
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in the
/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Quoted 8 lines
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my
x86_64PC and got the following results:
...
Quoted 4 lines
Which brings me to an idea, that the subject patch should have been accompanied by a default "never,task" rule inside the kernel, otherwise you require an extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance levels.
[NOTE: I dropped [email protected] from the To/CC line, I left Red Hat for greener pastures several months ago.]
Well, it generally hasn't been an issue as 1) most people that enable audit also enable syscall auditing and 2) most people that enable audit have some sort of audit userspace tools to work with the audit logs (and configure audit if necessary). I don't want to diminish your report, but this change was made several years ago and we really haven't heard of many issues surrounding the change. If we can ever get all of the different arches to support syscall auditing, I'd love to get rid of the syscall auditing Kconfig knob entirely.
If you wanted to put together a patch that added a single "-a never,task" rule on boot I could get behind that, just make it default to off.
Signature · 2 lines
paul moore www.paul-moore.com
Quoted 76 lines · On Mon, 28 Jan 2019 11:26:51 -0500 Paul Moore <[email protected]> wrote:
Quoted 54 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 42 lines · Paul Moore
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 6 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 8 lines
Quoted 8 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
Quoted 8 lines
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in the
/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
Quoted 6 lines
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my
x86_64PC and got the following results:...
Quoted 4 lines
Which brings me to an idea, that the subject patch should have been accompanied by a default "never,task" rule inside the kernel, otherwise you require an extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance levels.
[NOTE: I dropped [email protected] from the To/CC line, I left Red Hat for greener pastures several months ago.]
Well, it generally hasn't been an issue as 1) most people that enable audit also enable syscall auditing and 2) most people that enable audit have some sort of audit userspace tools to work with the audit logs (and configure audit if necessary). I don't want to diminish your report, but this change was made several years ago and we really haven't heard of many issues surrounding the change. If we can ever get all of the different arches to support syscall auditing, I'd love to get rid of the syscall auditing
Kconfigknob entirely.
Quoted 3 lines
If you wanted to put together a patch that added a single "-a never,task" rule on boot I could get behind that, just make it default to off.
That will make processes unauditable for everyone. That's how it gets a speedup is not entering into the audit machinery. I suppose its possible that people may want MAC hardwired events but no syscall events. I don't know if there are other kconfig audit options. but maybe getting it down to audit enabled and syscall auditing as the only choices is probably the most performant.
-Steve
Quoted 79 lines · Steve Grubb
Quoted 76 lines · On Mon, 28 Jan 2019 11:26:51 -0500 Paul Moore <[email protected]> wrote:
Quoted 54 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 42 lines · Paul Moore
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 6 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance degradation for those who used only
CONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 8 lines
Quoted 8 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
Quoted 8 lines
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in the
/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
Quoted 6 lines
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my
x86_64PC and got the following results:...
Quoted 4 lines
Which brings me to an idea, that the subject patch should have been accompanied by a default "never,task" rule inside the kernel, otherwise you require an extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance levels.
[NOTE: I dropped [email protected] from the To/CC line, I left Red Hat for greener pastures several months ago.]
Well, it generally hasn't been an issue as 1) most people that enable audit also enable syscall auditing and 2) most people that enable audit have some sort of audit userspace tools to work with the audit logs (and configure audit if necessary). I don't want to diminish your report, but this change was made several years ago and we really haven't heard of many issues surrounding the change. If we can ever get all of the different arches to support syscall auditing, I'd love to get rid of the syscall auditing
Kconfigknob entirely.
Quoted 6 lines
Quoted 3 lines
If you wanted to put together a patch that added a single "-a never,task" rule on boot I could get behind that, just make it default to off.
That will make processes unauditable for everyone. That's how it gets a speedup is not entering into the audit machinery.
That is pretty much what is being asked for in this thread. It's really no different from what Fedora/CentOS/RHEL (and who knows how many others) ship with their default audit config. It's important to note that you could always delete this rule at runtime; all that is being proposed is to have the kernel populate the the audit ruleset with the "-a never,task" rule *IF* the proposed kernel Kconfig option is enabled (and it would default to being off, you would have to turn it on during build).
Quoted 6 lines
I suppose its possible that people may want MAC hardwired events but no syscall events. I don't know if there are other kconfig audit options. but maybe getting it down to audit enabled and syscall auditing as the only choices is probably the most performant.
-Steve
Signature · 2 lines
paul moore www.paul-moore.com
Quoted 89 lines · On Mon, 28 Jan 2019 15:08:56 -0500 Paul Moore <[email protected]> wrote:
Quoted 81 lines · Steve Grubb
Quoted 78 lines · On Mon, 28 Jan 2019 11:26:51 -0500 Paul Moore <[email protected]> wrote:
Quoted 55 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 43 lines · Paul Moore
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 6 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance
degradation for those who used onlyCONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 8 lines
Quoted 8 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
Quoted 8 lines
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in
the/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
Quoted 6 lines
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my
x86_64PC and got the following results:...
Quoted 4 lines
Which brings me to an idea, that the subject patch should have been accompanied by a default "never,task" rule inside the kernel, otherwise you require an extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance levels.
[NOTE: I dropped [email protected] from the To/CC line, I left Red Hat for greener pastures several months ago.]
Well, it generally hasn't been an issue as 1) most people that enable audit also enable syscall auditing and 2) most people that enable audit have some sort of audit userspace tools to work with the audit logs (and configure audit if necessary). I don't want to diminish your report, but this change was made several years ago and we really haven't heard of many issues surrounding the change. If we can ever get all of the different arches to support syscall auditing, I'd love to get rid of the syscall auditing
Kconfigknob entirely.Quoted 6 lines
Quoted 3 lines
If you wanted to put together a patch that added a single "-a never,task" rule on boot I could get behind that, just make it default to off.
That will make processes unauditable for everyone. That's how it gets a speedup is not entering into the audit machinery.
Quoted 8 lines
That is pretty much what is being asked for in this thread. It's really no different from what Fedora/CentOS/RHEL (and who knows how many others) ship with their default audit config. It's important to note that you could always delete this rule at runtime; all that is being proposed is to have the kernel populate the the audit ruleset with the "-a never,task" rule *IF* the proposed kernel
Kconfigoption is enabled (and it would default to being off, you would have to turn it on during build).
Yes, but you can't add the auditable flag back to the task struct because syscalls never enter audit machinery where it can be added back. Meaning that even if you wanted to audit, there will be processes you never can audit. Whereas deciding via auditd, they become unauditable only after auditd loads the rule. Prior to that they are and all processes are auditable if you decide to audit. So, this is fundamentally different than what fedora does.
-Steve
Quoted 8 lines
Quoted 7 lines
I suppose its possible that people may want MAC hardwired events but no syscall events. I don't know if there are other kconfig audit options. but maybe getting it down to audit enabled and syscall auditing as the only choices is probably the most performant.
-Steve
Quoted 101 lines · Steve Grubb
Quoted 89 lines · On Mon, 28 Jan 2019 15:08:56 -0500 Paul Moore <[email protected]> wrote:
Quoted 81 lines · Steve Grubb
Quoted 78 lines · On Mon, 28 Jan 2019 11:26:51 -0500 Paul Moore <[email protected]> wrote:
Quoted 55 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 43 lines · Paul Moore
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 6 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance
degradation for those who used onlyCONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 8 lines
Quoted 8 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
Quoted 8 lines
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in
the/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
Quoted 6 lines
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my
x86_64PC and got the following results:...
Quoted 4 lines
Which brings me to an idea, that the subject patch should have been accompanied by a default "never,task" rule inside the kernel, otherwise you require an extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance levels.
[NOTE: I dropped [email protected] from the To/CC line, I left Red Hat for greener pastures several months ago.]
Well, it generally hasn't been an issue as 1) most people that enable audit also enable syscall auditing and 2) most people that enable audit have some sort of audit userspace tools to work with the audit logs (and configure audit if necessary). I don't want to diminish your report, but this change was made several years ago and we really haven't heard of many issues surrounding the change. If we can ever get all of the different arches to support syscall auditing, I'd love to get rid of the syscall auditing
Kconfigknob entirely.Quoted 6 lines
Quoted 3 lines
If you wanted to put together a patch that added a single "-a never,task" rule on boot I could get behind that, just make it default to off.
That will make processes unauditable for everyone. That's how it gets a speedup is not entering into the audit machinery.
Quoted 8 lines
That is pretty much what is being asked for in this thread. It's really no different from what Fedora/CentOS/RHEL (and who knows how many others) ship with their default audit config. It's important to note that you could always delete this rule at runtime; all that is being proposed is to have the kernel populate the the audit ruleset with the "-a never,task" rule *IF* the proposed kernel
Kconfigoption is enabled (and it would default to being off, you would have to turn it on during build).
Quoted 7 lines
Yes, but you can't add the auditable flag back to the task struct because syscalls never enter audit machinery where it can be added back. Meaning that even if you wanted to audit, there will be processes you never can audit. Whereas deciding via auditd, they become unauditable only after auditd loads the rule. Prior to that they are and all processes are auditable if you decide to audit. So, this is fundamentally different than what fedora does.
I did see a patch proposed at one point that actually went through and checked/flipped the TIF_SYSCALL_AUDIT bit when auditing was switched off.
Quoted 9 lines
-Steve
Quoted 7 lines
Quoted 7 lines
I suppose its possible that people may want MAC hardwired events but no syscall events. I don't know if there are other kconfig audit options. but maybe getting it down to audit enabled and syscall auditing as the only choices is probably the most performant.
-Steve
- RGB
--
Richard Guy Briggs <[email protected]>
Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Quoted 100 lines · Steve Grubb
Quoted 89 lines · On Mon, 28 Jan 2019 15:08:56 -0500 Paul Moore <[email protected]> wrote:
Quoted 81 lines · Steve Grubb
Quoted 78 lines · On Mon, 28 Jan 2019 11:26:51 -0500 Paul Moore <[email protected]> wrote:
Quoted 55 lines · Alexander (Nokia - DE/Ulm)
Hello Paul,
Quoted 43 lines · Paul Moore
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 6 lines
time also enables syscall auditing; this patch simplifies the
Kconfigmenus by removing the option to disable syscall auditing when audit is selected and the target arch supports it.Signed-off-by Paul Moore <[email protected]>this patch is responsible for massive performance
degradation for those who used onlyCONFIG_SECURITY_APPARMOR.And the numbers are, take the following test for instance:
dd if=/dev/zero of=/dev/null count=2M
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
ARM64: 500MB/s -> 350MB/s ARM: 400MB/s -> 300MB/sHi there.
Out of curiosity, what kernel/distribution are you running, or is this a custom kernel compile? Can you also share the output of 'auditctl
This test was carried out with Linux 4.9. Custom built.
I suspected that was the case, thanks.
Quoted 8 lines
Quoted 8 lines
-l' from your system? The general approach taken by everyone to turn-off the per-syscall audit overhead is to add the "-a never,task" rule to their audit configuration:
# auditctl -a never,taskIf you are using Fedora/CentOS/RHEL, or a similarly configured system,
Quoted 8 lines
This is an embedded distribution. We are not using auditctl or any other audit-related user-space packages.
Quoted 3 lines
you can find this configuration in
the/etc/audit/audit.rulesfile (be warned, that file is automatically generated based on/etc/audit/rules.d).I suppose in this case rule list must be empty. Is there a way to check this without extra user-space packages?
Yes, unless you are loading rules through some other method I would expect that your audit rule list is empty.
Quoted 6 lines
I'm not aware of any other tools besides auditctl to load audit rules into the kernel, although I haven't ever had a need for another tool so I haven't looked very hard. If you didn't want to bring auditctl into your distribution, I expect it would be a rather trivial task to create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my
x86_64PC and got the following results:...
Quoted 4 lines
Which brings me to an idea, that the subject patch should have been accompanied by a default "never,task" rule inside the kernel, otherwise you require an extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance levels.
[NOTE: I dropped [email protected] from the To/CC line, I left Red Hat for greener pastures several months ago.]
Well, it generally hasn't been an issue as 1) most people that enable audit also enable syscall auditing and 2) most people that enable audit have some sort of audit userspace tools to work with the audit logs (and configure audit if necessary). I don't want to diminish your report, but this change was made several years ago and we really haven't heard of many issues surrounding the change. If we can ever get all of the different arches to support syscall auditing, I'd love to get rid of the syscall auditing
Kconfigknob entirely.Quoted 6 lines
Quoted 3 lines
If you wanted to put together a patch that added a single "-a never,task" rule on boot I could get behind that, just make it default to off.
That will make processes unauditable for everyone. That's how it gets a speedup is not entering into the audit machinery.
Quoted 8 lines
That is pretty much what is being asked for in this thread. It's really no different from what Fedora/CentOS/RHEL (and who knows how many others) ship with their default audit config. It's important to note that you could always delete this rule at runtime; all that is being proposed is to have the kernel populate the the audit ruleset with the "-a never,task" rule *IF* the proposed kernel
Kconfigoption is enabled (and it would default to being off, you would have to turn it on during build).
Quoted 7 lines
Yes, but you can't add the auditable flag back to the task struct because syscalls never enter audit machinery where it can be added back. Meaning that even if you wanted to audit, there will be processes you never can audit. Whereas deciding via auditd, they become unauditable only after auditd loads the rule. Prior to that they are and all processes are auditable if you decide to audit. So, this is fundamentally different than what fedora does.
What I'm suggesting is adding an audit rule, just like Fedora, the only difference is that it is going to be populated at boot by the kernel. Sure, it is going to happen earlier than if you use auditctl during boot, but arguably if you want to disable all the syscall auditing, this is what you want. Calling it fundamentally different from what Fedora does is not correct.
For the record, this is something I would only recommend for a limited number of use cases (e.g. limited embedded environments with no need for syscall auditing), as for most users it is better to install a proper audit userspace and just configure it with auditctl during boot.
Signature · 2 lines
paul moore www.paul-moore.com