Authorization-plugin: Invoke the Core Bluetooth APIs from the plugin

Question

Created Nov ’23

Replies 2

Boosts 0

Participants 2

Hello, is it possible to interact with a nearby device through Bluetooth LE, from the authorization plugin? Currently, I have:

a plugin bundle, registered with the authorization mechanisms;
a daemon that I have set up to contain all the business logic
added the com.apple.security.device.bluetooth entitlement to the daemon package, to allow Bluetooth communication;
registered the daemon through LaunchDaemons so that it is managed by launchd And I'm using XPC to communicate between the plugin and the daemon.

When I send the request to the daemon to scan for peripherals, I get a TCC error: 0xd5a Error 0x23e5 161 0 tccd: [com.apple.TCC:access] Refusing TCCAccessRequest for service kTCCServiceBluetoothAlways from client Sub:{...} in background session

The above error seems to suggest that I can't grant the bluetooth permission from the daemon itself, is there a recommended way to grant permissions before running it? And if granted, would I be able to utilize the framework successfully from the logon screen?

Other options I have tried:

Invoking the framework directly from the plugin, which failed. Probably because the Security agent process isn't entitled to communicate via Bluetooth and that it would require changing the host process entitlements plist, which I don't have access to? 🤔
Attempting to use a launch agent in lieu of a daemon, with proper entitlement, but that didn't work either. Probably because launch agents are loaded after the user has successfully logged in and I was invoking it before? 🤔
And lastly, I looked into the possibility of utilizing Privacy Preference MDM payload to grant access, but it seems like the MDM options do not include Bluetooth support.

Is there any other way to accomplish this?

Thank you!

Boost

Answer 1

DTS Engineer OP

Apple

Nov ’23

is it possible to interact with a nearby device through Bluetooth LE, from the authorization plugin?

Probably not, at least not on the latest systems.

You can’t do anything from your authorisation plug-in directly; it’s hosted by a system process so you have no control over your entitlements, Info.plist properties, TCC privileges, and so on.

The standard workaround is, as you’ve described, to do that work in a launchd daemon and have your authorisation plug-in talk to that daemon via XPC. However, this won’t work for Bluetooth on modern systems because there’s no way for the user to grant the Bluetooth TCC privilege to your daemon.

The next workaround is to move that work to a launchd agent and have the agent do the work on behalf of the daemon. However, I doubt that approach will work for you. Most folks with authorisation plug-ins are interested in the system.login.console right, and that necessarily happens before login, which means the user’s launchd agents aren’t running yet [1].

IMO you should file a bug requesting that we add a way to grant the Bluetooth TCC privilege to a third-party daemon.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] There is the concept of pre-login agents but those run as root and thus bump into the same restrictions as a launchd daemon.

0

Answer 2

dahlita OP

Nov ’23

Thanks Quinn for your reply and suggestion.

And I have filed a bug through the feedback assistant. Here's the bug number: FB13370068

(💡 Interesting about pre-login agents; is there any documentation somewhere I can consult?)

0