EPM for Mac application definitions and types

The application requires authorization, so you need to approve that request. This applies to anything in macOS that has a padlock on the dialog box or where the system requires authorization to change something. The URIs are unique to the application. The Auth Request URIs are generic and any Auth Request URIs can be requested by any application.

When an application triggers an authorization request, the application will use a unique Auth Request URI. This URI will be different to the URI of the application itself. This matching criteria allows you to target any authorization request by matching the Auth Request URI, allowing you to target that specific Auth Request URI and apply your own controls.

This matching criteria can be used in combination with other criteria to target authorization requests from specific applications if more than one application uses the same Auth Request URI.

When this matching criteria is used in a definition, it will only match the authorization request of the application, and not the execution of the application. If you want to apply rules to both the application execution and application authorization request, then separate definitions must be created for each.

If you want to apply different rules to application execution and application authorization requests, then definitions must be added to different Application Groups and applied to different Application Rules.

Mac Packages are always configured to match exactly against the system.install.software request URI. You cannot set Auth Request URI or Perform Match Using options.

This matching criteria can be used with the following application types:

• Binaries
• Bundles
• Packages
• System Preferences

The Command Line Arguments matching criteria allows you to target a binary or sudo command based on the arguments passed to the command being executed on the command line. Command Line Arguments can be executed either through the Terminal, or through a script. With this matching criteria, you can apply a specific action (such as block, allow, or audit) to specific Command Line Arguments, rather than only applying actions to the use of the binary or sudo command.

The Command Line Arguments matching criteria will match specifically the arguments passed to the binary or sudo command. The following example shows a command for listing the contents of the /Applications directory:

MyMac:~ standarduser$ ls -la /Applications

• ls is the binary being executed, and is targeted by using the File or Folder Name matching criteria in a Binary definition.
• -la /Applications are the arguments being passed to ls, and is targeted by using the Command Line Arguments matching criteria in a Binary definition.

ℹ️

Note

Endpoint Privilege Management for Mac will only match the command line arguments, which will not include the beginning binary or sudo command being executed. If you want to match both the binary and sudo command, as well as the command line, then both the File or Folder Name and the Command Line Arguments matching criteria must be enabled and populated in the definition.

This matching criteria allows you to target all, or just parts of the command line being used. This is achieved by inserting wildcards into the Command Line Arguments string, defining which part of the command line you want to match, or by using a regular expression.

This matching criteria includes the following matching options:

• Command Line Arguments (for example, -la /Applications)
• Exact Match
• Starts With
• Ends With
• Contains
• Regular Expressions

This matching criteria can be used with the following application types:

• Binaries
• Scripts
• Sudo Commands

ℹ️

Note

You can match on any command line argument with the exception of those listed in macOS sudo command arguments not supported.

This matching criteria allows you to target applications based on their name / path on disk. It is an effective way of automatically allowlisting applications located in trusted areas of the filesystem (for example, /Applications or /System), and for targeting specific applications based on their full path.

This matching criteria can be used in combination with other criteria in a definition, giving you more granularity over which applications you can target based on their properties. Although you may enter relative file names, we strongly recommended you enter the full path to a file.

Applications can be matched on the file or folder name. You can choose to match based on the following options:

• File or Folder Name (for example, /Applications/iTunes.app)
• Exact Match
• Starts With
• Ends With
• Contains
• Regular Expressions

You can match on the file path containing or starting with the /AppTranslocation/ folder, however we recommend you block all applications attempting to run from this location to ensure unsigned applications are not run. Instead, we recommend you run applications from the /Applications/ folder.

ℹ️

Note

Targeting bundles with an Exact Match path applies only to the main binary in the Contents/MacOS directory as specified in the bundle's plist.

This matching criteria can be used with the following application types:

• Binaries
• Bundles
• Packages
• System Preferences
• Sudo Commands
• Scripts

This definition ensures the contents of the application (which can normally be edited by any user) remain unchanged, as changing a single character in the script will cause the SHA-1 hash to change.

A file hash is a digital fingerprint of an application, generated from the contents of application binary or bundle. Changing the contents of an application results in an entirely different hash. Every application, and every version of the same application, has a unique hash. Endpoint Privilege Management for Mac uses hashes to compare the application being executed against a hash stored in the configuration.

File hash matching is the most specific criteria, as it can be used to ensure the application being run is the exact same application used when creating the definition, and that it has not been modified.

This matching criteria includes the following matching options:

• File Hash

This matching criteria can be used with the following application types:

• Binaries
• Bundles
• Packages
• System Preferences
• Sudo Commands
• Scripts

ℹ️

Note

Although file hash is the more reliable matching criteria for matching a specific application, you must ensure definitions are kept up to date. When updates are applied to the endpoint, new versions of applications may be added, and so their SHA-1 hashes will be different. Applications on different versions of macOS also have different SHA-1 hashes.

