Command Line Policy
Manage the use of sudo across your macOS and Linux endpoints
Overview
On macOS and Linux systems, the Command-line policy manages the use of sudo as a standard user.
By default, Keeper has created a specific list of Linux commands which are elegible to be elevated by the standard user with sudo. If the request matches one of the eligible commands, Keeper will apply the policy and enforce approval, MFA or justification based on the policy details.
Command-Line policies provide granular control over how applications are executed. Administrators can define allowed or denied command arguments and enforce restrictions at the subcommand level, ensuring that even permitted applications operate strictly within approved parameters.
How it Works
After a command has been approved, the Keeper service temporarily adds the requested command to the sudoers file for the designated user.
Policies Without an Extensions Section
Wildcard Elevated-Only Policy
A Command Line policy that has no Extensions section configured will, by default, match only elevated commands — that is, commands run via sudo (on macOS and Linux) or via a UAC elevation (on Windows). Because it has no command-scope restrictions, it applies to all such elevated commands for the targeted users and machines. This makes it functionally equivalent to a wildcard sudo policy: every elevated command that reaches the policy engine will match it.
This is the appropriate starting point for a broad governance baseline — for example, requiring justification or approval before any elevated command runs — before layering in more targeted policies for specific commands.
Example: The following policy requires approval for every elevated command on targeted machines, with no restriction on which command is run:
json
Because there is no Extension section, this policy matches all elevated commands. To restrict scope to specific commands, or to apply the policy to non-elevated commands, see the sections below.
Usage
When a Command-line policy is applied, Keeper uses a pam module to override the sudo command with a new keepersudo command. Users can simply execute keepersudo to either request approval, elevate with MFA or send a justification message.
If a user attempts to use sudo, they will be instructed with the new command:
If an elevation policy is applied, the user can execute the command using keepersudo:
The admin will receive the elevation request.
After the request has been approved, the user can run keeperagent --approval to execute the approved request.
Managing Sudo Elevation
From the Admin Console > Endpoint Privilege Manager > Policies create a new policy. Select "Command Line" from the policy type and then "Enforce".
Command Line policies can be applied to specific users and machine collections. Select the machine collections to apply the policy.
Advanced Configuration
The "eligible" list of sudo commands is explicitly set in a file called ExecutableAllowlist.json.
On macOS, the file is located here:
On Linux systems, the file is located here:
If the admininstrator would like to allow additional commands, this file must be modified on each endpoint. (Note: In an upcoming release, Keeper will be incorporating the list of allowed commands into the front-end UI and sync'd policy).
Controlling the Elevation Context: The IsElevated Field
IsElevated FieldBy default, a Command Line policy targets elevated commands only. If you want a policy to apply to commands run without elevation — for example, standard shell commands a user runs directly without sudo — you must explicitly set "IsElevated": false in the Extension section.
The IsElevated field has three possible states:
Not set (absent)
Policy matches elevated commands only
true
Policy matches elevated commands only (same as not set)
false
Policy matches non-elevated commands (and also elevated commands)
Example: The following policy applies to non-elevated ls commands with specific arguments:
json
Without "IsElevated": false in the Extension section, this policy would not match a non-elevated command, and the user's action would proceed without any policy control being applied.
Scoping a Policy to Specific Commands: AllowCommands
AllowCommandsA Command Line policy without an AllowCommands array in its Extension section is a wildcard command policy — it matches every command run by the targeted user on the targeted machine (subject to the IsElevated context). This is the correct approach for broad governance baselines.
When you add one or more entries to Extension.AllowCommands, the policy's scope narrows: it will only match commands whose command line contains one of the listed patterns. Commands that do not match any pattern in AllowCommands are simply not governed by that policy and fall through to other applicable policies (or the system default).
Command patterns use case-insensitive substring matching — a pattern of /usr/bin/passwd will match sudo /usr/bin/passwd testuser and SUDO /USR/BIN/PASSWD admin.
AllowCommands configured?
Policy scope
No
Matches all commands (wildcard)
Yes
Matches only commands containing a listed pattern
Example — wildcard (no AllowCommands): Requires justification for any sudo command.
json
Example — scoped to specific commands: Allows password rotation without requiring justification, but only for the passwd command specifically.
json
Any command that does not contain /usr/bin/passwd in its command line is unaffected by this second policy and remains governed by the first.
Important: Specificity is determined by UserCheck, ApplicationCheck, and MachineCheck — not by whether AllowCommands is present. A policy with AllowCommands but ApplicationCheck: ["*"] is still treated as a wildcard policy and will not take automatic precedence over another wildcard policy. To achieve specific-policy precedence, ensure the policy's ApplicationCheck (or UserCheck / MachineCheck) targets a named application or collection rather than "*".
Built-In User Behavior
Keeper does not modify the sudo permissions of the built-in user, e.g. ubuntu or ec2-user. Therefore, when a user is a member of a group with existing sudo permissions, attempts to elevate to sudo will not be limited to the list of ExecutableAllowlist.json commands. In other words, Keeper's service applies best effort to adhere to enforcement policies when the user has already been granted elevated access by the system administrator.
To ensure full control over the elevation rights, ensure that users are not part of a group with existing sudo membership.
Interaction with Other Policy Types
Command-Line policies complement Privilege Elevation and Least Privilege policies by enforcing argument-level restrictions across both elevated and standard execution contexts. This ensures consistent enforcement regardless of privilege state.
Last updated
Was this helpful?