I'm developing an Authorization Plug-In and have stumbled upon a concerning behavior regarding credential caching that may have security implications. Consider this scenario: I'm working on a Mac without admin privileges, and I need to temporarily disable the Firewall for some testing. An administrator physically comes to my machine, inputs their credentials to disable the Firewall, and then leaves. What follows is that, for a short period after this action, the administrator's credentials remain cached in Authorization Services. During this window, I can perform some additional privileged operations without any re-authentication. For example, I can open Activity Monitor and send SIGKILL signals to arbitrary privileged processes (!!). From what I could gather, this happens because system.preferences.network shares cached credentials with other authorization rights. Even more concerning, even when I explicitly modify the authorization database to prevent credential sharing for this specific right, the behavior persists! I suspect the issue relates to the underlying shared authentication rules (such as authenticate-admin-30, which com.apple.activitymonitor.kill uses), but I've been unable to modify these rules to test this theory. From my understanding, the most concerning aspect is that even if all system Authorization Rights were configured to not share credentials, third-party applications could still create proprietary rights that might end up sharing credentials anyway. From my Auth Plug-In, I've tried unsetting the kAuthorizationEnvironmentShared context value (even though the documentation in AuthorizationTags.h tells me that the value is ignored), and looking for ways to override the timeout for shared credentials, both without success. Finally, I'm looking to answer some questions that have been raised: I understand that this credential sharing is a feature, but isn't the behavior I described actually a security vulnerability? I worry that other (potentially more dangerous) operations may be able to exploit this. Is there a recommended way to prevent privileged credentials from being reused across arbitrary authorization rights if the original process does not destroy the auth reference? Are there any options from within an Authorization Plug-In to ensure more strict authentication boundaries? What exactly is the authorization "session" mentioned in /System/Library/Security/authorization.plist? Does this concept imply that System Settings.app and Activity Monitor.app share the same session in my previous example? This post ended up being quite long, but unfortunately, documentation on the subject seems incredibly scarce. For reference, the little information I could find came from: QA 1277 The Credentials Cache and the Authentication Dialog Comments on /System/Library/Security/authorization.plist

From what I've gathered from the (rather old) documentation and sample projects on Authorization Plugins, I understand that those can be used to extend the macOS authorization services with custom (and possibly quite complex) requirements for privilege management. During my testing, I found it to be technically possible to allow a normal (non-admin) user to perform some actions that they normally couldn't by leveraging plugin mechanisms. For instance, if I alter the class of system.preferences.network from user to evaluate-mechanisms I can make it so my custom plugin decides which user is actually able to make modifications to the system through the Network settings pane. However, I've noticed that if I leave the actual authentication to the built-in authentication mechanism and perform my validations after that, the user will face a rather odd message: Clearly, even though this seems to work like I'd expected it to, there's something strange going on here. So my question is, what can I actually achieve with authorization plugins in terms of managing system privileges, and what should I use it for? Are there any alternatives I could consider? And if so, could they offer me the flexibility that implementing my own custom logic as a plugin does? I'm not sure what the best practices and recommendations are in terms of both security and usability regarding these plugins, and would very much appreciate some pointers in the right direction.