[arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Nicolas Iooss]

TL;DR: this is a technical answer which can be seen as slightly
off-topic as it focus only on SELinux and not much about kernel config
trimming.

2014-03-27 13:46 GMT+01:00 Thomas Bächler <thomas at archlinux.org>:
> Am 27.03.2014 09:07, schrieb Nicolas Iooss:
>>>> I agree regarding SELinux/Apparmor (it's not only userspace
>>>> tools, but also
>>> sane application policies that are missing).
>>
>> I strongly disagree with removing LSM from the packaged kernel.
>> I'm currently using SELinux with AUR packages [1] (which I help
>> to maintain) and a custom policy (basically a mix of Tresys'
>> Reference Policy, Fedora policy and Debian patches [2]) and it
>> works fine. The only reason behind "why nobody hasn't asked yet
>> to make libselinux and libsepol official packages?" is that
>> before this happens, the current maintainer of these AUR packages
>> wants a working SELinux policy [3].
>
> You use AUR packages for all kinds of SELinux stuff, so why not use
> a custom kernel for that?

Because there is a chicken-and-egg issue here. The long term
motivation is to migrate SELinux-compiled duplicated packages (like
sudo, systemd...) from the AUR to official packages ("long term"
meaning "no timeline can be given as there are way too many people
against it"). Currently there is a security issue due to package
duplication in the AUR (when a security patch is made for systemd for
example, it takes some time before systemd-selinux is updated). I
won't discuss this more in this thread as it is off topic.
>
>> Here are three arguments to motivate my disagreement.
>>
>> * First, removing LSM support makes it difficult for users to
>> test LSM. Before 3.13 kernel, users needed to recompile their
>> kernel (or to install linux-selinux AUR package) to be able to
>> use SELinux.
>
> So, installing packages from AUR is easy, _except_ when you need
> to install the kernel?

Yes, because there is no easy way to "mix two packages". I don't know
any other software which is provided in different packages depending
on their configuration. Most Archlinux packages support via
configure-time switches many things I've never heard about. Why would it
be different for the kernel? (I'm expecting people to ask me this
question and as I don't have any relevant answer yet, I ask it here.)
>
>> This is a hard first step and I know too many people who thinks
>> "I don't want to recompile my kernel as I've already done magical
>> things to make my graphic card works and I don't want to break my
>> fragile config". Now people just needs to install packages (from
>> unofficial repos or from the AUR) as described in the wiki [4]
>> and reboot to start using SELinux.
>
> So, install a kernel from unofficial repositories or AUR? It's
> "just a package".

If you installed modules with DKMS, you also need to recompile these
modules and it may break. I agree that "it's just a package" and
"nothing should break", but that's just theory and in the real world,
things like unsupported DKMS modules break with a custom kernel and
this increases the difficulty a lot. However this increases the
maintenance burden of unsupported things so it's not relevant here.
>
>> * Second, it's possible to compile things which are disabled at
>> runtime.
>
> 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 whole idea is to make the
> kernel smaller and to avoid problems caused by things we don't make
> use of.
>
>> Even if they are compiled, they can be enabled/disabled with such
>> runtime configuration and this config doesn't require much work.
>
> Do you even know what that means? If I see this right, every time
> the kernel needs to do some permission check, it needs to ask "are
> we using LSM xyz?". In any case, it's more code and thus more room
> for failure.

According to
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/security.c?id=v3.13
and
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c?id=v3.13#n5977
, the security checks are done using a structure of function pointers
(struct security_operations *security_ops) and the execution path to
check a file permission (at
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/read_write.c#n367
for example) looks exactly the same in both "SELinux not compiled" and
"SELinux compiled but disabled" configurations. I may have misunderstood
the code, in such case I'd be glad if you correct me.
>
> I see where you are coming from and I used to think the same way.
> But after we enabled AppArmor and SELinux in 3.13, the audit
> subsystem was silently enabled - and it is _on_ by default. This
> whole story got me thinking, do we even have any idea what the
> consequences of adding these features are? And I don't think we
> do.

This does sound weird. Could you please give me some references to
this so that I can understand better? I only know that SELinux uses
the audit subsystem to report denials and that the audit subsystem can
be disabled at boot time using "audit=0" kernel command line parameter
(and also I've read
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/audit.c?id=v3.13#n1001).

>
> The fact that these LSMs must be compiled into the kernel and
> cannot be built as modules tells you something important: These
> options change the behaviour of the kernel at its core.
>
> I don't have a really strong argument against these options, except
> that once we enable them, we need to deal with problems that they
> may cause users. I think we are better off going with what the
> majority of Arch users use these days (simple DAC LSM) and let
> everyone else deal with their use case themselves.

So, if I understand correctly, your opinion is to restrict as most as
possible the official/supported basis and force "experienced" users
use unsupported packages to do unsupported things. That makes sense
and "distributes" the work between official package maintainers and
AUR package mainteners. I completely agree with a position which aims
to give less work to everyone by distributing the user support.
>
>> * Third, users who want to combine several unofficial features
>> for their kernel already have to do weird things.
>
> Users competent enough to do weird things can compile their own
> kernels.
>
>> a) Create a linux-light package with less features than the
>> linux package, and don't trim linux' configuration. b) Rename
>> linux as "linux-full" (as an official package) and trim linux'
>> config.
>
> I won't maintain two kernels just for the sake of feature-creep.
>
>> c) Create a package ("linux-src"?) which install the kernel
>> sources and provides an easy way to customize the config before
>> making the packages (with pkgbuild). Currently linux-grsec AUR
>> package provides this feature by using the MENUCONFIG environment
>> variable [5].
>
> What is this supposed to do? Makepkg is for building packages,
> pacman is for installing binaries. If you want automated package
> building on upgrades, use Gentoo.
>
Why talking about Gentoo? Using yaourt -G and makepkg is enough for
building kernels with a custom config (thanks, Paul). (By the way, I
also administrate Gentoo and Debian servers but the reasons why I
still use Arch is off-topic). The more I'm thinking of it and the more
I wonder why the "light kernel" wouldn't be an AUR package, so that
users who really want a light kernel can easily compile it themselves?
Maybe it even already exists and nobody has taken time to find it
before starting the discussion? I don't know if the approach "do it in
the AUR and then ask users to test it before asking devs to integrate
changes in official packages" is common/relevant.

Thanks,

Nicolas