So, you are getting slammed by your nonsensical InfoSec department with their irrational fears? You spend some time doing some research and you’re just so screwed! MacOS won’t let you remove httpd? You can’t block this or that? Who you gonna call? Workspace ONE to the rescue!

This week we turn our attention to something new. Sometimes in our world, the Agile development cycle can make some things slip between the cracks. New features coming out often and due to being busy or poor marketing they get missed. I was pleased to learn (with an assist from my friend Rob at VMware) that there is a new big-time feature available in Workspace ONE: App and Process Restrictions. With that being said, we will cover this briefly by discussing how to build the profile, deploying and seeing it in action.

The Components of App and Process Restrictions in Workspace ONE for MacOS

Apple’s Endpoint Security System Extension Framework can make some special things possible. They monitor system events to enable us to block software/processes from running on a MacOS device. You can use this for CLI tools, apps, utilities, and so much more.

To capitalize on this technology, you must meet a few basic requirements:

• Device on macOS 10.15+
• Workspace ONE Intelligent Hub 21.04+
• Systems Extension/Private Preferences payloads (Only if your environment is below WS1 UEM 2105)

Once you hit those, you can easily set things up. Let’s check out a short demo and then we’ll cover the pieces:

So that video shows you how it all comes together. Now, let’s explore the different aspects of deployment.

Creating the Systems Extension and Privacy Preferences Payloads

For those of us below WS1 UEM 2105, we will create these two basic payloads.

First, we have System Extension Profile:

Next, we have the Privacy Preferences:

As you can see they’re relatively easy to achieve. For those keeping score at home, the settings are:

##System Extension##
Team ID:S2ZMFGQM93
Bundle Identifier: com.vmware.hub.EndpointSecurity

##Privacy Preferences##
Identifier: com.vmware.hub.EndpointSecurity
Code Requirement: anchor apple generic and identifier "com.vmware.hub.EndpointSecurity" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = S2ZMFGQM93)

Allow System Policy All Files and Sys Admin Files

It’s just that simple. From here, we will move onto the XML setup.

Building the Custom XML Payload in Workspace ONE

Building the XML is a bit more difficult. Let’s explore different parts of the XML Payload.

The Base of the Payload

The Base of the Payload is simple as you can see below this is what facilitates things. We’ll explain it more below:

<dict>	
        <key>Restrictions</key>   <------------------- This opens up the payload
	<array> <-----------------This opens the array of settings
		<dict>
			<key>Attributes</key> <----------This contains the info used to identify what is being blocked
			<dict> <------Creates the dictionary of Attributes
</dict>   <--------Closes that dictionary
	<key>PayloadDisplayName</key>
	<string>Restricted Software Policy</string> <-----Signifies the name of the Payload
	<key>PayloadIdentifier</key>
	<string>HubSettings.5e43695c-d4f6-4d12-8790-0b7de67a1601</string> <-----The Payload Type+UUID to identify the Payload
	<key>PayloadOrganization</key>
	<string>Synterex</string> <-----Our Payload Org
	<key>PayloadType</key>
	<string>com.vmware.hub.mac.restrictions</string> <------The Payload Type
	<key>PayloadUUID</key>
	<string>5e43695c-d4f6-4d12-8790-0b7de67a1601</string> <-----Payload Unique ID
	<key>PayloadVersion</key> <-------Payload Version
	<integer>1</integer>
</dict>

The Attributes Dictionary

Now we can get into the different attributes and what they mean!

<dict>
				<key>cdhash</key> <-----Cdhash or code directory hash identifies the version of a program.
	<string>eafe9b1dd6f62abef044419330d1c071426370cf</string>
				<key>name</key> <-----name of the app bundle or process
				<array> <---This helps you set multiple items
					<string>Diskutil</string> 
				</array>
				<key>path</key> <-----the binary path of the application
				<string>/usr/sbin/diskutil</string>
                                <key>bundleId</key> <----the bundle ID of the application
                                <array>
                                <string>com.apple.DiskUtility</string>
                                </array>
                                <key>sha256</key> <----the SHA-256 hash of the application/item
				<string>a3a459093d5660bd37493c91e90f95445dae031cf6374a06e87a7d792498166b</string>
			</dict>
			<key>Actions</key> <----what action to take. Only block the process and display dialog is supported.
			<array>
			<integer>1</integer>
			</array>
			<key>Message</key> <------The message displayed upon blocking
			<string>You are not permitted to use DiskUtil</string>
		</dict>

##Note##

There is one key supported I didn't use because I think its useless and thats "IsSilentNotify" which is a boolean you can use to block the action without a message. I think telling users that their action is restricted is good form and good user experience, but that's up to you.

Bringing it All Together

When you combine the great work in those previous sections, you get a nice full custom XML to deploy to your users:

<dict>
	<key>Restrictions</key>
	<array>
		<dict>
			<key>Attributes</key>
			<dict>
				<key>cdhash</key>
	<string>eafe9b1dd6f62abef044419330d1c071426370cf</string>
				<key>name</key>
				<array>
					<string>Diskutil</string>

                                        <string>com.apple.DiskUtility</string>
				</array>
				<key>path</key>
				<string>/usr/sbin/diskutil</string>
			</dict>
			<key>Actions</key>
			<array>
			<integer>1</integer>
			</array>
			<key>Message</key>
			<string>You are not permitted to use DiskUtil</string>
		</dict>
	</array>
	<key>PayloadDisplayName</key>
	<string>Restricted Software Policy</string>
	<key>PayloadIdentifier</key>
	<string>HubSettings.5e43695c-d4f6-4d12-8790-0b7de67a1601</string>
	<key>PayloadOrganization</key>
	<string>Synterex</string>
	<key>PayloadType</key>
	<string>com.vmware.hub.mac.restrictions</string>
	<key>PayloadUUID</key>
	<string>5e43695c-d4f6-4d12-8790-0b7de67a1601</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>

Let’s check out my video in action of building that custom XML and sleuthing our way to filling out the XML:

Final Thoughts

Well here we are at the end, This isn’t one of my longer articles, but It is a very useful one nevertheless. Truthfully, many companies who follow BSCs and other similar security benchmarks will throw stuff at you which is difficult to solve on MacOS. This new capability from VMware leveraging Apple Security Frameworks should empower you to deliver a dynamic and secure MacOS experience that we can feel confident about. My hope is this will hit the GUI very soon because custom XML profiles are a struggle for many, but hopefully with my tutorials it will be a bit easier. My new article should be the perfect compliment to my many MacOS articles to help you fight the good fight with Workspace ONE!