disable USB or USB Mass Storage Devices

[jmanprasert]

Now that Apple deprecated the Disable of External Disks feature in their MDM framework with the release of Big Sur so this no longer functions as it did in previous versions on MacOS, has anyone been able to disable USB or USB Mass Storage Devices? I tried writing a script that unloaded the IOUSBMassStorageDriver.kext but that did not work. My company cannot have any flash drives connected to their macs but i cannot seem to get it to work. Any suggestions? We have about 50 2015 macs and the rest are 2019 USB-C macs.

[ljcacioppo]

There are third party products that can do it, such as CrowdStrike. I am not familiar with a method to do it now without a DLP or endpoint security product though.

[mm2270]

Yeah, you'll pretty much need to use a DLP product to get this now. We're using McAfee where I am (much to my chagrin). It does the job of blocking USB and other connected drives, but McAfee as a whole is not a great product on the Mac. Plus, it lacks some important true DLP features like web upload protection. So I'd advise looking at some other product for DLP if you need to go that route.

[fperry]

I went down a rabbit hole, but I think I found a way to leverage JAMF config profiles. I got my idea from this article.

Ventura - Allow accessories to connect (USB Type-C... - Jamf Nation Community - 276823

I followed the JAMF PRO feature request in the article above and that led me to a place where I could look up options to configure restrictions on a device.

Restrictions | Apple Developer Documentation

I found one for allowFilesUSBDriveAccess. true/false.
Leveraging true/false in the command below will allow you to create a config profile in the upload section of Application & Custom Settings.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>allowFilesUSBDriveAccess</key>
        <false />
    </dict>
</plist>

 I tested on two different macs that had ventura 13.2 and this worked for me. To undo this action, I created the same config profile with true. Once I logged out and in again, I could use USB drives. I know enough to be dangerous so if anyone wants to try this, please test on a test mac first. Based on some findings, this may only work for Ventura 13.1 and greater. I haven't tested this on any other builds. 

[howie_isaacks]

I like this. I keep getting requests from our customers to do this. Jamf Pro has the notification next to the settings that this has been deprecated. So has the function that Jamf is using been deprecated then? According to the developer documentation it's not actually deprecated.

[bwoods]

Quick question, did you test this on Intel or ARM? I can't seem to get it to work. Also, are you using "com.apple.applicationaccess" for your preference domain?

[fperry]

Yes. to both

The 2 macs originally tested were for intel and M1 and the preference domain is com.apple.applicationaccess.

It may be that this only works for certain versions of ventura? Are you on the latest version? I haven't retested on OS13.2.1, but I can't imagine that would be making a difference.

[bwoods]

I Tested on 13.2.0. I'm gonna give it another shot today. Thanks.

[mm2270]

The link to the Apple documentation lists this as being for iOS, not for macOS. That doesn't mean it can't work on macOS, but it's possible that if it works, it's not really an intended outcome.

allowFilesUSBDriveAccess
boolean

If false, prevents connecting to any connected USB devices in the Files app. Requires a supervised device. Available in iOS 13.1 and later.

Default: true

[fperry]

I see multiple devices here. Mac OS 10.7+ is one of them with ipad, appletv and iOS

Restrictions | Apple Developer Documentation 

[mm2270]

That's only the top listing, which is going to list all the devices/OSes that are represented on that page, but the specific setting of allowFilesUSBDriveAccess only mentions being available in iOS 13.1 and later. Based on the description of 

If false, prevents connecting to any connected USB devices in the Files app.

Files.app is an iOS app, not something on macOS, so think is supposed to only be for iOS.

But really, if it works for you to block USB drive connections in macOS, that's great. I just don't think that was it's intention, so you might want to verify it still works after each OS update, since it could possibly break after one is installed.

[fperry]

I see what your meant. Thanks for the clarification and keeping me honest. I guess it is a little bit of a gamble to block in this way. I can confirm it has been working for me, but I will take your advisement and test with each update going forward. I have to check so many things already, so what's one more. :)

[Tim_DS]

If you do need a deep level of control over USB / peripheral ports - don't forget https://marketplace.jamf.com/details/endpoint-protector-by-cososys

 https://www.endpointprotector.com/solutions/device-control

Built for macOS so gives you the greatest control possible over peripheral ports, rather than just brute-force blocking. For example, allow iPhone to charge but don't allow data transfer; block Bluetooth (except for mouse / keyboard); only allow IT mandated removable media, and only to certain user groups.....etc, etc. 

Full transparency - I work for Endpoint Protector. 

[mickl089]

As long as the tool can be easily deleted by the user under macOS, I would look for a solution there first.

[fluffyhardy]

this was a great option and we've been using it for years at a secure location but the price rises are exponential at our upcoming renewal so we're now having to look elsewhere.

[chris_kemp]

Was looking into this just now, as a request came down from the PTB. I tested this profile on a 13.4 Mac and it didn't work. (Thanks, Apple...)

[david_maestre]

I'm running into the same issue. We have a profile in place to restrict iCloud settings and within the "Restrictions" panel I have External Drives unchecked. 

Now I have another profile specifically set for Block USB (external drives) too that can be scoped and excluded depending on who requires access. 

But now I'm running into an issue well maybe the 1st is conflicting with the 2nd on machines that are allowed USB access where their externals go dead. Whats the proper way to setup profiles so restrictions overlap properly and take precedence?

[jamf-42]

you can't block USB drives with a config profile in JAMF Pro.  Needs 3rp party product.. 

[david_maestre]

Well, it does still work. It's just not consistent anymore because it's deprecated. 

[cambam]

For those interested I made a script with that can be triggered by a launch daemon as a contingency for when the configuration profile stops working. It's not the most elegant solution but it seems to work for our data security needs. It also doesn't prevent drives from mounting. It just ejects them once they are mounted. I'm sure it has flaws in it but maybe it can be a starting point for someone else looking to accomplish something similar. If anyone has any suggestions on how to improve it I am all ears.

Here is a potential script:

#!/bin/zsh

#script to eject all external drives
disks=$(diskutil list external | awk '/physical/ {print $1}')

if [ -n "$disks" ]
then
echo "$disks" | while read line ; do
    diskutil eject $line
  done
else
  echo "No external disks to eject"
fi

Here is a potential launch daemon:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.company.mounteddrive</string>
    <key>UserName</key>
    <string>root</string>
	<key>ProgramArguments</key>
    <array>
    	<string>zsh</string>
    	<string>/path/to/script.sh</string>
    </array>
	<key>WatchPaths</key>
    <array>
        <string>/Volumes/</string>
    </array>
</dict>
</plist>

The launch daemon watches the volumes path for changes and runs the eject script when changes are made.

You'll have to change the /path/to/script.sh string in the launch daemon to the path to the script.

To load the launch daemon you'll have to change the permissions with something like the command below:

sudo chown root:wheel /Library/LaunchDaemons/com.company.mounteddrive.plist

sudo chmod 644 /Library/LaunchDaemons/com.company.mounteddrive.plist

Once the permissions are set you should be able to load the launch daemon with something like...

sudo launchctl bootstrap system /Library/LaunchDaemons/com.company.mounteddrive.plist

You'll also have to change the permissions of the script for the launch daemon to be able to run it with something like...

chmod 774 /path/to/script.sh

Those might not be the most secure permissions because everything will be living locally on the Mac but it may help you get a start.

Hopefully this helps as a good starting point for anyone else whose company needs stuff done but doesn't necessarily want to shell out the cash for a third party product.

Again, please feel free to suggest any improvements or just tell me why you think it wouldn't work.

Best regards,

Cameron

[dvasquez]

This is not working as when I try to start the launchdaemon I get the following errors.

The script alone does work when manually kicked off when an external drive is mounted, so that is good!

However, I am unable to have the daemon run successfully. Maybe there is a missing piece? The permissions have been properly set as well. 

Thank you.

[cambam]

Hi dvasquez,

I don't see the errors in your post. Are you seeing the launch daemon in list in terminal when you run the launchctl list command? Also, when I made this I tested it on Ventura and Sonoma. I haven't tested on Sequoia. Though, I don't think it should make a difference.

Best regards,

Cameron