On Tue, 2016-08-02 at 11:52 +0200, Peter Zijlstra wrote: > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > > > When kernel.perf_event_paranoid is set to 3 (or greater), disallow > > all access to performance events by users without CAP_SYS_ADMIN. > > > > This new level of restriction is intended to reduce the attack > > surface of the kernel. Perf is a valuable tool for developers but > > is generally unnecessary and unused on production systems. Perf may > > open up an attack vector to vulnerable device-specific drivers as > > recently demonstrated in CVE-2016-0805, CVE-2016-0819, > > CVE-2016-0843, CVE-2016-3768, and CVE-2016-3843. > > We have bugs we fix them, we don't kill complete infrastructure > because > > of them. It's still accessible to privileged processes either way. Android still allows access from unprivileged processes but it can only be enabled via the debugging shell, which is not enabled by default either. It isn't even possible to disable the perf events infrastructure via kernel configuration for every architecture right now. You're forcing people to have common local privilege escalation and information leak vulnerabilities for something few people actually use. This patch is now a requirement for any Android devices with a security patch level above August 2016. The only thing that not merging it is going to accomplish is preventing a mainline kernel from ever being used on Android devices, unless you provide an alternative it can use for the same use case. https://source.android.com/security/bulletin/2016-08-01.html > > This new level of > > restriction allows for a safe default to be set on production > > systems > > while leaving a simple means for developers to grant access [1]. > > So the problem I have with this is that it will completely inhibit > development of things like JITs that self-profile to re-compile > frequently used code. > > I would much rather have an LSM hook where the security stuff can do more fine grained control of things. Allowing some apps perf usage while > denying others. If the only need was controlling access per-process statically, then using seccomp-bpf works fine. It needs to be dynamic though. I don't think SELinux could be used to provide the functionality so it would have to be a whole new LSM. I doubt anyone will implement that when the necessary functionality is already available. It's already exposed only for developers using profiling tools until they reboot, so finer grained control wouldn't accomplish much.
Attachment:
signature.asc
Description: This is a digitally signed message part
