[arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line

Tobias Markus

12 Feb 2017 12 Feb '17

5:43 p.m.

Hi, As some of you might know, the question of enabling SELinux support in the official Arch Linux kernel package has been brought up a number of times. The main issue that has been pointed out the previous time was that enabling SELinux depends on CONFIG_AUDIT which is considered unnecessary or even harmful for most desktop users since it generates a flood of kernel log messages. Citing Thomas Bächler's previous post (in 2014) on the matter [1]:

...

And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line.

Actually, I think there is a perfectly valid and simple way to disable audit by default: By using the built-in kernel command line. This makes it possible to specify a number of kernel parameters at build time that the kernel prepends to the usual command line it gets from the bootloader. By specifying CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="audit=0" in the configuration [2], the audit subsystem is disabled by default, but users intending to use it can do so by manually setting audit=1 on the bootloader's command line. That in turn would override the audit=0 specified on the built-in command line. I would be glad if Arch Linux's official kernel could support SELinux again this way! Thanks for your comments, Tobias [1] https://lists.archlinux.org/pipermail/arch-general/2014-March/03567 9.html [2] For menuconfig, look at the very end under "Processor type and features"

Show replies by date

SET

12 Feb 12 Feb

7:53 p.m.

Le dimanche 12 février 2017 18:43:22 CET Tobias Markus a écrit :

...

I would be glad if Arch Linux's official kernel could support SELinux again this way! https://lists.archlinux.org/pipermail/arch-general/2014-March/035679.html

Thank you for the link you posted. I went through most of the discussion. This quote is what strikes me most : https://lists.archlinux.org/pipermail/arch-general/2014-March/035658.html

...

That they are disabled at runtime does not mean that they have no impact at runtime. At best, it's "only" a performance impact and at worst, it even causes problems.

Everything has already been discussed. The global conclusions seem to be : Most users don't need SELinux/AppArmor or anything that protects them from themselves; Implementing these features in the kernel may lead to more trouble than ease; Arch kernel's devs and other devs are not ready for the tremendous tasks following such a decision; These features can be compiled in personal kernels if required; Arch devs do that on a voluntary basis and can't respond to all requests. For me, I'm happy with Arch as it is, I'm happy the previous discussion led to the 'no need' conclusion, and I just want to voice I wish it goes on this way. Regards.

Jeremy Brown

9:16 p.m.

On Sun, Feb 12, 2017 at 08:53:19PM +0100, SET wrote:

...

Most users don't need SELinux/AppArmor or anything that protects them from themselves;

Not to nitpick, but given all the recent talk of things like gaping Webkit vulnerabilities I think the benefits of adopting something like AppArmor would go well beyond protecting users from themselves. Jeremy

Tobias Markus

13 Feb 13 Feb

3:26 p.m.

Hi, On Sun, 2017-02-12 at 20:53 +0100, SET wrote:

...

Le dimanche 12 février 2017 18:43:22 CET Tobias Markus a écrit :

...
I would be glad if Arch Linux's official kernel could support SELinux again this way! https://lists.archlinux.org/pipermail/arch-general/2014-March/035679.html

Thank you for the link you posted. I went through most of the discussion. This quote is what strikes me most : https://lists.archlinux.org/pipermail/arch-general/2014-March/035658.html

...
That they are disabled at runtime does not mean that they have no impact at runtime. At best, it's "only" a performance impact and at worst, it even causes problems.

The performance reasoning in that threat never really talked about hard metrics, it was mostly looking at kernel code and guessing what performance impact it would have. While I do think that there is no such thing as a free lunch, to my knowledge there are no recent benchmarks comparing syscall performance with and without the SELinux/audit config options.

...

Everything has already been discussed. The global conclusions seem to be :

Most users don't need SELinux/AppArmor or anything that protects them from themselves; Implementing these features in the kernel may lead to more trouble than ease; Arch kernel's devs and other devs are not ready for the tremendous tasks following such a decision;

I'm not quite sure which tremendous task you mean? Enabling the audit/SELinux config option in itself is not really a maintenance burden.

...

These features can be compiled in personal kernels if required;

Yes, of course - but wouldn't you agree that the Wiki page asking you to compile your own kernel first somewhat hinders users interested in trying out SELinux? Furthermore, I don't think that the theoretical next step in Arch Linux SELinux support, i.e. userspace tools in [community]/[extra], could ever be reasonably done if the actual kernel does not support SELinux.

...

Arch devs do that on a voluntary basis and can't respond to all requests.

For me, I'm happy with Arch as it is, I'm happy the previous discussion led to the 'no need' conclusion, and I just want to voice I wish it goes on this way.

Regards.

Greetings Tobias

nmset＠netcourrier.com

4:35 p.m.

Le lundi 13 février 2017 16:26:46 CET Tobias Markus a écrit :

...

Enabling the audit/SELinux config option in itself is not really a maintenance burden. Userspace tools, SE policies... the 'users interested in trying out SELinux' won't do that.

...

but wouldn't you agree that the Wiki page asking you to compile your own kernel first somewhat hinders users interested in trying out SELinux? A huge interest will lead them to build from scratch.

...

I don't think that the theoretical next step in Arch Linux SELinux support, i.e. userspace tools in [community]/[extra], could ever be reasonably done if the actual kernel does not support SELinux. The theoretical next step is not a natural move. Arch users do not have military grade security needs. Even sensitive industries like power plants, or less sensitive businesses like the post office, won't use a bleeding edge distro like Arch.

Regards.

Leonid Isaev

12 Feb 12 Feb

9:02 p.m.

On Sun, Feb 12, 2017 at 06:43:22PM +0100, Tobias Markus wrote:

...

I would be glad if Arch Linux's official kernel could support SELinux again this way!

AFAIR, coreutils and many other things need to be rebuilt to support selinux. -- Leonid Isaev

Tobias Markus

13 Feb 13 Feb

3 p.m.

On Sun, 2017-02-12 at 14:02 -0700, Leonid Isaev wrote:

...

On Sun, Feb 12, 2017 at 06:43:22PM +0100, Tobias Markus wrote:

...
I would be glad if Arch Linux's official kernel could support SELinux again this way!

AFAIR, coreutils and many other things need to be rebuilt to support selinux.

Hi Leonid, this really is just about the kernel, not the related userspace tools. Of course it would be great to have SELinux tools in an official Arch repository, but that is another question entirely. And I guess there will be no tools if the official kernel doesn't support SELinux. Greetings Tobias

Nicolas Iooss

12 Feb 12 Feb

10:13 p.m.

On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus wrote:

...

Hi,

As some of you might know, the question of enabling SELinux support in the official Arch Linux kernel package has been brought up a number of times. The main issue that has been pointed out the previous time was that enabling SELinux depends on CONFIG_AUDIT which is considered unnecessary or even harmful for most desktop users since it generates a flood of kernel log messages.

Hi, Do you have more information about this unwanted flood of messages? From my personal experience on systems with SELinux and audit, the application which produces the biggest number of audit events is Chromium, because of misconfigured seccomp rules that report in audit log every call to set_robust_list(). This has been reported two years ago on Chromium bug tracker and the developers seem unwilling to fix it ( https://bugs.chromium.org/p/chromium/issues/detail?id=456535). If there are similar problems which need to be fixed before thinking of enabling audit compilation in Arch Linux kernel, where can I find information on them? Regards, Nicolas

Tobias Markus

13 Feb 13 Feb

3:18 p.m.

On Sun, 2017-02-12 at 23:13 +0100, Nicolas Iooss wrote:

...

On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus wrote:

...
Hi,

As some of you might know, the question of enabling SELinux support in the official Arch Linux kernel package has been brought up a number of times. The main issue that has been pointed out the previous time was that enabling SELinux depends on CONFIG_AUDIT which is considered unnecessary or even harmful for most desktop users since it generates a flood of kernel log messages.

Hi, Do you have more information about this unwanted flood of messages? From my personal experience on systems with SELinux and audit, the application which produces the biggest number of audit events is Chromium, because of misconfigured seccomp rules that report in audit log every call to set_robust_list(). This has been reported two years ago on Chromium bug tracker and the developers seem unwilling to fix it ( https://bugs.chromium.org/p/chromium/issues/detail?id=456535). If there are similar problems which need to be fixed before thinking of enabling audit compilation in Arch Linux kernel, where can I find information on them?

Regards, Nicolas

Hi Nicolas, I have also seen a flood of audit messages arising from Chromium. However, the configuration I propose would not actually enable audit by default, i.e. unless you explicitly set "audit=1" in the bootloader's kernel command line, the audit subsystem will be disabled and thus silent. In other words, if you don't want to use SELinux/audit, the impact should be minimal. Since the Chromium bug you mentioned is an application bug, I don't think it should hinder enabling the audit option, especially since audit would be opt-in. The reason for Chromium's message floods is that Chromium create quite a lot of processes and (as written in the bug report you mentioned) set_robust_list is called during that. So floods of audit messages should be rather atypical. Greetings Tobias

Daniel Micay

6:34 p.m.

On Mon, 2017-02-13 at 16:18 +0100, Tobias Markus wrote:

...

On Sun, 2017-02-12 at 23:13 +0100, Nicolas Iooss wrote:

...
On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus wrote:

...
Hi,

As some of you might know, the question of enabling SELinux support in the official Arch Linux kernel package has been brought up a number of times. The main issue that has been pointed out the previous time was that enabling SELinux depends on CONFIG_AUDIT which is considered unnecessary or even harmful for most desktop users since it generates a flood of kernel log messages.

Hi, Do you have more information about this unwanted flood of messages? From my personal experience on systems with SELinux and audit, the application which produces the biggest number of audit events is Chromium, because of misconfigured seccomp rules that report in audit log every call to set_robust_list(). This has been reported two years ago on Chromium bug tracker and the developers seem unwilling to fix it ( https://bugs.chromium.org/p/chromium/issues/detail?id=456535). If there are similar problems which need to be fixed before thinking of enabling audit compilation in Arch Linux kernel, where can I find information on them?

Regards, Nicolas

Hi Nicolas,

I have also seen a flood of audit messages arising from Chromium. However, the configuration I propose would not actually enable audit by default, i.e. unless you explicitly set "audit=1" in the bootloader's kernel command line, the audit subsystem will be disabled and thus silent. In other words, if you don't want to use SELinux/audit, the impact should be minimal.

Since the Chromium bug you mentioned is an application bug, I don't think it should hinder enabling the audit option, especially since audit would be opt-in.

It's not a bug. It's intentional hardening... and is correct.

...

The reason for Chromium's message floods is that Chromium create quite a lot of processes and (as written in the bug report you mentioned) set_robust_list is called during that. So floods of audit messages should be rather atypical.

Greetings Tobias

2628

Age (days ago)

2629

Last active (days ago)

List overview

Download

9 comments

7 participants

participants (7)

Daniel Micay
Jeremy Brown
Leonid Isaev
Nicolas Iooss
nmset＠netcourrier.com
SET
Tobias Markus