By Jon Xavier. Special thanks to Reyna Sparby and Aidan Mulrooney.

In macOS, the behavior of various types of media and drives is controlled by a subset of the com.apple.systemuiserver payload. Using this payload you can do things like restrict flash drives to read only mode, or prevent disk burners from operating. Since flash drives are a common virus vector, and also a great way to steal proprietary data, these controls are very useful for security.

We recently implemented these features as media management in Fleetsmith. However, as we worked on it, we noticed something strange—not everything behaved as expected. Apple’s documentation, in typical minimalist fashion, doesn’t offer much guidance beyond saying that all keys should work in all versions of macOS, something we found to be very much not the case. There did not seem to be any extant community documentation for these features, either.

All of which is to say that it took quite a bit of trial and error before we knew what we could and couldn’t do with media management. So that the community may benefit from our experience, we’re documenting that research publicly here.

Apple Media Management: an intro

Here’s how Apple describes the Media Management payload:

The profile configuration keys for media management are of two kinds: those that restrict disc burning and those that restrict media mounting and ejection. All keys are available on all versions of macOS and are supported on the user channel.

As Luke Skywalker says:

Alright, that’s a small exaggeration—but only a small one. There are actually three types of key, because in addition to disc burning, mounting, and unmounting, there’s another one that is meant to control what happens to media when a user logs out. And while all keys are certainly available in all versions of macOS, we’ve found that they behave differently in different versions, and in some cases they don’t work at all.

We’ll get into this next, as well as disc burning, which is a little more complicated than they suggest. For the time being let’s look at the media controls we have available:

  • logout-eject: Intended to control which devices are unmounted/ejected when a user logs out. Does not function as intended.
  • mount-controls: Controls whether media is allowed to mount when it’s inserted/plugged in.
  • unmount-controls: Controls whether a media type can be unmounted. Per the documentation, only combinable with authenticate or deny.

And these are the settings we can use:

  • authenticate: When this is set, will require the user to authenticate as an administrator before the media will mount.
  • read-only: Causes the media to mount in read-only mode.
  • deny: Prevents the media from mounting.
  • eject: Supposed to prevent the media from mounting and eject it automatically, if it is ejectable media. Apple’s documentation suggests that this might be less reliable than deny. In our tests, we found that this setting is actually implemented identically to deny by the latest versions of macOS, so there’s no reason to use it.
  • alert: We couldn’t find this documented anywhere, but there are some implementations we found that use it, so we decided to test it. It does not appear to do anything useful, but does cause a hanging error 100% of the time when applied to harddisk-external.

Finally, control can get very granular, because you can optionally provide a dictionary where the keys are media types and the values are a corresponding setting. Want to block users from watching DVDs but not Blu-rays? We’re not sure why you would, but it’s possible!

These are the media type keys we can use:

  • blankcd
  • blankdvd
  • blankbd
  • cd
  • disk-image
  • dvd
  • dvdram
  • bd (Blu-ray disc)
  • harddisk-external (USB disks, flash drives, etc. This is actually a catch-all for any storage device that’s not covered by another type.)
  • harddisk-internal
  • networkdisk
  • all-media Apple’s docs note this is not used and should be set to an empty string. This is true—we couldn’t find a configuration where this media type does anything at all.

What works and what doesn’t

We tried various keys with various controls and device types and found, essentially, that only mount-controls consistently does what it’s supposed to do. Even there, there are some differences between different media types and versions of macOS.

Here’s what we found:

10.13.6 Results
mount-controls read-only authenticate deny/eject alert
optical media, writeable N/A
optical media, written N/A
disk-image N/A
harddisk-internal
harddisk-external
networkdisk
all-media (deny)
unmount-controls
optical media, writeable N/A N/A
optical media, written N/A N/A
disk-image N/A N/A
harddisk-internal N/A N/A
harddisk-external N/A N/A
networkdisk N/A N/A
logout-eject
optical media—writeable N/A
optical media—written N/A
disk-image N/A
harddisk-internal N/A
harddisk-external N/A
networkdisk N/A
10.14.3 Results
mount-controls read-only authenticate deny/eject alert
optical media, writeable N/A
optical media, written N/A
disk-image N/A
harddisk-internal
harddisk-external
networkdisk
all-media (deny)
unmount-controls
optical media, writeable N/A N/A
optical media, written N/A N/A
disk-image N/A N/A
harddisk-internal N/A N/A
harddisk-external N/A N/A
networkdisk N/A N/A
logout-eject
optical media, writeable N/A N/A
optical media, written N/A N/A
disk-image N/A N/A
harddisk-internal N/A N/A
harddisk-external N/A N/A
networkdisk N/A N/A

Some notes on these tables:

  • All of these configurations require a device restart before they take effect.
  • All-media simply does not work, as suggested by the documentation. If you need to do something to affect all media, you will have to set all of the media types individually.
  • Network disk controls do not work. The problem here is a bad interaction between this mobileconfig and the way that shared drives work in macOS. Once a user connects to a shared drive, they will have whatever permissions were set by the host regardless of what the mobileconfig says. If the host/share has guest accounts enabled, guests are restricted to the host’s permission set, and read-only and authenticate do not work to bypass this. deny likewise does not deny access if it’s been allowed on the host/share. There’s one exception to this: in macOS 10.14.3, read-only does kind of work. Setting it on a network drive will prevent you from adding new files to the drive. However, if you have administrator privileges to the network drive, you can still delete and rename files. So it’s not a true solution if what you care about is restricting users from interacting with network entirely.
  • For disk images, authenticate functions similarly to deny. Although it will ask the user to authenticate when they try to mount a disk image, once authenticated the system complains that there’s no file system to mount to.
  • The one area that unmount-controls almost works is when used with deny. While it does prevent the user from unmounting a drive, it still pops up a dialog box asking if the user would like to force eject, so it will not actually accomplish its intended purpose.

Disc Burning

Apple’s media controls present us with three different ways to prevent disc burning:

  • You can use deny on writable optical media types, which will prevent those drives from mounting in the first place so they can be written to.
  • You can set com.apple.DiscRecording BurnSupport to disable to block in burn support, or authenticate to require an admin authentication first.
  • You can set com.apple.finder ProhibitBurn to true, which hides the option to burn a disk in the Finder.

Any one of these options will “block” disc burning. What’s not initially clear from Apple’s documentation is that you should do all three at once if you want to fully prevent disc burning. This is because setting just some of them will lead to weirdness from a user standpoint. Simply setting BurnSupport to disable without setting the others, for example, will still allow the disk to mount and still give users the UI for disc burning, but will cause an error if they try to do it.

Conclusion

Apple’s media management payloads do provide the functionality you’d need for security and compliance purposes, with a few quirks and caveats. There’s only a few let downs—it would be really nice if authenticate worked with disk images, for example. But if you know what you’re doing, they’re quite useful.

Hopefully, this overview gives you what you need to get the most out of media management with the fewest possible headaches!