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

[Daniel Micay]

On 28/03/14 06:54 AM, Arthur Țițeică wrote:
> Hi,
> 
> În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris:
>> And here is my problem: Audit is enabled by default and must be
>> explicitly disabled by the admin. This is a showstopper for me! There is
>> no kernel option to configure audit to be disabled by default (as far as
>> I am aware) so that it can be enabled with 'audit=1' on the command line.
> 
> I couldn't find a definitive answer but the two documents I did find ¹² 
> suggest that having selinux and audit fully functional (not just enabled) has 
> no real performance impact.
> 
> Kernel debugging options on the other side seem to have a much bigger impact.
> 
> It raises a question mark that the two most important components of a system 
> (systemd and the kernel) have security measures disabled.

These 'security measures' do nothing but provide hooks for malware to
latch onto. Audit and LSM are a rootkit author's wet dream. It's
strictly a security *improvement* to have them disabled if there's no
userspace support as it just increases the kernel surface area and
provides more useful post-exploitation tools.

Claiming that we will have 'security measures disabled' is just
hyperbole when Arch Linux is shipping with protected symlinks,
hardlinks, ptrace_scope=1 and stack smashing protection. It certainly
doesn't disable namespaces and seccomp-bpf.

> People in this thread like to put out the over subjective "lightweight" factor 
> but still there are no bug reports or any other solid evidence that the kernel 
> ate their computers since apparmor, selinux and audit were semi-silently 
> enabled a few builds back.

Security needs to be simple, predictable and well understood. It needs
to be provably correct and easily audited. SELinux is none of these
things. I don't really understand why a distribution striving for
simplicity would ever enable it.

It's the same kind of hogwash as Windows security tokens, where it looks
great from a theoretical point of view but is far too complex to
actually use correctly. The Chromium sandbox is broken over and over on
Windows because this complex token design simply doesn't work. On Linux,
it uses a simple chroot, namespaces and seccomp whitelist. It doesn't
ever get in the way of users, and it's easy for any developer to understand.

If a story ran on the Guardian tomorrow showing that the NSA
open-sourced SELinux to set back the development of MAC by *years* by
sending people down the wrong path, I would not be the least bit
surprised. :P

> The facts will remain though:
> 
> * the kernel will still be "everything and the kitchen sink".
> * no provable performance enhancement so far.
> * security measures will get back at square 1.

Neither AppArmor or SELinux is provided in the official repositories, so
enabling these in the kernel only adds attack surface. I doubt that
using AUR packages provided by a different group of maintainers every
week is going to improve anyone's security. If someone wants to attack
Arch users, their easiest shot at it is taking over a somewhat popular
AUR package (like apparmor) and sticking some subtly malicious code in
the source or install file.

-------------- 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-general/attachments/20140328/094661e9/attachment.asc>