We want to be very clear about everything Secret Chest has access to. This is a deep part of the Apple ecosystem and one we very much agree with. An important aspect of apps that run on Apple devices is that they are not able to access resources outside of themselves unless the route to do is is very well defined, users opt into giving access, and ultimately the user privacy is preserved. This is even true in an enterprise or company-provided app context (at least in most cases). Those routes that developers use to access data often run through what Apple calls extensions.
Application extensions allow developers to import common SDKs into projects in order to build increasingly interesting apps without developing a lot of code for those things vendors expose. They also provide access to things that might not otherwise be available to an app in the Apple ecosystem, due to entitlements. These are for developers but have ramifications that users can see in System Settings and from the command line.
Apple extensions typically allow a developer to bring in various Apple libraries and then call them in their code. For example, com.apple.quicklook.thumbnail is used to produce thumbnails in quicklook; therefore Apple apps like iBooks and Shortcuts and any 3rd party developer like MindNode that wants to use Quicklook can provide a known and so somewhat seamless user experience. Search for Extensions in System Settings and then click on the Quick Look to see the non-Apple apps that use the Quick Look SDK.
These are loaded during plug-in discovery. When an app is opened, the plug-ins load and since they’re part of the /System/Library/ExtensionKit/Extensions or some other directory they can be dynamically loaded and exposed without consuming a ton of resources. There are tons of extensions. Some import graphical libraries and others allow developers to work with files more easily (e.g. com.apple.fileprovider-nonui in OneDrive), etc. In the Extensions screen of System Settings, click Finder extensions to see those that are loaded (including if it’s installed, OneDrive). Sharing sheets, Notifications, Photo Editing, and others can be seen in Extensions as well. Most (although not all) will require users to explicitly grant access to the necessary resources to load.
System Extensions are a replacement for kernel extensions and are typically used to change the way the system responds to various events. Some have higher barriers of entry, such as individual meetings to make sure the power they give the developer isn’t used for unintended purposes. Another barrier of entry is that users can disable them and/or have to have them enabled via an MDM as a part of a command or profile. To see a list of active System Extensions, use the systemextensionsctl command with a list verb to see the running extensions:
systemextensionsctl listSome extensions also fall somewhere between what a System Extension might be used for and what app extensions are meant for. Some can be enabled programmatically, such as with:
pluginkit -e use -I io.secretchest.SecretChest.CredentialProvider-macOS(1.0)Many cannot. One of these is the Credential Provider extension, which is why the above command would fail when run on Secret chest. These are managed by PluginKit, the pluginkit command can be used to see them loaded and provide metadata about them. For example, rather than use the Privacy & Security System Settings -> Extensions to see the Password AutoFill, we can check the status with pluginkit (which resembles Jorge but for extensions instead of hardware).
The command to see this information would be pluginkit with some switches – for example, the following shows all extensions:
pluginkit -mAvvvA quick find in Terminal shows the CredentialProvider along with where the .appex bundle is located:
+ io.secretchest.SecretChest.CredentialProvider-macOS(1.0) Path = /Applications/SecretChest.app/Contents/PlugIns/CredentialProvider-macOS.appex
UUID = D68B78DF-8806-4AF5-B73F-389A6A95F2FB Timestamp = 2024-01-05 16:26:46 +0000
SDK = com.apple.authentication-services-credential-provider-ui
Parent Bundle = /Applications/SecretChest.app
Display Name = SecretChest
Short Name = SecretChest
Parent Name = SecretChest
Platform = macOSThe CredentialProvider is managed by the CredentialProviderExtensionHelper and the AppleCredentialManagerDaemon. The PluginKit binary is pkd (invoked by launchd and if all is well consuming less than maybe a dozen megs of memory).
Inside the CredentialProvider.appex bundle there is an info.plist with metadata about the credential provider and any app that loads an extension should have a corresponding /Applications/SecretChest.app/Contents/_CodeSignature/CodeResources file that lists the extensions loaded:
cat /Applications/SecretChest.app/Contents/_CodeSignature/CodeResourcesHere, there are keys for resources and plugins loaded. That credential provider is then loaded in user space at ~/Library/Application Support/com.apple.AuthenticationServices/CredentialProviders (which SIP protects from reads). A network provider (e.g. what’s used by most ZTNA solutions) might show com.apple.networkextension.packet-tunnel and so looking for whether that’s loaded can net a way to programmatically derive the state of those by bundle ID. Unlike kernel extensions, these are imported and exposed as well-documented APIs for developers. To interrogate extensions (rather than walk through info plists and the like:
pluginkit -m -v -I io.secretchest.SecretChest.CredentialProvider-macOS(1.0)Note: Most of this also applies to iOS simulators but you can’t really get to it on a running device.
Some of these require entitlements. To see a list of entitlements for many of these, see Jonathan Levin’s entitlement database at: http://newosxbook.com/ent.jl?osVer=MacOS15. It doesn’t include which third parties have access to entitlements but does lay out how Apple uses many internally.