Big Sur - Unable to use Bluetooth in PC/SC IFD Handler plugin from within platform binary

Hi,

Our PC/SC IFD Handler plugin loaded and running inside of com.apple.ifdhandler system process stops working on BigSur because the TCC engine denies com.apple.ifdhandler access to bluetooth. Our IFD Handler communicates via BLE to the SmartCardReader.

Here the relevant messages from the log

AUTHREQATTRIBUTION: msgID=4121.1, attribution={responsible={identifier=com.apple.ifdreader, pid=4115, auid=0, euid=0, responsiblepath=/System/Library/CryptoTokenKit/com.apple.ifdreader.slotd/Contents/MacOS/com.apple.ifdreader, binarypath=/System/Library/CryptoTokenKit/com.apple.ifdreader.slotd/Contents/MacOS/com.apple.ifdreader}, requesting={identifier=com.apple.ifdbundle, pid=4121, auid=0, euid=0, binarypath=/System/Library/CryptoTokenKit/com.apple.ifdreader.slotd/Contents/XPCServices/com.apple.ifdbundle.xpc/Contents/MacOS/com.apple.ifdbundle}, },
standard 15:21:59.836608+0100 tccd AUTHREQSUBJECT: msgID=4121.1, subject=com.apple.ifdreader,
15:21:59.836956+0100 tccd Refusing TCCAccessRequest for service kTCCServiceBluetoothAlways from client Sub:{com.apple.ifdreader}Resp:{identifier=com.apple.ifdreader, pid=4115, auid=0, euid=0, responsiblepath=/System/Library/CryptoTokenKit/com.apple.ifdreader.slotd/Contents/MacOS/com.apple.ifdreader, binary_path=/System/Library/CryptoTokenKit/com.apple.ifdreader.slotd/Contents/MacOS/com.apple.ifdreader} in background session


We tried to add com.apple.security.device.bluetooth entitlement to our plugin and also we added NSBluetoothAlwaysUsageDescription and NSBluetoothPeripheralUsageDescription to its Info.plist file but nothing works

Does anyone know how to allow platform binary to access bluetooth? if not, all plugins written that runs inside of platform process will not be able to access bluetooth.
Up vote post of xenox Down vote post of xenox
2.7k views
Posted by
xenox
Reply
Add a Comment

Replies

Have you found a solution to this? I've running into same issue since Big Sur released, the error message I've got is like:

Refusing TCCAccessRequest for service kTCCServiceBluetoothAlways from client ... in background session

I've been searching around and haven't found a solution for this problem, like you said, if TCC can block bluetooth permission for platform binaries in the background session, all plugins need bluetooth access would stop working.

If we can't found solution from this forum, anybody knows where else could we look for help?
Posted by
XtalPeak
Up vote reply of XtalPeak Down vote reply of XtalPeak
Add a Comment
platform binaries running in background session is not owned by any user since they're running as root, are there any general guidelines on how TCC should work with system process. It's fairly clear now that user involvement is needed for TCC, but how does TCC work with system process? Anybody have an idea?
Posted by
XtalPeak
Up vote reply of XtalPeak Down vote reply of XtalPeak
Add a Comment

Does anyone have any insight on a possible solution? I'm experiencing the exact same issue

Posted by
ozmiz
Up vote reply of ozmiz Down vote reply of ozmiz
Add a Comment

Has there been any movement on this? It seems to be an issue with allowing Bluetooth systemwide. The UI will only add the permission for a user. It looks like we can add an entitlement to bluetoothd that will prompt the user for permission (see below), but I'm not entirely sure. Any insight would be much appreciated.

identifier=com.apple.bluetoothd, pid=124, auid=0, euid=0, binary_path=/usr/sbin/bluetoothd attempted to call TCCAccessRequest for kTCCServiceBluetoothAlways without the recommended com.apple.private.tcc.manager.check-by-audit-token entitlement

Otherwise, I'm seeing the same error when trying to access Bluetooth from a system service:

Refusing TCCAccessRequest for service kTCCServiceBluetoothAlways from client Sub:{REDACTED}Resp:{identifier=REDACTED, pid=14338, auid=0, euid=0, responsible_path=REDACTED, binary_path=REDACTED} in background session
Posted by
cspensky
Up vote reply of cspensky Down vote reply of cspensky
Add a Comment

It seems to be an issue with allowing Bluetooth systemwide.

This isn’t really my field but I can confirm that there’s a known issue in TCC when you try to use Bluetooth from a daemon context (r. 52528727). I’m not aware of any way to work around it.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

I'm guessing this is still an issue and still no workaround available? I have a similar use case that is holding me back. Weirdly on some user installs it works, and the daemon has permission to run, but others are unauthorised. There doesn't seem to be any pattern to why some installs work, and others don't. For instance we had a machine where it was working, had to upgrade and do a time machine restore on it, now it no longer works.

Posted by
eric_j
Up vote reply of eric_j Down vote reply of eric_j
Add a Comment

This is still not my field but I checked on the status of the above-mentioned bug and it’s not been resolved.

Weirdly

Yeah, that is weird. I’ve got nothing.

If this is critical to you, I recommend that you open a DTS tech support incident and one of us can dig into it.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • Thanks for following up Quinn, appreciate it.

    —
    eric_j
Add a Comment

Hi,

Do you have found a fix for this issue ? How do you manage to bypass this ?

Thank you for your help, Regards,

Posted by
AppleDevU2S
Post not yet marked as solved Up vote reply of AppleDevU2S Down vote reply of AppleDevU2S
Add a Comment