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

[Daniel Micay]

On 26/03/14 03:08 PM, Dave Reisner wrote:
> On Wed, Mar 26, 2014 at 07:56:26PM +0100, Thomas Bächler 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.
> 
> +1
> 
>> 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.
> 
> Very much agreed. Though, I wouldn't mind if we kept yama around in some
> disabled form if possible. There's no userspace component here, just the
> ptrace_scope knob in sysctl, which a lot of other distros enable.  It
> affects a rather small number of app, but potentially closes off a
> fairly large security concern.

I think we should keep Yama, because it's a simple knob providing a
significant security boost without any integration into our packages.
It's an especially nice improvement to many of our services able to run
in a chroot, but not yet aware of process namespaces.

Yama previously included knobs for protected symlinks and hardlinks, and
those became core kernel features. It doesn't really make sense to me
that this tiny feature was forced to be an LSM module... it was
originally authored as a built-in sysctl switch and perhaps it will move
in the future too.

If someone wants to support the userspace component of a *non-invasive*
(no patches) LSM module in [extra] or [community] down the road, then
enabling it would make sense. We're never going to have good SELinux
integration, and haphazard patches and policies from the AUR are only
going to do more harm than good.

>> 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without
>> enabling CONFIG_EXPERT. I have no idea what the impact of this option
>> is, other than that it was requested in order to support some tool that
>> can freeze and save single processes resume them later. I am generally
>> sceptical towards options that require CONFIG_EXPERT, so I propose
>> dropping this one, too.
> 
> CRIU userspace tools are in the AUR. +1 to dropping this unless we have
> someone to wants to actually maintain this in the repos.

I don't think this actually works properly with our kernel, as I played
with it and just got a bunch of broken snapshots. I thought about moving
it to [community] in the past, but Mozilla's rewindable debugger has
erased any interest I once had in it:
http://robert.ocallahan.org/2014/03/introducing-rr.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20140326/d40a4443/attachment.asc>