On 20/04/14 04:32 AM, Florian Pritz wrote:
On 19.04.2014 23:58, Daniel Micay wrote:
For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd.
Going slightly off topic here, but you only seem to connect audit with the systemd bug so might be valuable:
I don't care about audit so I don't use it. Sadly that doesn't work because it defaults to being enabled which means I get tons of audit spam in dmesg.
As long as that's the case I'm against enabling it and the same thing applies to all other features that change the kernel behaviour even if I don't use them.
Sure, that's why I raised this point. Enabling any security feature in the core/linux kernel breaking something by default or even printing a few lines to the kernel log is a hard sell here. As far as I know we only have the nice `ptrace_scope=1` feature enabled because it managed to sneak in at some point.[1] I fought hard against a bug report asking for it to be disabled by default, but I expect more complaints about it because it stops `gdb -p $PID`, `strace -p $PID`, `perf trace $PID` and `reptyr $PID` from working as an unprivileged user. Security-related features are just as hard to sell upstream, even when they're completely optional. For example, PaX has a very low cost sanity check on kernel reference counting. It barely shows up in any profiling and is an optional configuration feature (PAX_REFCOUNT). It prevents a steady stream of bugs from being exploitable, such as this one from a few days ago: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2851 In order to have KASLR in core/linux (once it stops breaking hibernate?), we're going to need to enable dmesg_restrict and kptr_restrict. This means the kernel logs won't be readable as non-root and some things like perf with privileges will be broken. That's hard enough to sell here, but KASLR isn't actually useful until the kernel stops leaking addresses everywhere. It's already shown to be worthless in the current state via simple bypasses. [1] https://bugs.archlinux.org/task/36846