Mac Policy Structure and Precedence

Structure

Policies are stored in /etc/defendpoint/. For example:

pmc.xml
epo.xml
mdm.xml
local.xml

These policies are not case-sensitive. All policies stored in this location must have the following permissions to ensure policy acceptance and system security:

Ownership of _defendpoint user and group, for example:
```
sudo chown _defendpoint:_defendpoint <policy path>
```
Permission for the _defendpoint user and group to read the policy, but not other users, for example:
```
sudo chmod 660 <policy path>
```

The policy or policies that are read and loaded by dppolicyserver are dependent on the settings under config.order in the defendpoint.plist.

If all policies are deleted, the local.xml policy is regenerated.

Precedence

The policy precedence determined in the defenpoint.plist, which is stored here: /Library/Application Support/Avecto/Defendpoint/defendpoint.plist.

The defendpoint.plist is appended or created with the precedence lists (as below) on start up or installation. But editing and saving of the list is applied immediately.

<key>config.order</key>
<array>
<string>pmc</string>
<string>epo</string>
<string>mdm</string>
<string>local</string>
</array>

You can edit the defendpoint.plist file manually to change the policy precedence if required.

The dppolicyserverd will go through the policies under /etc/defendpoint/ by finding the first policy in the config.order, and it if it can't a policy of that name it will progress to the next in the list.

If one or more policies are found with the correct name it will load them, irrespective of whether or not it has a license.

Apply Multiple Policies for MacOS Estates in ePO

For Mac estates managed by ePO, the simultaneous application of multiple policies is supported, for example:

epo.xml
epo001.xml
epo002.xml

In the example above, if the policy precedence is set for ePO policies, then rules processing will first check the rules in epo.xml. If no rules are found for the process in this policy, then it will go through epo001.xml. Each policy is processed in an alpha-numeric/C locale order. This continues until the process hits a rule or dppolicyserverd reads all of the policies without finding a match.

If multiple policies are loaded, only one of them requires a Privilege Management for Mac license. We do not recommend you use multiple licenses in this configuration. Each policy can have a different Challenge / Response key.

Copy and pasted policies with altered rules are still processed. The dppolicyserverd log outputs whether it replace GUIDs when loading them into memory if it was a duplicate.

Categories for Mac Application Templates

Privilege Management for Mac ships with some standard application templates to simplify the definition of applications that are part of the operating system. The standard application templates are split into categories:

System Preference Panes
Bundles
Binaries

Each category then has a list of applications for that category. Picking an application will cause the application to be prepopulated with the appropriate information.

Privilege Management for Mac Audit Logs

How to log events to a file:

When Privilege Management for Mac is installed, it checks to see if the following path and file is present. If it's not, it creates it: /var/log/defendpoint/audit.log
This file cannot be edited during output. If this file is deleted, Privilege Management for Mac recreates it dynamically. If the folder structure is deleted, Privilege Management for Mac recreates it when the endpoint is restarted.

This log file can be viewed in the macOS Console for all versions from /var/log in the side bar. You can also view the log output in real time, if required.

The log file is maintained by the core macOS service newsyslog. The newsyslog.conf file contains various log files and associated settings and is maintained by the core macOS. The newsyslog.conf file is held here: /etc/newsyslog.conf.

This part of the set up must be done by a user who can write to this location.

In the newsyslog.conf file the settings are outlined and have column headers:
logfilename, mode, count, size, when, flags
For the purposes of the maintenance of the audit.log file, you need to populate the logfilename, mode, count, size, and/or when, and flags attributes in the newsyslog.conf file.
- logfilename: Path and filename
- mode: File mode, i.e. settings for read/write for each user type (POSIX file permissions)
- count: Count for amount of archived files (count starts from 0)
- size: Threshold for log size in KB
- when: Threshold for log size in terms of time (i.e. new log everyday at X, or every month)
- flag: Instruction for processing the archived/turn-over file. This is most likely to be JN or ZN

An example of a line in the newsyslog.conf for Privilege Management for Mac is:

/var/log/defendpoint/audit.log 644 5 1000 * JN

This indicates that:

the filename is audit.log
it can be viewed by all user types but can only be edited by the root user
it has an archive count of 5 (6 archived files, not including the current log)
it has a threshold of 1MB for turn-over/archiving
it doesn't have a date turn over
for archiving, files are to be compressed into a .BZIP file

The threshold relies on the newsyslog service. This service is low priority in macOS and only reads the .conf file approximately every 30mins. Using the example line above, the log can become greater than 1MB prior to the service reading the newsyslog.conf file due to it being a "threshold" value, rather than each log file being of equal size.

Once you have applied the newsyslog.conf by adding the audit.log line to it, you can run sudo newsyslog -nv in Terminal to see the state of the logging, when the next roll over is, and whether there are any syntax issues.

Add Privilege Management for Mac Settings to a Mac Client Computer

Privilege Management for Mac settings are stored in the file /etc/defendpoint/local.xml, and can be overwritten with an exported XML file from the MMC. To prevent any invalid permissions being applied, we recommend that this file be replaced using the following command. In this example, the source XML file is located on your desktop:

sudo cp ~/Desktop/local.xml /etc/defendpoint/local.xml

Privilege Management for Mac will apply the new settings immediately, and does not require any restart.

Do not delete the local.xml file, as this will interfere with the client machine’s ability to enforce policy. If the local.xml file is deleted from a client machine, replace the file and restart the machine.

Mac Command Arguments Not Supported

The following arguments are not supported by Privilege Management for Mac when you use sudo:

Option (single dash)	Option (double dash)	Description
-A	--askpass	use a helper program for password prompting
-C num	--close-from=num	close all file descriptors >= num
-E	--preserve-env	preserve user environment when running command
-g group	--group=group	run command as the specified group name or ID
-H	--set-home	set HOME variable to target user's home dir
-h host	--host=host	run command on host (if supported by plugin)
-K	--remove-timestamp	remove timestamp file completely
-k	--reset-timestamp	invalidate timestamp file
-l	--list	list user's privileges or check a specific command; use twice for longer format
-n	--non-interactive	non-interactive mode, no prompts are used
-P	--preserve-groups	preserve group vector instead of setting to target's
-p prompt	--prompt=prompt	use the specified password prompt
-U user	--other-user=user	in list mode, display privileges for user
-u user	--user=user	run command (or edit file) as specified user name or ID
-v	--validate	update user's timestamp without running a command

Use Centrify to Bind MacOS Endpoints

If you are using Centrify to bind macOS endpoints to Active Directory, contact BeyondTrust Technical Support for assistance.