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

[Thomas Bächler]

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?

> 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?

> 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".

> * 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.

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.

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.

> * 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.

> d) Don't create new packages and trim linux' config (this is your
> idea, if I understood correctly).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140327/e69dc4d3/attachment.asc>