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

Nicolas Iooss nicolas.iooss at m4x.org
Thu Mar 27 04:07:23 EDT 2014

2014-03-26 20:18 GMT+01:00 Leonid Isaev <lisaev at umail.iu.edu>:
> On Wed, 26 Mar 2014 19:56:26 +0100
> Thomas Bächler <thomas at archlinux.org> wrote:
> > Hello all,
> >
> > it won't be too long until 3.14 is out and I want to address a topic
> > that has been bugging me for a while. Our kernel includes everything and
> > the kitchensink. I have no problem with delivering drivers that can be
> > built modular, but there are other things that have an unknown impact on
> > everyone.
> >
> > I want to trim our kernel down to what we actually support.
> Thanks for doing this.
> >
> > 1) Once we agreed to disable one LSM, everyone else said "we can enable
> > LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK,
> > Tomoyo, AppArmor and Yama, although we don't support the userspace for
> > any of those.
> >
> > I propose to drop all of them.
> 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].

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. 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
* Second, it's possible to compile things which are disabled at
runtime. For example, I don't need to compile the kernel without IPv4
to test what breaks when running a non-IPv4 kernel, I only need to add
a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
for LSM. Even if they are compiled, they can be enabled/disabled with
such runtime configuration and this config doesn't require much work.
* Third, users who want to combine several unofficial features for
their kernel already have to do weird things. For example, I'm using a
grsec kernel with SELinux. A few months ago, there were linux-grsec
and linux-selinux in the AUR but no package which provided both. Hence
I needed to build a custom package to have both. Now, the next time
linux-grsec's maintainer will sync its config with the official repo,
SELinux will be available in this package (unless I've missed
something) and I'll no longer need to build my custom kernel.

That been said, I agree that having a kernel with less features would
be good. To my mind, here are possible ways :

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.
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].
d) Don't create new packages and trim linux' config (this is your
idea, if I understood correctly).

Any of a) or b) would suits fine for me if you choose to drop LSM in
the lighter config.



[1] https://github.com/Siosm/siosm-selinux
[2] https://github.com/fishilico/selinux-refpolicy-patched
[3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261
[4] https://wiki.archlinux.org/index.php/SELinux
[5] https://github.com/nning/linux-grsec/blob/master/PKGBUILD#L32

More information about the arch-general mailing list