Application Definitions in Privilege Management for Mac

Application definitions allow you to target applications based on specific properties. When an application is executed, Privilege Management for Mac will query the properties of the application and attempt to match them against the matching criteria in the definition. If a match is made, then the rule is applied. If any of the matching criteria do not match, then neither will the definition, and Privilege Management for Mac will attempt to match against subsequent definitions in the Application Group.

Privilege Management for Mac will continue this process for subsequent Application Groups defined in Application Rules until a successful match is made and the rule is applied. If no matches are made, then no rule will be applied to the application, and it will run as normal.

Privilege Management for Mac must match every enabled criteria in an application definition you configure before it will trigger a match (the rules are combined with a logical AND).

Application definitions that require a match can also be negated. To target applications that do not match the definition, select does NOT match from the dropdown.

Application Definition Matching Criteria

Many of the matching criteria below support using wildcards such as the asterisk (*). Care must be taken when using these wildcards, as misuse can lead to undesirable behavior, such as blocking or elevating all applications.

All matching criteria are case sensitive on macOS.

Application Requests Authorization

The application requires authorization so you need to approve that request - anything in macOS that has a padlock on the dialog box or where the system requires authorization to change something. You can match on the Auth Request URI, which is unique to the application.

When an application triggers an authorization request, the application will use a unique Auth Request URI. This URI will differ from the URI of the application. This matching criterion allows you to target any authorization request and apply your own controls by matching the Auth Request URI.

This matching criterion 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 criterion 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 criterion can be used with the following application types:

• Binaries
• Bundles
• Packages
• System Preferences

Command Line Arguments

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

The Command Line Arguments matching criterion will match specifically the arguments passed to the binary, script or sudo command.

MyMac:~ standarduser$ ls -la /Applications

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/sudo command and 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 criterion 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 criterion includes the following matching options:

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

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

• Binaries
• Scripts
• Sudo Commands

You can match on any command line argument with the exception of those listed in Mac Command Arguments Not Supported.

Delete Action Match

This criterion allows you to delete from the /Applications folder on a macOS system.

This matching criterion can be used with the Bundle application type.

File or Folder Name Matches

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

This matching criterion 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 recommend that 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 (wildcard characters ? and * may be used):

• 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 that unsigned applications are not run. Instead, we recommend you run applications from the /Applications/ folder.

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

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

File Hash (SHA-1 Fingerprint)

This definition ensures that 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 an application binary, script, or bundle. Changing the contents of an application will result in an entirely different hash. Every application, and every version of the same application, has a unique hash. 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 criterion, as it can be used to ensure that the application being run is the exact same application that was used when creating the definition, and that it has not been modified.

This matching criterion includes the File Hash matching options.

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

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

Although File Hash is the more reliable matching criterion for matching a specific application, you must ensure that 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 will also have different SHA-1 hashes.

File Hash (SHA-256 Fingerprint)

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>

File Version matches

If the application you entered has a File Version property, it is automatically extracted and you can choose to Check Min Version, Check Max Version, and edit the version number fields.

For application types that have defined versions, you can optionally use the File Version matching criterion 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 its 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 criterion includes the following matching options:

• File Min Version
• File Max Version

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

• Bundles
• System Preferences

Install Action Match

This criterion allows you to install to the /Applications folder on a macOS system.

This matching criterion can be used with the Bundle application type.

Parent Process Matches

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/child hierarchy for the application, looking for any matching parent process, whereas 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 the parent process will be launched. However, sometimes applications like binaries and bundles are executed by other applications.

For example, binaries like curl can be executed from the Terminal, and will be created as a child of the user's shell, for example, bash. However, curl can also be used by applications.

The Parent Process matching criterion allows you to the target applications based on their parent process, so that 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 that you can identify multiple parents without having to create multiple definitions. This also means that the parent process can be defined as any type of application (binary, bundle, script, system preference or package), using any of the relevant matching criteria for each application.

This matching criterion includes the Parent Process Group matching option (dropdown menu of all Application Groups that exist in the configuration).

This definition can be used with the following application types:

• Binaries
• Bundles
• Sudo Commands
• Scripts

Publisher Matches

This option can be used to check for the existence of a valid publisher. If you browse for an application, then the certificate subject name is automatically retrieved, if the application is 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, guaranteeing that the application is genuine and from a specific vendor. The certificate also ensures that 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.

If you want to check if an application has been digitally signed, and what the certificate authorities are, use the Codesign command.

Codesign -dvvv /Applications/iTunes.app/

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 the example, you can see that Apple uses the certificate authority Software Signing to digitally sign iTunes.app.

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

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 criterion 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

Source

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 Privilege Management for Mac at the point it is downloaded, therefore 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

URI

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

The URI matching criterion 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 criterion 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 (wildcard characters ? and * may be used):

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

This definition can be used with the Bundles application type.