bluetooth control

Reordering things for clarity:

I searched google and found out that I can use CoreBluetooth to control bluetooth. But when I get connected to bluetooth keyboard or mouse, didConnectPeripheral dose not get called or when I call [central cancelPeripheralConnection:peripheral] disconnection never happens.

CoreBluetooth is specifically for BLE (Bluetooth Low Energy) or GATT (Generic Attribute Profile) devices, which is not how most keyboards or mice function.

I am learning about endpoint security and other system extensions, while I was handling ES_EVENT_TYPE_AUTH_IOKIT_OPEN event I realized that I cannot auth deny any bluetooth events.

Sort of. The issue here is that "ES_EVENT_TYPE_AUTH_IOKIT_OPEN" specifically applies when a user space process attempts to open an IOKit service, typically connecting through a user client. The problem is that for many device types, that user client is probably not "bluetooth specific". For example, looking at my own machine, I could block the magic mouse by denying "AppleMultitouchDeviceUserClient", but I'd have "know" in advance that this was a driver I should be blocking. This is further complicated by the fact that you don't really get a lot of information inside ES_EVENT_TYPE_AUTH_IOKIT_OPEN- for example, you can't really correlate the connection request back to the object it originates from.

Is there any recommendation for handling or controlling events related to bluetooth connection?

What are you actually trying to block/prevent?

Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for the reply.

What are you actually trying to block/prevent?

I'm working on an app that offers users a distinct environment, with limitations on Mac machine access. This app is tailored for Macs destined for museum exhibits or pop-up stores. It enables specific applications or connections to designated Bluetooth or USB devices.

I'm currently stuck at the Bluetooth part, aiming to restrict users from connecting unauthorized devices to the Mac machine.

but I'd have "know" in advance that this was a driver I should be blocking

I plan to achieve this by implementing such as a whitelist feature, allowing only pre-approved devices to establish Bluetooth connections.

Do you have any recommendations to achieve this feature?

I'm working on an app that offers users a distinct environment, with limitations on Mac machine access. This app is tailored for Macs destined for museum exhibits or pop-up stores. It enables specific applications or connections to designated Bluetooth or USB devices.

How are you planning on the machine being used? There is a HUGE difference between wants possible in a "general use" configuration (Finder, apps, etc. are all available) and a "kiosk" configuration (where you're only going to allow specifics things to run and nothing else).

In "kiosk" applications the typical approach to this sort of issue it to side step the entire problem by preventing the user from ever getting to the interface element that would have allowed the interface "process" to start. In concrete terms, it's REALLY hard to pair a bluetooth device if:

-You can't open system preference because you're never given access to that menu.

-You can't open things through the Finder, because the Finder isn't running*.

-You can't search for things because spotlight isn't there.

-Etc.

One thing to understand here, particularly if you're coming from iOS, is that macOS Kiosk's are FAR less "API driven" than an iOS device would be. For example, if you don't want the Finder to be available then you can just "turn it off" using launchctl to configure launchd*. The big point here is that a macOS kiosk are setup and managed as part of the larger login account configuration, not just "as an a app".

I'm currently stuck at the Bluetooth part, aiming to restrict users from connecting unauthorized devices to the Mac machine.

I plan to achieve this by implementing such as a whitelist feature, allowing only pre-approved devices to establish Bluetooth connections.

Do you have any recommendations to achieve this feature?

Again, this is all about the larger "picture" of how this is going to be used. If you're constraining the larger interface, then this is relatively straightforward Kiosk design. I broad terms, you setup your kiosk configuration so that it can be "locked/unlocked" and you only allow access to the the bluetooth pairing interface when kiosk is unlocked.

In the "general usage" case.... Honestly, I can think of any "clean" way to do it. If you REALLY want to do this in the general case then I can give it some more thought, but that's a MUCH harder case than a kiosk would be.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware