Location permissions for a System Extension

Question

Hello!

Is it possible to add location permissions to a macOS system extension?

We have a network firewall system extension that also considers WIFI connections in its rules. With the release of Sonoma, interface information is only accessible while having location permissions, which we are having trouble asking for.

We have the entitlements, the usage description, but the authorizationStatus of CLLocationManager stays at .notDetermined and no window for location permission pops up after calling requestAlwaysAuthorization().

What we need is to get the SSID of the network that the interface is connected, its security and encryption type. If the permission is not possible, is there a workaround?

Cheers

739

Posted by

rapidSquirrel

Reply

Add a Comment

Answer 1

I talked with DTS’s Core Location expert about your problem. The Core WLAN side of this is straightforward: See the Apple Recommended post on this thread. So this boils down to a Core Location issue: Is it possible for a system extension to get the Core Location privilege?

My understand is that it is not. A sysex is effectively a launchd daemon and daemons can’t get the Core Location privilege.

The only workaround I can suggest is to install a global launchd agent to do this work on the daemon’s behalf. This is less than ideal:

It makes everything more complicated.
The modern way to install agents, SMAppService, does not support global launchd agents. See this thread.
Each instance of the agent is ‘owned’ by the user associated with that login session, and thus the user could potentially interfere with its operation.

If you’d like to see this improve, I encourage you to file an enhancement request explaining your requirements and why this is causing you such grief. Make sure to file this against Core Location, because this is an issue that affects all parts of the system where Core Location is involved.

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"

Posted by

eskimo

Add a Comment

Answer 2

What we need is to get the SSID of the network that the interface is connected, its security and encryption type

You could try using fetchCurrentWithCompletionHandler to see if this provides you more information in the context of your firewall, but if it doesn't you may have to look to your container app to get this information under one of these conditions:

 * @method fetchCurrentWithCompletionHandler:completionHandler:
 * @discussion This method returns SSID, BSSID and security type of the current Wi-Fi network when the
 *   requesting application meets one of following 4 requirements -.
 *   1. application is using CoreLocation API and has user's authorization to access precise location.
 *   2. application has used NEHotspotConfiguration API to configure the current Wi-Fi network.
 *   3. application has active VPN configurations installed.
 *   4. application has active NEDNSSettingsManager configuration installed.
 *   An application will receive nil if it fails to meet any of the above 4 requirements.
 *   An application will receive nil if does not have the "com.apple.developer.networking.wifi-info" entitlement.
 * @param completionHandler A block that will be executed when current Wi-Fi network details are
 *   obtained from the system. The NEHotspotNetwork object passed to this block will be nil if the requesting
 *   application fails to meet above requirements, non-nil otherwise. NEHotspotNetwork object contains only valid
 *   SSID, BSSID and security type values, when the block is passed non-nil object.This block is executed on application's
 *   main queue.

Posted by

meaton

Add a Comment

Answer 3

Hello, this seems like an iOS API. We are on macOS, will it help us?

Posted by

rapidSquirrel

Add a Comment

Answer 4

I talked with DTS’s Core Location expert about your problem. The Core WLAN side of this is straightforward: See the Apple Recommended post on this thread. So this boils down to a Core Location issue: Is it possible for a system extension to get the Core Location privilege?

My understand is that it is not. A sysex is effectively a launchd daemon and daemons can’t get the Core Location privilege.

The only workaround I can suggest is to install a global launchd agent to do this work on the daemon’s behalf. This is less than ideal:

It makes everything more complicated.
The modern way to install agents, SMAppService, does not support global launchd agents. See this thread.
Each instance of the agent is ‘owned’ by the user associated with that login session, and thus the user could potentially interfere with its operation.

If you’d like to see this improve, I encourage you to file an enhancement request explaining your requirements and why this is causing you such grief. Make sure to file this against Core Location, because this is an issue that affects all parts of the system where Core Location is involved.

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"

Posted by

eskimo

Add a Comment

Location permissions for a System Extension

Accepted Reply

Replies