Changes to file hash auditing

Prior to version 21.6, the file hash audited depends on the context, for example, whether the application is a bundle or whether it’s code signed:

• Signed applications report the code directory hash (CDHash).
• Unsigned single files (binaries, scripts) and signed packages report a SHA-1.
• Unsigned bundles report a recursively generated SHA-1 of all their contents. In a worst case scenario, this can take several minutes to generate.

In version 21.6, what is audited is simplified to provide support for reputation services such as VirusTotal:

• Single files report a SHA-1.
• Bundles report the SHA-1 of their main binary, as specified by their Info.plist.

Changes to file hash matching criteria

Support for matching signed applications using their CDHash is continuing, and we also now support matching against the audited SHA-1.

Support for recursive SHA-1 matching for unsigned bundles will be removed once Apple Silicon is widely adopted by businesses, as unsigned code is not allowed to run on these devices. It can cause significant performance issues.

How to determine a file’s hash for matching criteria

If you have audit events available through reporting, then you can find the appropriate SHA-1 file hash there. This is not as secure as using a CDHash for bundles.

Signed application (bundle, binary, script):

codesign -dvvv <path to bundle or file> 2>&1 | egrep "^CDHash"

Unsigned files (binary, script) and both signed and unsigned packages:

shasum -a 1 <path to file>

Unsigned bundle:

shasum -a 1 <path to bundle’s main binary>

Set the SHA-256 file hash on an application. The SHA-256 hash is supported on all appropriate macOS applications. On the macOS operating system, you can select match. The does NOT match setting is not available on macOS. We recommend using SHA-256 rather than SHA-1.

How to determine a file’s hash for matching criteria

If you have audit events available through reporting, then you can find the appropriate SHA-256 file hash there. This is not as secure as using a CDHash for bundles.

Unsigned files (binary, script) and both signed and unsigned packages:

shasum -a 256 <path to file>

Unsigned bundle:

shasum -a 256 <path to bundle’s main binary>

If the application you entered has a File Version property, then it is automatically extracted. You can choose to Check Min Version, Check Max Version, and edit the version number fields. Alphanumeric characters are supported in the version of applications.

For application types with defined versions, you can optionally use the File Version matching criteria to target applications of a specific version or range of versions. This allows you to apply rules and actions to certain versions of an application, for example, blocking an application if it’s version is less than the version defined in the definition.

File Version matching can be applied either as a minimum required version, as a maximum required version, or you can use both to define a range of versions (between a minimum and a maximum).

This matching criteria includes the following matching options:

• File Min Version
• File Max Version

This matching criteria can be used with the following application types:

• Bundles
• System Preferences

This option can be used to check if an application’s parent process matches a specific Application Group. You must create an Application Group for this purpose or specify an existing Application Group in the Parent Process group. Setting match all parents in tree to True will traverse the complete parent and child hierarchy for the application, looking for any matching parent process. Setting this option to False only checks the application’s direct parent process.

When a new application executes, it is executed by another process, or parent process. In most cases on macOS, the parent process will be launchd. However, sometimes applications like binaries and bundles are executed by other applications. For example, binaries like curl can be executed from Bash, and will be created as a child of the Terminal process. However, curl can also be used by applications.

The Parent Process matching criteria allows you to the target applications based on their parent process, so you can apply different rules and actions depending on where the application is being executed from. In the example above, you can use Parent Process matching to allow curl to be used by an authorized application, but still block users from executing it directly in the Terminal.

Parent Processes are defined as an Application Group, so you can identify multiple parents without having to create multiple definitions. This also means the parent process can be defined as any type of application (binary, bundle, system preference, or package) using any of the relevant matching criteria for each application.

This matching criteria includes the following matching options:

• Parent Process Group (dropdown menu of all Application Groups existing in the configuration)

This definition can be used with the following application types:

• Binaries
• Bundles
• Sudo Commands
• Scripts

This option can be used to check for the existence of a valid publisher. If you have browsed for an application, then the certificate subject name will automatically be retrieved, if the application has been signed. By default, a substring match is attempted (Contains). Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a Regular Expression. The available operators are identical to the File or Folder Name definition.

Some applications are digitally signed with a certificate, giving a guarantee the application is genuine and from a specific vendor. The certificate also ensures the application has not been tampered with by an unauthorized source. The vendor who owns the certificate can be identified from certain properties of the certificate, which are referred to as Authorities. A certificate typically contains several Authorities linked together in a chain of trust.

To check if an application has been digitally signed and what the certificate Authorities are, use the following command example to check the certificate of the iTunes.app application bundle:

Codesign -dvvv /Applications/iTunes.app/

