Hello.
Is there a legal way to block iOS devices from being mounted on macOS?
I noticed, that when an iOS device is connected, it pretends to be like a storage device but it is not. It not even going through diskArbitration. It seems that some fileProvider is taking place there.
I know that it is possible to do via the MDM profile:
<key>PayloadContent</key>
<dict>
<key>.GlobalPreferences</key>
<dict>
<key>Forced</key>
<array>
<dict>
<key>mcx_preference_settings</key>
<dict>
<key>ignore-devices</key> <true/>
</dict>
</dict>
</array>
</dict>
</dict>
But is there some programmatic solution?
If I use EndpointSecurity and block file operations for the usbmuxd process on /var folder, it prevents iOS devices from being mounted. But wouldn't be there any negative side effects from such a solution?
Hi,
Starting with "ignore-devices" preference, I don't think there is any programmatic way to replicate what it does. As far as I can tell all that is doing is setting a global preference which our internal components are then checking. There isn't really any way to duplicate that other than just setting the same preference value.
Next on this:
I noticed, that when an iOS device is connected, it pretends to be like a storage device but it is not. It not even going through diskArbitration. It seems that some fileProvider is taking place there.
Actually, it's a lot simpler than that. Nothing "mounts" at all, as there , the Finder is simply presenting a custom interface when the system detects an iOS device. The connection/communication doesn't involve the file system or any really "public" API (like FileProvider). That's also why it seems to be "hidden" from all the APIs you might normally think of (like DiskArb). It simply isn't going through any of them.
That leads to here:
Is there a legal way to block iOS devices from being mounted on macOS?
On thing to understand in the context of Endpoint Security (ES) is that the term "legal" doesn't really make sense. By defintion, you're block/altering/interferring with how the system would "normal" work, so nearly everything you do is changing how the system works. It's the ES client's job to understand the potential consequences and manage the changes you made. That's easy when you're dealing with "direct" behavior- denying a process access to a particular file means... that process won't be able to access that file. That may have other side effects, but at least there's a clear starting point and "failure" path.
However, things are a lot more complicated when you're talking about changing high level behavior (like how the Finder handles iOS devices), things are a lot more complicated. Some times there are simple/direct answers, but much of the time this simply isn't something the system has a clear way to block. If you still want to block it, then that's an investigation you'll need to take on yourself.
In terms of usbmuxd, I don't think we've ever talked about it publicly but it's also been talked about pretty broadly on the wider internet. As you've already figured out, it's a critical part of communicating with iOS device. What you're doing now obviously "works" (in the basic sense), however, my general advice here is that it's better/safer to disable a daemon like this entirely, instead of trying to target specific actions. Shutting it down entirely means you're more likely to find an side effects quickly and reduces the risk of creating subtle problems that you don't discover until much later. Keep in mind that if you decide to disable a daemon, don't just block it's launch with ES. Disable it using launchd so that the system doesn't keep trying to launch it.
-Kevin Elliott
DTS Engineer, CoreOS/Hardware
