Command Line
Understanding the Keeper command-line policy setup and usage
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.
Command Line policies follow the same specific-versus-wildcard precedence rules that govern all other KEPM policy types. When multiple policies match a request, the engine separates them into specific and wildcard policies and evaluates only the more targeted group.
A policy is considered specific if its UserCheck, ApplicationCheck, or MachineCheck contains one or more non-wildcard values (i.e., it targets named users, named applications, or named machines rather than "*"). A policy is considered wildcard if all three of those filters are set to "*" or are empty.
The precedence rule is:
If any specific policies match the request, only those specific policies are evaluated; all wildcard policies are ignored for that request.
If no specific policies match, wildcard policies are evaluated.
This means a specific Allow policy for a particular application will take effect even if a wildcard policy requires MFA for all commands — because the specific policy wins and the wildcard is set aside.
Similarly, if two specific policies both apply to the same request and one requires Justification while the other requires Allow, Justification will be required — specific policies that conflict with one another combine additively, with Justification outranking Allow.
Control precedence order (highest to lowest): DENY → APPROVAL → MFA → JUSTIFY → ALLOW
Example:
Policy A — wildcard, requires MFA for all elevated commands:
json
Policy B — specific, allows password rotation without controls:
json
When a user runs sudo passwd testuser, Policy B is specific (its ApplicationCheck names sudo explicitly) and Policy A is a wildcard. The engine evaluates only Policy B, and the command is allowed without MFA.
Important: Specificity is determined by
UserCheck,ApplicationCheck, andMachineCheck— not by whetherAllowCommandsis present. A policy withAllowCommandsbutApplicationCheck: ["*"]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'sApplicationCheck(orUserCheck/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