We are looking for a solution (API, Frameworks) that would allow us to block any type of external device, including storage devices, HIDs, network adapters, and Bluetooth devices according with dynamic rules that comes from management server . This feature is important for endpoint security solutions vendors, and it can be implemented on other platforms and older versions of macOS using the IOKit framework and kexts. I have found one solution that can control the usage only of "storage" devices with the EndpointSecurity framework in conjunction with the DiskArbitration framework. This involves monitoring the MOUNT and OPEN events for /dev/disk files, checking for devices as they appear, and ejecting them if they need to be blocked.. Also, I have found the ES_EVENT_TYPE_AUTH_IOKIT_OPEN event in EndpointSecurity.framework, but it doesn't seem to be useful, at least not for my purposes, because ES doesn't provide AUTH events for some system daemons, such as configd (it only provides NOTIFY events). Furthermore, there are other ways to communicate with devices and their drivers apart from IOKit. DriverKit.framework does not provide the necessary functionality either, as it requires specific entitlements that are only available to certain vendors and devices. Therefore, it cannot be used to create universal drivers for all devices, which should be blocked. Any advice would be greatly appreciated!

Starting with macOS Sequoia Beta, a new "Local Network Privacy” feature was introduced, which had previously been present in iOS. Unfortunately, there is little information about this topic on the Apple developer website, especially for the macOS platform. I conducted some experiments to understand the new feature, but was confused by the results. Firstly, I noticed that the type of application accessing the local network in macOS matters - bundled or command-line (CLI) applications. The TCC subsystem does not restrict access to the local network for CLI applications at all, regardless of how they are launched - as a launchd daemon with root privileges, or through a terminal with standard user privileges. At the same time, access to the local network for bundled applications is controlled by the TCC subsystem at most cases. Upon the first request, the system will display an alert to the user explaining the purpose of using the local network. Then, communication with local network devices will be allowed or restricted based on whether consent has been granted or revoked. Secondly, it's worth noting that if the bundled application supports CLI mode (launched through the terminal without a GUI), it will be able to access the local network in that mode regardless of the “Local Network Access” consent state if it has been granted at least once. However, if the same application is in GUI mode, its access to the local network will be limited by the current consent. Is this behaviour correct and likely to remain the same in future releases of macOS Sequoia? Or is there something described here that is incorrect and will be fixed in the upcoming betas? Also, I have posted FB14581221 on this topic with the results of my experiments.

Starting with macOS 15, the Local Network Privacy (LNP) feature has been introduced, which has been available on iOS for some time. We are developing an enterprise application for remote control and protection of corporate devices. The management is carried out using a dedicated server, usually located on the internal LAN of the enterprise. In order to interact with this server, devices require access to the local network, which is managed by the new TCC LNP. The UX of our application involves minimal user interaction. To address this issue, we use Apple's MDM to automatically grant various permissions. Additionally, we have scripts for remotely installing the application and configuring it. However, for the new TCC LNP, we have not found a way to do this through the MDM profile. Does Apple intend to incorporate the relevant functionality into the MDM? There are several posts on the dev forum about this topic, but they are all about iOS.