Security and Compliance
Guide

Configure endpoint privilege management for Workbrew

Petros Amoiridis

This guide shows you how to configure an endpoint privilege management (EPM) tool, such as CyberArk EPM or BeyondTrust, so it does not block the Workbrew Agent's privileged operations. EPM tools commonly intercept sudo, and when they do not account for the Workbrew Agent, operations that Workbrew runs as root through sudo fail silently. For the reasoning behind the recommendation below, and why it is safe, see How the Workbrew Agent uses elevated privileges.

Recognize the symptom

EPM interference usually shows up as elevated operations that silently fail rather than as an obvious error in the Workbrew Console. The most common signs are:

  • A cask install, upgrade, or uninstall that Workbrew runs fails partway through with a message from your EPM tool in the command output, such as Execution blocked: _workbrewd does not have Admin rights.
  • On older Workbrew Agent versions, Standard Users do not get brew access even though Managed brew access is enabled, and their Devices show "Access Denied" in the Console.
  • On older Agent versions, the Workbrew Agent log at /opt/workbrew/var/log/workbrew-agent.log contains sudo: a password is required, and the Agent stays on an old version because it cannot update itself.

The first happens because Homebrew elevates some cask steps through sudo, and when the Agent runs Homebrew it does so as the _workbrewd account. Running a cask's package installer and removing an app during an uninstall or upgrade are two examples. Updating the Workbrew Agent does not change this, so the policy below is what resolves it.

The other two happen because older Agents run their own root operations with sudo --non-interactive, which fails immediately rather than prompting when the EPM tool does not allow the call. The latest version of the Agent runs those operations in a separate privileged helper that does not use sudo, so they no longer depend on the EPM policy. An older Agent cannot update itself to the latest version while its sudo is blocked. Either apply the policy below, or deploy the latest Agent package to those Devices through your MDM once.

Allow the Workbrew Agent's elevation

The Workbrew Agent's daemon runs as a dedicated _workbrewd system account. Homebrew commands the Agent runs elevate to root through sudo from that account, as do the Agent's own root operations on older versions. On install, Workbrew adds a single rule at /etc/sudoers.d/workbrew:

_workbrewd ALL=(root) NOPASSWD:ALL

Your EPM policy needs to let that elevation run. EPM tools differ in how policies are expressed, so apply the following to whichever targeting your tool supports:

  • Account: _workbrewd
  • Process: the Workbrew Agent daemon, registered as the LaunchDaemon com.workbrew.workbrew-agent, with the executable at /opt/workbrew/bin/brew
  • Code signature: Apple Developer Team ID 676JW3JDLF, if your tool can scope by signed publisher rather than by path
  • Elevation it performs: /usr/bin/sudo -E -- <command> from Homebrew, and /usr/bin/sudo --non-interactive -- <command> from the Agent

Homebrew calls sudo from its own process rather than from /opt/workbrew/bin/brew. If your tool matches on the calling process or its signature, check that the rule also covers those calls. A rule on the _workbrewd account covers both.

Allow the _workbrewd account's elevation as a whole rather than allowlisting individual commands. The commands that go through sudo depend on which casks you manage and change across Homebrew and Workbrew releases, so a command-level policy would need constant revisiting and would silently break Workbrew when it drifts. Scoping the policy to the daemon account covers every operation and stays correct across updates. See the explanation linked above for why this does not expand Workbrew's privileges.

Verify

Apply the policy, then rerun the cask command that failed. It should run to completion instead of stopping at the elevated step.

On older Agent versions, also trigger or wait for a Device check-in. On an affected Device, confirm an authorized Standard User is now in the workbrew_users group:

dseditgroup -o checkmember -m "USERNAME" workbrew_users

A USERNAME is a member of workbrew_users result confirms the elevation now succeeds. In the Workbrew Console, the Device's brew access status changes from "Access Denied" to "Granted via Workbrew" on the next check-in, and sudo: a password is required stops appearing in /opt/workbrew/var/log/workbrew-agent.log.

If access still does not appear, the user may genuinely lack a Secure Token rather than being blocked by the EPM tool. See Managed brew access for how accounts are selected, and Adding Users to the workbrew_users Group via MDM for adding users directly with a script.