macOS policies
A policy is built with the following optional components:
- Workstyles: A Workstyle is part of a policy. It's used to assign Application Rules for users. You can create Workstyles using the WorkStyle Wizard or by importing them.
- Application Groups: Application Groups are used by Workstyles to group applications together to apply certain Endpoint Privilege Management for Mac behavior.
- Messages: Messages are used by Workstyles to provide information to the end user when Endpoint Privilege Management for Mac has applied certain behavior you have defined and needs to notify the end user.
Note
- Using .MPKG (multiple package) format or launching multiple .PKG files at once is not supported and is blocked by Endpoint Privilege Management for Mac.
- Mac policies are not applied to the root user.
Workstyles
Workstyles are used to assign Application Groups for a specific user or group of users. The Workstyle wizard can generate Application Rules depending on the type of Workstyle you choose.
Create a workstyle
The Workstyle wizard guides you through the process of creating an Workstyle. The options you select determine the function of the Workstyle.
- Navigate to the OS X > Workstyles node.
- Right-click the Workstyles node, and then click Create Workstyle on the top-right. The Workstyle Wizard is displayed.
- You can optionally enter a license code at this stage or you can enter it later once the Workstyle has been created.
- You can choose from Controlling or Blank for your Workstyle. A controlling Workstyle allows you to apply rules for access to privileges and applications. A blank Workstyle allows you to create an empty Workstyle without any predefined elements. If you select a blank Workstyle, the next screen is Finish as there is nothing to configure.
- Filtering (Controlling Workstyle only). This determines who will receive this Workstyle. You can choose from Standard users only or everyone. If you apply it to everyone, it will apply to Administrators. You can modify the filters and apply more detailed filtering once the Workstyle has been created.
- Capabilities (Controlling Workstyle only). Allows you to choose Endpoint Privilege Management, Application Control, or both. If you don't select either capabilities, the next screen is Finish. This Workstyle would only contain filtering information.
- Privilege Management (Controlling Workstyle with the Endpoint Privilege Management capability). Allows you to choose how you manage Authorization prompts including sudo control and Installer privileges.
If you select Present users with a challenge code from the dropdown, you are prompted to configure the challenge and response functionality at the end of creating your Workstyle, if your policy doesn't already have one. - Application Control (Controlling Workstyle with the Application Control capability). Allows you to choose:
- How you want to apply application control. You can choose from an allowlist or blocklist approach. We recommend you use an allowlist approach.
- As an allowlist: How you want to handle non-allowed applications.
- As a blocklist: How you want to handle blocked applications.
- How you want to apply application control. You can choose from an allowlist or blocklist approach. We recommend you use an allowlist approach.
- Finish. Allows you to enter a Name and Description for your new policy. If the Workstyle has been configured to use a Challenge / Response message and the policy doesn't have an existing key, you will be asked to set a key. You can check the box on this screen to activate this Workstyle immediately or you can clear the box to continue configuring the Workstyle before you apply it to your endpoints.
Depending on the type of Workstyle and any capabilities included, Endpoint Privilege Management for Mac auto-generates certain Application Groups (containing rules) and Messages. Filters are applied and subsequently configured as part of the Workstyle.
Disable or enable workstyles
By default, a Workstyle is disabled when initially created. Enable a Workstyle when configuration is complete and ready for the production environment.
Disable the Workstyle whenever you need to change the configuration.
To enable or disable a Workstyle:
- Navigate to the policy and select the Workstyles node. You can see which policies are disabled and enabled in the list.
- Right-click on the Workstyle and click Disable Workstyle to disable it or Enable Workstyle to enable it.
In the above example, the General Rules Workstyle is enabled and the High Flexibility Workstyle is disabled.
Workstyle precedence
If you have multiple Workstyles, they are evaluated in the order they are listed. Workstyles higher in the list have a higher precedence.
Once an application matches a Workstyle, no further Workstyles are processed for that application. It is important you order your Workstyles correctly, because an application could match more than one Workstyle.
To change the precedence of a Workstyle:
- Select the Workstyles node in the left pane.
- Right-click and choose from: Move Top, Move Up, Move Down, Move Bottom
Workstyle summary
Select the OS X node in the policy editor to view a summary of the Workstyles, Application Groups, and Messages in the policy.
Some tabs may not display if they are not configured in the policy.
Overview
The Overview tab allows you to quickly access the following features of your policy:
- General: Allows you to edit the description of your Workstyle and enable or disable it.
- Totals: Allows you to configure Application Rules.
- Filters: Allows you to configure filters.
Application rules
Application Rules are applied to Application Groups. Application Rules can be used to enforce allowlisting, monitoring, and assigning privileges to groups of applications. They are a set of rules that apply to the applications listed in the Application Group.
You need an Application Group before you can create an Application Rule.
Application Rules are color coded in the interface:
- Green: The default action is Passive (No Change) or Allow.
- Orange: The default action is Block.
Insert an application rule
Click Application Rules to view, create, or modify the following for each Application Rule:
| Option | Description |
|---|---|
| Target Application Group | Select from the Application Groups list. |
| Default Action | Select from Passive (No Change), Allow Execution, or Block Execution. This is what will happen if the application in the targeted Application Group is launched by the end user. |
| Default End User Message | Select if a message will be displayed to the user when they launch the application. We recommend using Messages if you're blocking the execution of the application so the end user has some feedback on why the application doesn't launch. |
| Auditing | |
| Raise an Event | Whether or not you want an event to be raised if this Application Rule is triggered. This will forward to the local event log file. |
| BeyondInsight Reporting Options | |
| BeyondInsight Events | When configured, sends BeyondInsight events to BeyondInsight. |
| Endpoint Privilege Management Reporting | When configured, sends Endpoint Privilege Management Reporting events to BeyondInsight. |
Application rule precedence
If you add more than one Application Rule to a Workstyle, then entries that are higher in the list will have a higher precedence. Once an application matches an Application Rule, no further rules or Workstyles will be processed. If an application could match more than one Workstyle or rule, then it is important you order both your Workstyles and rules correctly. You can move Application Rules up and down to change the precedence.
Filters
The Filters tab of a Workstyle can be used to further refine when a Workstyle will be applied. By default, a Workstyle will apply to all users and computers who receive it. However, you can add one or more filters that will restrict the application of the Workstyle:
Account filters
Account filters specify the users and groups the Workstyle will be applied to.
Note
When a new Workstyle is created, a default account filter will be added to target either Standard users only or Everyone (including administrators), depending on your selection in the Workstyle Wizard.
To restrict a Workstyle to specific groups or users, you can filter on the Account Name, UID/GID, or both.
- Expand the appropriate Workstyle in the left pane and click Filters.
- Select Add a new local OS X account or Add a new domain account if you want to use Windows AD to create your filters. If you choose this option, you need to create a mapping between your Windows SID macOS UID/GUID. You can choose to filter by User or Group.
- For User, you can match on the Account Name, the User ID, or both. In the instance of both, they both must match for the filter to be applied. The Account Name is not case sensitive.
- For Group you can match on the Group Name, the Group ID, or both. In the instance of both, they both must match for the filter to be applied. The Group Name is not case sensitive.
- Click OK to finish configuring your filter.
By default, an account filter will apply if any of the user or group accounts in the list match the user. If you have specified multiple user and group accounts within one account filter, and want to apply the Workstyle only if all entries in the account filter match, then check the box at the top of the screen that says All items below should match.
You can add more than one account filter if you want the user to be a member of more than one group of accounts for the Workstyle to be applied.
If an account filter is added, but no user or group accounts are specified, a warning will be displayed advising No accounts added, and the account filter will be ignored.
Note
If All items below should match is selected, and you have more than one user account listed, the Workstyle will never apply, as the user cannot match two different user accounts.
Note
For more information, see Clarification regarding the status of Identity Management for Unix (IDMU) & NIS Server Role in Windows Server 2016 Technical Preview and beyond.
Computer filters
A computer filter can be used to target specific computers. You can specify a computer using either its host name, or by an IP address.
To restrict the Workstyle to specific computers by IP address:
- Select the Filters tab, and then click Add a new filter.
- Click Add a Computer Filter > Add a new IP rule. The Add IP rule dialog box appears.
- Enter the IP address manually, in the format 123.123.123.123.
- Click Add.
Note
You can also use the asterisk wildcard () in any octet to include all addresses in that octet range, for example, 192.168..*. Alternatively, you can specify a particular range for any octet, for example, 192.168.0.0-254. Wildcards and ranges can be used in the same IP Address, but not in the same octet.
To restrict the Workstyle to specific computers by hostname:
- Select the Filters tab, and then click Add a Filter.
- Click Add a Computer Filter > Add a new hostname rule. The Add hostname rule dialog box appears.
- Enter a hostname, or alternatively browse for a computer. You can use the * and ? wildcard characters in hostnames.
- Click Add.
Note
By default, a computer filter is applied if any of the computers or IP Addresses in the list match the computer or client. If you specified multiple entries, and want to apply the Workstyle only if all entries in the computer filter match, then check the option All items below should match.
If a computer filter is added, but no host names or IP addresses are specified, a warning displays advising No rules added, and the computer filter is ignored.
Application Groups
Application Groups are used to define logical groupings of applications.
Application Groups are assigned to Workstyles, so you must define Application Groups for all of the applications you want to assign to a Workstyle.
Create Application Groups
To create an Application Group:
- Navigate to the OS X > Application Groups node.
- Right-click the Application Groups node, and then click New Application Groups on the top-right. The Workstyle Wizard is displayed.
- Enter a name and a description (if required) for the new Application Group. Click OK to save your new Application Group.
View or edit an Application Group
Each Application Group has a name, an optional description, and can be hidden from the policy navigation tree. You can edit these in the properties for the Application Group.
To view the properties of an Application Group:
- Navigate to the OS X > Application Groups node.
- Right-click the Application Groups and click Properties to view the properties. Make any changes you require and click OK to save the new properties.
Delete an Application Group
Application Groups are usually mapped to one or more Application Rule in a Workstyle. If you attempt to delete an Application Rule that is mapped to an Application Group, you are notified of this before you continue. If you continue to delete the Application Group, the associated Application Rule in the Workstyle is also deleted.
To delete an Application Group:
- Navigate to the OS X > Application Groups node.
- Right-click on the Application Group you want to delete and click Delete.
- If there aren't any Application Rules in the Workstyle using that Application Group, then it is deleted. If there are Application Rules in the Workstyle referencing that Application Group, then you are prompted to check the reference before you continue. If you click OK, then both the Application Group and the Application Rule referencing it are deleted from your policy. If you don't want to do this, click Cancel.
Duplicate an Application Group
You can duplicate an Application Group if you need a new Application Group containing the same applications as an existing Application Group. You can edit a duplicated Application Group independently of the Application Group it was duplicated from.
To duplicate an Application Group:
- Navigate to the OS X > Application Groups node.
- Right-click on the Application Group you want to duplicate and click Copy.
- Select the Application Groups node, right-click, and select Paste. This will make a new copy of the Application Group and all the Application Rules it contained.
- A new duplicate Application Group with an incremental number in brackets appended to the name will be created that you can add applications to.
Rule precedence
If you add more than one Application Rule or content rule to a Workstyle, then entries higher in the list will have a higher precedence. Once a target matches a rule, no further rules or Workstyles will be processed for that target. If a target could match more than one Workstyle or rule, then it is important you order both your Workstyles and rules correctly.
To change the precedence of a rule within a Workstyle:
- Expand the relevant Workstyle and then select the rule type tab: Application, On-Demand, or Content.
- Right click on the rule and use the following options to change the rule precedence:
- Move Top
- Move Up
- Move Down
- Move Bottom
Application definitions
Note
All matching criteria are case sensitive on macOS.
Application definitions allow you to target applications based on specific properties. When an application is executed, Endpoint 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 Endpoint Privilege Management for Mac will attempt to match against subsequent definitions in the Application Group.
Endpoint 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.
Endpoint Privilege Management for Mac must match every definition you configure before it will trigger a match. The rules are combined with a logical AND.
Application definitions requiring a match can also be negated. To target applications that do not match the definition, select does NOT match from the dropdown.
Definitions
Application requests authorization
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
Command line arguments
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 Mac Sudo command arguments not supported.
File or folder name matches
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
File hash (SHA-1 fingerprint)
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>
File hash (SHA-256) matches
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, 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
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 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
Publisher matches
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
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 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
URI
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
Install action matches
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
Delete action matches
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
Manage disk mounted images
Endpoint Privilege Management for Mac examines each Disk Mounted Image (DMG) when running with a valid license. If there are one or more bundles of applications in the Disk Image, where the policy is contained within an allow rule for the Workstyle, and the install action is also set to Yes in the Application Rule, the user is allowed to copy those bundles to the System Applications folder on the endpoint.
If the applications do not have an Endpoint Privilege Management Allow rule, the copying of the bundle defaults to normal macOS functionality where admin credentials are required to copy the bundle to the System Applications folder. Standard macOS functionality is used if anything other than an Allow rule is associated with the application bundle in the DMG, such as Block or Passive.
Note
Previously, to trigger copy functionality, the bundle from the DMG had to be in an Application Group with an Endpoint Privilege Management Allow rule.
As of version 5.4, the same condition applies, however, the bundle must also have Install Action match set to Yes in the Application matching criteria, within the Application Groups settings to right-click and Install with Defendpoint.
Existing policies must be altered to reflect the changes in functionality.
For more information, see Manage system applications.
Configure the defendpoint.plist file
Managing DMGs is controlled by default, but it can be turned off by editing the defendpoint.plist file.
The location for the defendpoint.plist file is /Library/Application Support/Avecto/Defendpoint/defendpoint.plist.
Set the MountAssistant key to false to turn off the Endpoint Privilege Management for Mac management of DMG files (it is set to true by default):
<key>MountAssistant</key>
<false/>
You must restart the defendpointd daemon after you edit the defendpoint.plist file for any changes to take effect. This can either be done by restarting the machine or by running these commands from Terminal:
sudo launchctl unload /Library/LaunchDaemons/com.avecto.defendpointd.plist
sudo launchctl load /Library/LaunchDaemons/com.avecto.defendpointd.plist
Note
If you specify the -w parameter in the command line, it will disable the daemon and a reboot will not turn it back on. Not including the parameter will allow the daemon to restart after a reboot of the endpoint.
Format of messages
Within the defendpoint.plist file, you can also modify the string used for the messaging in the key tag.
The format of the messages is a key and string tag:
<key>MountMessageAllow</key>
<string>Allow copying "[APP_NAME]" from "[MOUNT_NAME]" to Applications?</string>
The following placeholders can be used:
- [APP_NAME]: Replaced by the Application Name.
- [MOUNT_NAME]: Replaced by the Volume Name of the mounted DMG.
When you enter your own strings for the above keys, the formatting is 'what you see is what you get'. For example, if you press Enter, then you will get a new line.
You can configure the message displayed to the user at the endpoint in the following scenarios:
- MountMessageAllow: Message that appears when a DMG containing an allowed bundle, is mounted.
- MountMessageNoteSame: Message that appears in smaller text below the MountMessageAllow message if the bundle is allowed, but the same version exists in the destination.
- MountMessageNoteNewer: Message that appears in smaller text below the MountMessageAllow message if the bundle is allowed but a newer version of the bundle exists in the destination.
- MountMessageNoteOld: Message that appears in smaller text below the MountMessageAllow message if the bundle is allowed but an older version of it exists in the destination.
- MountNotificationSuccess: Message that appears in the macOS notification center when the copying process succeeds.
- MountNotificationFailure: Message that appears in the macOS notification center when the copying process fails.
If the message keys above have not been set, Endpoint Privilege Management for Mac uses the default values and strings. If you enter the `key` but do not specify the `string`, then the message will be empty.
You must use escaped characters for valid XML, such as in the examples below:
| Symbol | Escaped Form |
|---|---|
| " | "" |
| & | &" |
| ‘ | &apos" |
| < | <" |
| > | >" |
Example
The following examples show sample messages in the defendpoint.plist file.
<key>MountMessageAllow</key>
<string>Allow copying "[APP_NAME]" from "[MOUNT_NAME]" to Applications?</string>
<key>MountMessageNoteSame</key>
<string>Note: same version of the item named "[APP_NAME]" already exists in this location.</string>
<key>MountMessageNoteNewer</key>
<string>Note: a newer version of the item named "[APP_NAME]" already exists in this location.</string>
<key>MountMessageNoteOlder</key>
<string>Note: an older version of the item named "[APP_NAME]" already exists in this location.</string>
<key>MountNotificationSuccess</key>
<string>"[APP_NAME]" was successfully copied from "[MOUNT_NAME]" into the Applications older.</string>
<key>MountNotificationFailure</key>
<string>"[APP_NAME]" was not successfully copied from "[MOUNT_NAME]" into the Applications folder.</string>
Manage system applications
Endpoint Privilege Management for Mac examines each application and, if there is an application bundle where the application is associated with an Allow rule and Install Action match of Yes, the user can right-click the application and select Install with Privilege Management. This will install the bundle in the /Applications folder on the endpoint.
If the applications do not have an Allow rule with an Install Action match or Delete Action match of Yes, the management of the bundle defaults to normal macOS functionality where admin credentials are required to manage the bundle in the /Applications folder. Standard macOS functionality is used if anything other than an Allow rule with an Install Action match or Delete Action match of Yes is associated with the application bundle, such as Block or Passive.
Note
- You cannot use File Hash matching criteria to install or uninstall unsigned bundles.
- Per system functionality, applications that are running or protected by System Integrity Protection (SIP) cannot be uninstalled.
Manage the Endpoint Privilege Management Finder Extension
To use Run with Privilege Management menu functionality to manage the System Applications folder, the Privilege Management Finder Extension must be enabled under System Preferences > Extensions > Finder Extensions.
The Finder extension allows end users to install applications. The extension works in the same way as the native macOS functionality. The following sections provide details on the Finder extension behavior.
Remove applications from the /Applications folder
Standard users can drag an application from the /Applications folder to the Trash.
- If the application matches a policy entry which has Deletable set on it, then any messages configured in the policy are displayed first to the user, and the user can proceed.
- If the policy does not contain a matching entry for the item being removed, then this is treated as a passive event and the user is prompted for an administrative user’s credentials to proceed.
Install applications distributed in a DMG file
The Finder extension is active within mounted DMG volumes to install applications.
As with all previous releases, if a standard user attempts to drag an application to the /Applications folder, then they are prompted for an administrator’s user name and password to proceed.
Allowing standard users to install applications using the Finder extension or MountAssist features remains, as per previous releases.
VLC media player is an example of an application distributed in a DMG volume.
Install applications distributed from a non-DMG file
As of version 22.7, a standard user can drag files to the /Applications folder to install applications.
This only supports application bundles which are not contained within a mounted disk (DMG).
Standard users can drag an application from the /Applications folder to the Trash.
- Removing these file types behaves passively if the dragged item does not match any entries in the policy.
- Allows the user to remove the application pending the completion of any configured Endpoint Privilege Management for Mac messaging.
Allow authorization of the console application
Note
Starting in version 24.1, this feature is no longer supported.
With the introduction of macOS Big Sur, standard user accounts are required to enter administrator credentials when attempting to stream logs in the Console application. This behavior does not use Apple's authorization services framework.
To permit standard users access to the Console application, you can create a policy allowing access to the application from the Finder Extension context menu. The context menu is not available through the Dock or Spotlight.
When configured, a standard user can stream logs in the Console application as an administrator user, which mirrors the behavior of the Console application on macOS Catalina.
This feature explicitly works for the Console application in /System/Applications/Utilities/.
Note
The feature is not available for any other application.
Configure the authorization
Note
Starting in version 24.1, this feature is no longer supported.
Target the Console application in an allow rule with any matching criteria. We recommend using the following:
- Application type: Bundle
- Matching criteria:
- URI: com.apple.console
- Publisher: Software Signing
Keep the following points in mind when setting up the policy:
- If you are using a variation of the QuickStart policy for Mac, you might need to add a new rule above the (Default) Passive - System Trusted in All Users as the Console application matches within that Application Group.
- If the allow rule is configured with a message, then the message appears when the user attempts to open the Console application in a traditional method. We recommend using an allow rule without a message so that the users can use the feature without being prompted.
Insert a binary
Note
Matching criteria is case sensitive.
- Select the Application Group you want to add the binary control to.
- Right-click and select Insert Application > Binary.
- Enter a File or Folder Name, or click Template to choose a template.
- Enter a description or accept the default and click Next . You can leave the Description blank to match on all binaries.
- Configure matching criteria for the binary:
- File or Folder Name matches
- File Hash (SHA-1 Fingerprint
- File Hash (SHA-256) matches
- Application Requests Authorization
- Command line arguments
- Publisher matches
- Parent Process matches
- Click Finish. The binary is added to the Application Group.
Insert a bundle
Note
Matching criteria is case sensitive.
- Select the Application Group you want to add the bundle control to.
- Right-click and select Insert Application > Bundle.
- Enter a File or Folder Name, or click Template to choose a template.
- Enter a description or accept the default and click Next . You can leave the Description blank to match on all bundles.
- Configure matching criteria for the bundle:
- File or Folder Name matches
- File Hash (SHA-1 Fingerprint
- File Hash (SHA-256) matches
- Source
- File Version matches
- URI
- Application Requests Authorization
- Publisher matches
- Parent Process matches
- Click Finish. The bundle is added to the Application Group.
Insert a package
Note
Matching criteria is case sensitive.
- Select the Application Group you want to add the package to.
- Right-click and select Insert Application > Package.
- Enter a File or Folder Name, or click Template to choose a template.
- Enter a description or accept the default and click Next. You can leave the Description blank to match on all packages.
- Configure matching criteria for the package:
- File or Folder Name matches
- File Hash (SHA-1 Fingerprint)
- File Hash (SHA-256) matches
- Application Requests Authorization
- Publisher matches
- Click Finish. The package is added to the Application Group.
Insert a script
Use the Script application type to target a script that is trying to run privileged operations using sudo. System administrators can apply Application Rules on scripts to allow installation and management of development tools; for example, Homebrew.
Supported script types include:
- bash (.sh)
- ruby (.rb)
- python (.py - xattr)
Note
Matching criteria is case sensitive.
- Select the Application Group you want to add the script control to.
- Right-click and select Insert Application > Script.
- Enter a File or Folder Name.
- Enter a description or accept the default and click Next. You can leave the Description blank to match on all scripts.
- Configure matching criteria for the binary:
- File or Folder Name matches
- File Hash (SHA-1 Fingerprint)
- File Hash (SHA-256) matches
- Command Line Arguments
- Parent Process matches
- Click Finish. The script is added to the Application Group.
Install Homebrew
The Homebrew installer is a shell script which users can download to their machine and run. This script internally uses sudo to create folders on the system and set their ownership/permissions to be accessible by the installing user, reducing the need for further privileged sudo operations when users want to install packages.
Allow standard users to install Homebrew via Endpoint Privilege Management for Mac
Prepare a script
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>
Add the script to policy
To create a rule to match this script in the Policy Editor:
-
Create an Application Group to add the script control.
-
Right-click and select Insert Application > Script.
-
Enter * as the file or folder name, as you're matching explicitly on hash.
-
Enter a description of User Homebrew Installation.
-
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.
-
Click Finish. The script is added to the Application Group.
Add a sudo command for Homebrew to policy
In the same Application Group:
-
Right-click and select Insert Application > Sudo Command.
-
Enter * to represent any sudo command.
-
Enter a description or accept the default, and click Next.
-
Configure the Parent Process Matches to be the group which you are editing.
This keeps the configuration of Homebrew isolated within the policy and easier to navigate. Alternatively, you can separate the Script and Sudo application definitions.
-
Click Finish. The sudo command is added to the Application Group.
Set Up an application rule for Homebrew
- Select the Workstyle that is appropriately filtered for users you want to allow to install Homebrew.
- Create an application assignment for the Application Group that contains the sudo command, of type Allow Execution, with your messaging and auditing preferences.
Insert a Sudo command
Note
Matching criteria is case sensitive.
- Select the Application Group you want to add the sudo command to.
- Right-click and select Insert Application > Sudo Command.
- Enter a File or Folder Name, or click Template to choose a template.
- Enter a description or accept the default and click Next. You can leave the Description blank to match on all sudo commands.
- You can leave the Description blank to match on all sudo commands.
- Configure matching criteria for the sudo command:
- File or Folder Name matches
- File Hash (SHA-1 Fingerprint)
- File Hash (SHA-256) matches
- Command Line Arguments
- Publisher matches
- Parent Process matches
- Click Finish. The sudo command is added to the Application Group.
Sudo switches
Endpoint Privilege Management for Mac supports running sudo commands with the following switches:
- -b, --background
- -e, --edit
- -i, --login
- -S, --stdin
- -s, --shell
- -V, --version
When a sudo command is run, Endpoint Privilege Management for Mac ignores any switches that have been used and will match the rest of the command against the application definition. If Endpoint Privilege Management for Mac matches against a rule that allows execution, the sudo command runs with any supported switches that were used. Any switches that are not supported by Endpoint Privilege Management for Mac are ignored.
If Endpoint Privilege Management for Mac matches on a passive rule or doesn't match any rules, then the sudo command runs with any supported or unsupported switches that have been used.
Note
- The -e switch requires configuration in Endpoint Privilege Management for Mac for it to be supported. For more information, see Edit -e switch.
- The -l --list switch, which lists the commands the user is allowed to run, does not take into account the commands that are restricted by Endpoint Privilege Management for Mac.
Edit -e switch
The -e --edit switch, also known as sudoedit, allows the user to edit one or more files using their preferred text editor. The text editor is defined by setting the SUDO_EDIT, VISUAL, or EDITOR environment variable in the user's Terminal session. Otherwise, the default editor, Vim, is used. To configure your policy to support the -e switch, you must set up a sudo command Application Rule so that:
- The File or Folder Name definition is set to sudoedit with the Perform Match Using set to Exact Match.
- The Command Line Arguments definition is set to the path of the files you want to control using this rule.
For example, the application definition shown in the following screenshot supports the sudo command sudo -e /etc/hosts.
The audit log will show an application of /usr/bin/sudo and the command line arguments will have -e prepended to them.
Note
Matching criteria is case sensitive.
Important
When adding the Battery preference pane to a policy, the match must include the URI and exact file path, similar to:
Failing to configure the preference correctly can result in matching unrelated authorization requests, which can lead to unexpected behavior.
Add a system preference pane
- Select the Application Group you want to add the system preference pane to.
- Right-click and select Insert Application > System Preference Pane.
- Enter an Auth Request URI or click Template to choose a template.
- Enter a description or accept the default and click Next. You can leave the Description blank to match on all bundles.
- Configure matching criteria for the system preference pane:
- File or Folder Name matches
- File Hash (SHA-1 Fingerprint)
- File Hash (SHA-256) matches
- Source
- File Version matches
- Application Requests Authorization
- Publisher matches
- Click Finish. The System Preference Pane is added to the Application Group.
Insert applications from templates
Application templates provide a simple way to pick from a list of known applications. A standard set of templates are provided that cover basic administrative tasks.
There are two ways you can insert applications into Application Groups. If you want to insert multiple applications from the BeyondTrust templates, you must add the applications from the template menu.
Use the add apps to template menu
- Select the Application Group you want to add the application to.
- Right-click and select Insert Application > Application Template. Choose one or more applications to add to the Application Group. You can select multiple rows using standard Windows functionality.
- Click Insert to add the applications.
Updated 8 days ago