# Command Line
## 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 ```json { "PolicyName": "Require approval for all sudo commands", "PolicyType": "CommandLine", "Status": "enforce", "Actions": { "OnSuccess": { "Controls": ["APPROVAL"] } }, "UserCheck": ["*"], "MachineCheck": [""] } ``` 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: ``` ubuntu@ip-172-31-8-134:/home$ sudo systemctl restart nginx ERROR: To run sudo, use keepersudo ``` If an elevation policy is applied, the user can execute the command using keepersudo: ``` ubuntu@ip-172-31-8-134:/home$ keepersudo systemctl restart nginx Your Keeper Administrator requires approval for this action. Please enter the reason for this request: Ticket SYS-4432 I need to restart nginx Approval request has been submitted. To refresh approval status run: keeperagent --refresh After approval run: keeperagent --approval ``` The admin will receive the elevation request.
After the request has been approved, the user can run `keeperagent --approval` to execute the approved request. ``` ubuntu@ip-172-31-8-134:/home$ keeperagent --approval You have 1 approved command: 1: /usr/bin/sudo /usr/bin/systemctl restart nginx (expires in 23 hours and 57 minutes) To run an approved command, enter the number. To see pending requests, type 'p' To refresh approvals, type 'r' Choose an option or 'e' to exit: 1 ``` ## 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: {% code overflow="wrap" %} ``` /Library/Keeper/sbin/Plugins/bin/KeeperLeastPrivilegeEnforcer/Configuration/ExecutableAllowlist.json ``` {% endcode %} On Linux systems, the file is located here: {% code overflow="wrap" %} ``` /opt/keeper/sbin/Plugins/bin/KeeperLeastPrivilegeEnforcer/Configuration/ExecutableAllowlist.json ``` {% endcode %} 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 By 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:
ValueBehavior
Not set (absent)Policy matches elevated commands only
truePolicy matches elevated commands only (same as not set)
falsePolicy matches non-elevated commands (and also elevated commands)
**Example:** The following policy applies to non-elevated `ls` commands with specific arguments: json ```json { "PolicyName": "Audit non-elevated ls usage", "PolicyType": "CommandLine", "Status": "monitor", "Actions": { "OnSuccess": { "Controls": ["AUDIT"] } }, "UserCheck": ["*"], "ApplicationCheck": ["*"], "Extension": { "IsElevated": false } } ``` 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` A 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
NoMatches all commands (wildcard)
YesMatches only commands containing a listed pattern
**Example — wildcard (no `AllowCommands`):** Requires justification for any `sudo` command. json ```json { "Extension": { "IsElevated": true }, "Actions": { "OnSuccess": { "Controls": ["JUSTIFY"] } } } ``` **Example — scoped to specific commands:** Allows password rotation without requiring justification, but only for the `passwd` command specifically. json ```json { "Extension": { "IsElevated": true, "AllowCommands": ["/usr/bin/passwd"] }, "Actions": { "OnSuccess": { "Controls": ["ALLOW"] } } } ``` 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 ```json { "ApplicationCheck": ["*"], "UserCheck": ["*"], "Extension": { "IsElevated": true }, "Actions": { "OnSuccess": { "Controls": ["MFA"] } } } ``` *Policy B — specific, allows password rotation without controls:* json ```json { "ApplicationCheck": ["sudo", "/usr/bin/sudo"], "UserCheck": ["*"], "Extension": { "IsElevated": true, "AllowCommands": ["/usr/bin/passwd"] }, "Actions": { "OnSuccess": { "Controls": ["ALLOW"] } } } ``` 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`, 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-types/command-line-policy-type.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.