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.