I'm trying to restore an APFS volume to its previous state using a snapshot created with the tmutil command. The only native Apple tool I've found for this purpose is apfs.util. According to the documentation, the correct command for this task is /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -R </dev/diskXsY>. However, this command is not working for me. It returns the error "No such file or directory" for any existing . If I use a valid file/dir path instead of the as an experiment, I get an "Invalid argument" error. To investigate the issue, I decided to debug apfs.util and found that the fsctl() function is responsible for these errors (ENOENT and EINVAL). The first argument passed to fsctl() is the (or file/dir path in my experiment), and the second argument is the value 0x80084A01, which corresponds to the APFSIOC_REVERT_TO_SNAPSHOT command according to xnu's source code (https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/vfs/vfs_syscalls.c#L174). It seems that this command is not supported by the latest versions of macOS (see https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/bsd/vfs/vfs_syscalls.c#L12984) and always returns EINVAL error. Is this correct? Are there any other tools available that can be used to revert APFS snapshots?

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 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.

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.