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

[Savyasachee Jha]

I think what Nicolas says is a good idea. I realise that Arch is not really
a security-focused distro, but having to not recompile the kernel on my
laptop after every upgrade with SELinux enabled is a pretty awesome thing.
I realise that this is not really relevant to most Archers, but with Siosm
working on a working Arch SELinux Policy, I think that having something
like the SELinux LSM is not really a burden on the user.

On the other hand, (seeing that it has come up) a package like
linux-sources would be wonderful. In short, I think that for something as
essential as the kernel, having multiple configurations (viz. linux,
linux-lts, linux-light and linux-sources) in the official repos is a pretty
good idea. I hope it can be realised.


On Thu, Mar 27, 2014 at 5:07 PM, Nicolas Iooss <nicolas.iooss at m4x.org>wrote:

> Hello,
> 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
> SELinux.
> * 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.
>
> Regards,
>
> Nicolas
>
> [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
>
>


-- 
Savyasachee Jha

*"Without a sign his sword a brave man draws, And asks no omen but his
country's cause."*