If the application has a certificate, there will be one or more Authorities listed in the output:

Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA

In the output, the first Authority listed is the authority most specific to the application. In this example, you can see Apple uses the certificate Authority Software Signing to digitally sign iTunes.app.

With the Publisher matching criteria, you can target applications based on the publisher information contained in its certificate. This matching criteria can also be used in combination with other matching criteria, as a way of ensuring the application is a genuine application from the vendor.

ℹ️

Note

All apps downloaded from the Apple Store will have certificates with the same authority, as Apple resigns all applications before making them available in the Apple Store.

This matching criteria includes the following matching options:

• Publisher (For example, the Publisher for Apple applications is Software Signing)
• Exact Match
• Starts With
• Ends With
• Contains
• Regular Expressions

This definition can be used with the following application types:

• Binaries
• Bundles
• Packages
• System Preferences
• Sudo Commands

If an application was downloaded using a web browser, this option can be used to check where the application or installer was originally downloaded from. The application is tracked by Endpoint Privilege Management for Mac at the point it is downloaded, so if a user decided to run the application or installer at a later date, the source can still be verified. By default, a substring match is attempted (Contains). Alternatively, you can choose to pattern match based on either a wildcard match (? and *) or a Regular Expression. The available operators are the same as the File or Folder Name definition.

This definition can be used with the following application types:

• Bundles
• System Preferences

Every macOS application bundle has a defined Uniform Resource Identifier (URI), a property that uniquely identifies the application to the system. URI’s follow a specific structure, typically referencing the vendor and application. For example, the URI for Apple iTunes is com.apple.iTunes.

The URI matching criteria provides an effective way of targeting applications where the filename or file path may not always be known. It is also an effective way of targeting applications from a specific vendor.

This matching criteria can also be used in combination with other matching criteria, as a way of ensuring the application is a genuine application from the vendor.

This is the Unique Request Identifier for the application bundle. You can choose to match based on the following options:

• URI (for example, com.apple.iTunes)
• Exact Match
• Starts With
• Ends With
• Contains
• Regular Expressions

This definition can be used with the following application types:

• Bundles

Use to allow installation of bundles to the /Applications directory. This matching criteria can be used in combination with other criteria to allow or deny installation of the matched bundle.

You can choose from the following options to allow installation to the /Applications directory:

• Yes
• No

This definition can be used with the following application type:

• Bundles

This definition can be used to allow deletion of bundles from the /Applications directory. This matching criteria can be used in combination with other criteria to allow or deny deletion of the matched bundle.

You can choose from the following options to allow deletion from the /Applications directory:

• Yes
• No

This definition can be used with the following application type:

• Bundles

The current installation script for Homebrew must be modified slightly to work with Endpoint Privilege Management for Mac.

To achieve this, create a script that contains the following:

#!/bin/bash

# Download the latest brew install script using curl
curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh -o install.sh

# The following command modifies the install.sh script, creating a backup of the original
# as install.sh.bak, and does the following modifications
#  - replaces occurrences of "/usr/bin/sudo" with just "sudo" to allow customers using
#    the non-Apple sudo to continue
#  - Inserts a line "HAVE_SUDO_ACCESS=0" near the top of the file. This bypasses the
#    built-in have_sudo_access feature with the expectation that the PMFM plugin policy is
#    correctly configured to match this script

sed -i .bak -e $'s^set -u^set -u\\\nHAVE_SUDO_ACCESS=0^' \ 
    -e '/unset HAVE_SUDO_ACCESS/d' install.sh

source install.sh
                
rm install.sh
rm install.sh.bak

Check the shasum of the file you created to ensure no copy and paste irregularities have introduced differences.

To check the shasum of the script, run the following command in Terminal:

shasum -a 1 <name of script>

To create a rule to match this script in the Policy Editor:

1. Create an Application Group to add the script control.

2. Select Create New Application > Script.

3. Enter * as the file or folder name, as you're matching explicitly on hash.

4. Enter a description of User Homebrew Installation.

5. Set the File Hash to value <insert shasum here>.

   Ensure this file hash is the same as the script you prepared earlier, in case you made any custom modifications.

6. Click Create Application. The script is added to the Application Group.

In the same Application Group:

1. Click Create New Application > Sudo Command.

2. Enter * to represent any sudo command.

3. Enter a description or accept the default.

4. Configure the Parent Process to be the group which you are editing.

   This keeps the configuration of Homebrew isolated in the policy and easier to navigate. Alternatively, you can separate the Script and Sudo application definitions.

5. Click Create Application. The sudo command is added to the Application Group.

1. Select the Workstyle that is appropriately filtered for users you want to allow to install Homebrew.
2. Create an application assignment for the Application Group that contains the sudo command, of type Allow Execution, with your messaging and auditing preferences.