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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to