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