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
Regarding the big picture issue here, I believe that this is working as designed [1]. If you’d like to see that change, my advice is that you file a bug report explaining your concern..
Please post your bug number, just for the record.
What exactly is the authorization "session" mentioned in /System/Library/Security/authorization.plist?
This refers to the security session, which is roughly equivalent to the login session.
QA 1277
It’s hard to believe that this is the second time that truly ancient Q&A has come up in the past few weeks.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] If you look at the design of System Preferences on early versions of Mac OS X, various panels have a lock icon. That reflects the state of the admin credentials. If you’re logged in as a standard user and want to do something that requires privileges, you click the lock icon and enter your admin credentials. If you then want to walk away safely, you click the log icon again. That destroys the credentials you acquired when you unlocked.