Disallowing perf_event_open()

An Android security measure that limits the ability of processes to access the perf events subsystem ran up against some, perhaps surprising, resistance when it was recently proposed for the mainline. The patch simply provides another setting for the kernel.perf_event_paranoid sysctl parameter to disallow unprivileged processes from accessing the perf_event_open() system call at all. It is currently used in both Android and Debian kernels, but some kernel developers see it as too much of a "big hammer" approach.

Jeff Vander Stoep posted the patch on July 27. It adds a another value that can be set for the sysctl parameter (i.e. kernel.perf_event_paranoid=3) that restricts perf_event_open() to processes with the CAP_SYS_ADMIN capability. Currently, perf_event_paranoid is set to 2 by default, which disallows access to some perf features (raw tracepoint access, CPU event access, and kernel profiling) to processes without the proper capabilities; the patch does not change the default. He also submitted another patch that would allow configuring the kernel to make 3 be the default perf_event_paranoid value.

In the first patch, he noted five vulnerabilities worthy of CVE numbers that have recently been found in perf and argued that allowing access to it increases the attack surface of the kernel. For production kernels, that may not make sense, so the patch is intended to allow administrators to restrict access to perf, while still providing a means for developers and others to access the tool as needed (by granting CAP_SYS_ADMIN). The patches are based on the grsecurity PERF_HARDEN feature and were first proposed by Ben Hutchings back in January. At that time, he said it had been running in the Debian kernel since August 2015 with no complaints.

It is a fairly simple and straightforward change, but Peter Zijlstra objected that providing a way to turn off perf because of some bugs was heavy-handed: "We have bugs we fix them, we don't kill complete infrastructure because of them." He also thought that it would inhibit new and innovative uses for the tool:

Daniel Micay noted that the functionality would still be available to privileged processes and that Android will allow access by unprivileged processes, but that capability must be enabled from the adb shell. Furthermore:

Micay was skeptical that an LSM-based approach would work, as was Kees Cook, who said: "I'm not against an LSM, but I think it's needless complexity when there is already a knob for this but it just doesn't go 'high' enough." He also noted that bugs live a long time ("an average of 5 years from introduction to fix") and they can last even longer when you take product update lifecycles into account. He argued that administrators need the ability to reduce the attack surface of their systems:

The use case Zijlstra mentioned might be a good reason to change the value of the setting, Cook said, but there are other use cases where administrators want to be able to reduce their systems' attack surface when running a pre-built kernel. But Zijlstra disagreed; he is concerned that having this knob available will mean that administrators blindly apply it. That would have the effect of stopping the development of use cases like he described:

Cook was undeterred, however, saying that the feature is based on a risk analysis of the attack surface, and that there are "hundreds of millions of end-users for whom perf is not needed". Beyond that, though, Zijlstra's argument assumes that the knob is not available, but that simply isn't true:

Ingo Molnar agreed with Zijlstra that the approach was "too coarse". He suggested that perf is not just a "narrow debugging mechanism" that can simply be turned off, but that it is a "wide scope performance measurement and event logging infrastructure that is being utilized not just by developers but by apps and runtimes as well".

Micay pointed out that the wide scope of perf is part of its problem from a security perspective. Because it has been a "frequent source of vulnerabilities", it has been disabled by some distributions. Part of the problem also lies outside of the core kernel, he said: "It's extended by lots of vendor code to specific to platforms too, so it isn't just some core kernel code that's properly reviewed."

The coarseness of the setting also concerned Eric W. Biederman. He suggested that many of the features to reduce the attack surface amount to a "system wide off switch" for features like user namespaces and perf. The result is that new applications cannot take advantage of these features, which turns the attack-surface reduction into "great big denial of service attacks on legitimate users". He also suggested several ideas for ways to make the feature less coarse: "I vote for sandboxes. Perhaps seccomp. Perhaps a per userns sysctl. Perhaps something else."

That's about where things stand at this point. The second patch to allow configuring the kernel to default to denying access to perf has seemingly been dropped. The first will undoubtedly live on in grsecurity, Android, and Debian (at least), which seems to undermine the concern that Zijlstra, Molnar, and Biederman have—as Cook said, the change has already happened in some places. Whether a more fine-grained approach emerges remains to be seen, but it is a little hard to see who would work on it. Distributions already have their solution at this point.