Revisiting the SELinux/audit question: Disabling audit on the kernel command line

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Revisiting the SELinux/audit question: Disabling audit on the kernel command line

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.

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"
SET
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

SET
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.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

Leonid Isaev-3
In reply to this post by Tobias Markus
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
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

Jeremy Brown
In reply to this post by SET
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
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

Nicolas Iooss
In reply to this post by Tobias Markus
On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

Tobias Markus
In reply to this post by Leonid Isaev-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

Tobias Markus
In reply to this post by Nicolas Iooss
On Sun, 2017-02-12 at 23:13 +0100, Nicolas Iooss wrote:

> On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

Tobias Markus
In reply to this post by SET
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
SET
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

SET
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.
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting the SELinux/audit question: Disabling audit on the kernel command line

arch general mailing list-2
In reply to this post by Tobias Markus
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 <[hidden email]>
> > 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

signature.asc (883 bytes) Download Attachment