> The default has no impact on the "it's too coarse and limiting" > negative property > of this patch, which is the show-stopper aspect. Please fix that > aspect instead of > trying to argue around it. Disabling perf events in the kernel configuration is even more limiting, and is currently the alternative to doing it this way. It makes sense for debugging features to be disabled in production releases of products unless there's a way to control them where risk isn't increased. Having a way to toggle it dynamically will allow it to be remain available. > This isn't some narrow debugging mechanism we can turn on/off globally > and forget > about, this 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. The incredibly wide scope is why it's such a big security problem. If it wasn't such a frequent source of vulnerabilities, it wouldn't have been disabled for unprivileged users in grsecurity, Debian and then Android. 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. I don't think there are runtimes using this for JIT tracing. Perhaps it doesn't actually suit their needs. It's a theoretical use case. > > Let me take this another way instead. What would be a better way to > > provide a > > mechanism for system owners to disable perf without an LSM? (Since > > far fewer > > folks run with an enforcing "big" LSM: I'm seeking as wide a > > coverage as > > possible.) > > Because in practice what will happen is that if the only option is to > do something > drastic for sekjurity, IT departments will do it - while if there's a > more > flexible mechanism that does not throw out the baby with the bath > water that is > going to be used. It's already done: Android and Debian disable it for unprivileged users by default. It's already done for most of desktop and mobile Linux and perhaps even most servers. Not providing functionality desired by downstream doesn't mean it won't be provided there. They'll keep doing it whether or not this lands. If it doesn't land, it will only mean that mainline kernels aren't usable for making Android devices. They need to pass the compatibility test suite, which means having this. The mechanism could change but I don't see why the actual requirement would. > This is as if 20 years ago you had submitted a patch to the early > Linux TCP/IP > networking code to be on/off via a global sysctl switch and told > people that > "in developer mode you can have networking, talk to your admin". > > We'd have told you: "this switch is too coarse and limiting, please > implement > something better, like a list of routes which defines which IP ranges > are > accessible, and a privileged range of listen sockets ports and some > flexible > kernel side filtering mechanism to inhibit outgoing/incoming > connections". > > Global sysctls are way too coarse. The end result of submitting an LSM hook instead of using this would probably come down to having a global sysctl toggle in Yama. There would be two sysctl controls for perf restrictions rather than one which is needless complexity for the interface. Android and Debian would be using a fine-grained perf LSM to accomplish the same thing: globally disabling it for unprivileged users when not doing development. The nice thing about fine-grained control would be implementing a *more* restrictive policy for the case when it's toggled on. It wouldn't necessarily have to be globally enabled, only enabled for the relevant user or even a specific process, but that would be complicated to implement.
Attachment:
signature.asc
Description: This is a digitally signed message part
