Discussion:
Revisiting the SELinux/audit question: Disabling audit on the kernel command line
Add Reply
Tobias Markus
2017-02-12 17:43:22 UTC
Reply
Permalink
Raw Message
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.
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"
SET
2017-02-12 19:53:19 UTC
Reply
Permalink
Raw Message
Post by Tobias Markus
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
Post by Tobias Markus
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
2017-02-12 21:16:36 UTC
Reply
Permalink
Raw Message
Post by SET
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
2017-02-13 15:26:46 UTC
Reply
Permalink
Raw Message
Hi,
Post by SET
Post by Tobias Markus
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 
https://lists.archlinux.org/pipermail/arch-general/2014-March/035658.html
Post by Tobias Markus
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.
Post by SET
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.
Post by SET
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.
Post by SET
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
n***@netcourrier.com
2017-02-13 16:35:38 UTC
Reply
Permalink
Raw Message
Post by Tobias Markus
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.
Post by Tobias Markus
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.
Post by Tobias Markus
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
2017-02-12 21:02:17 UTC
Reply
Permalink
Raw Message
Post by Tobias Markus
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
2017-02-13 15:00:47 UTC
Reply
Permalink
Raw Message
Post by Leonid Isaev
Post by Tobias Markus
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
2017-02-12 22:13:43 UTC
Reply
Permalink
Raw Message
Post by Tobias Markus
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
2017-02-13 15:18:17 UTC
Reply
Permalink
Raw Message
Post by Nicolas Iooss
Post by Tobias Markus
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 via arch-general
2017-02-13 18:34:09 UTC
Reply
Permalink
Raw Message
Post by Tobias Markus
Post by Nicolas Iooss
Post by Tobias Markus
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.
Post by Tobias Markus
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
Loading...