About using sudo
Sudo is a program for Unix-like computer operating systems that lets users run programs using the security privileges of another user (by default, the superuser).
Sudo lets you configure highly restricted user privileges on a remote device (refer to the commands listed in the table below). This new sudo option offers a more secure connection because root access is no longer required. Root access meant that if user account credentials were compromised, all other data on the remote device was potentially compromised, as well.
DID YOU KNOW? On Trust Protection Foundation, sudo is a method for provisioning certificates to a device using a non-root account and uses the default file ownership and permissions configured on your operating system. If your implementation requires different file ownership or permissions, Trust Protection Foundation drivers that support sudo include the ability to set them using a different feature of the driver.
When using sudo with Trust Protection Foundation, consider the following limitations and requirements:
- Workflow (SSH) Command Injection is not supported with sudo unless the injected commands are prefixed with sudo and no password is required by sudo to execute them.
- Only one certificate can be provisioned at a time to the same device when using sudo (the Concurrent Connection Count must be 1).
- The sudo account used by Trust Protection Foundation must have read and write permissions to the temp directory, as well as permissions to transfer files to and from the temp directory using SFTP.
- sudo can only be used with Palo Alto Networks drivers that make use of an SSH command-line interface and is only supported by platforms that use a standard, non-proprietary command shell.
|
Commands used with Central Generation |
Commands used with Remote Generation |
|
|
General Purpose |
ls rm cp |
ls rm cp |
|
Set File/Owner Permissions |
chmod chown |
chmod
chown |
|
Apache and PEM |
openssl | |
|
GSK |
gsk7cmd gsk7capicmd gsk8capicmd gsk8capicmd_64 ikeycmd |
|
|
iPlanet |
certutil pk12util |
certutil pk12util |
|
JKS |
keytool | |
|
PKCS#12 |
(Not Applicable) |
|
Purpose |
Commands |
| Find and check key files |
ls, stat, grep, sha256sum |
|
Manage temporary files |
mkdir, touch, chmod, chown, cp, rm |
| Identify the server | echo, hostname, host |
To ensure SSH Manager can function across different Linux distributions, you must allow each of these commands in both the /bin and /usr/bin directories.
When sudo is enabled, each command executed remotely on a device is prefixed with “sudo” to have the command execute in a privileged security context. The sudoers file governs which commands and which users are allowed. It can also specify whether or not the user must enter their password when prompted, an optional configuration that is supported by Trust Protection Foundation.
EXAMPLE In this example sudoer file, venafi is the user name that Trust Protection Foundation has been configured to use, /opt/pki is the target directory, /tmp is the temporary directory, and the commands are being executed via sudo without having to specify a password.
IMPORTANT The following example provides a general guide to get you started. Do not use the following example without replacing wildcard references with actual file path names wherever possible so as not to allow directory traversal.
# GSK, JKS, PEM, PKCS#12 central gen
venafi ALL= NOPASSWD:/bin/ls -ld /opt/pki*
venafi ALL= NOPASSWD:/bin/cp -pf /tmp/* /opt/pki/*
venafi ALL= NOPASSWD:/bin/cp /opt/pki/* /tmp/*
venafi ALL= NOPASSWD:/bin/cp -pf /opt/pki/* /opt/pki/*
venafi ALL= NOPASSWD:/bin/cp /tmp/* /tmp/*
venafi ALL= NOPASSWD:/bin/rm -rf /opt/pki/*.bak
venafi ALL= NOPASSWD:/bin/rm -rf /tmp/*
# for setting file owner/group and/or permissions
venafi ALL= NOPASSWD:/bin/chmod 0[0-7][0-7][0-7] /opt/pki/*
venafi ALL= NOPASSWD:/bin/chown * /opt/pki/*
venafi ALL= NOPASSWD:/bin/chmod 0[0-7][0-7][0-7] /tmp/*
venafi ALL= NOPASSWD:/bin/chown * /tmp/*
# iPlanet
venafi ALL= NOPASSWD:/bin/ls -ld /usr/bin/certutil, /bin/ls -ld /usr/bin/pk12util
venafi ALL= NOPASSWD:/usr/bin/certutil *, /usr/bin/pk12util *
venafi ALL= NOPASSWD:/bin/cp -pf /tmp/* /tmp/*
venafi ALL= NOPASSWD:/bin/ls -ld /tmp*
# PEM remote gen
venafi ALL= NOPASSWD:/usr/bin/openssl *
# JKS remote gen
venafi ALL= NOPASSWD:/usr/bin/keytool *
# GSK remote gen
venafi ALL= NOPASSWD:SETENV:/bin/sh -c ikeycmd *
venafi ALL= NOPASSWD:SETENV:/bin/sh -c gsk7cmd *
venafi ALL= NOPASSWD:SETENV:/bin/sh -c gsk7capicmd *
venafi ALL= NOPASSWD:SETENV:/bin/sh -c gsk8capicmd *
venafi ALL= NOPASSWD:SETENV:/bin/sh -c gsk8capicmd_64 *
Configuring sudo for SSH Manager
EXAMPLE If you use sudo for privilege elevation, you must configure the sudoers file on each target server to allow the SSH Manager's service account to run the required discovery and remediation commands. The following example shows the specific entries needed to support agentless operations. To ensure compatibility across different Linux distributions, this configuration explicitly allows both the /bin and /usr/bin path variants for every command.
IMPORTANT Replace <service_account> with the actual username of the credential you created for SSH connections. This example allows each command to run without a password and without specific argument restrictions.
# SSH Manager
<service_account> ALL= NOPASSWD:/bin/echo, /usr/bin/echo
<service_account> ALL= NOPASSWD:/bin/mkdir, /usr/bin/mkdir
<service_account> ALL= NOPASSWD:/bin/chmod, /usr/bin/chmod
<service_account> ALL= NOPASSWD:/bin/chown, /usr/bin/chown
<service_account> ALL= NOPASSWD:/bin/rm, /usr/bin/rm
<service_account> ALL= NOPASSWD:/bin/cp, /usr/bin/cp
<service_account> ALL= NOPASSWD:/bin/ls, /usr/bin/ls
<service_account> ALL= NOPASSWD:/bin/stat, /usr/bin/stat
<service_account> ALL= NOPASSWD:/bin/sha256sum, /usr/bin/sha256sum
<service_account> ALL= NOPASSWD:/bin/grep, /usr/bin/grep
<service_account> ALL= NOPASSWD:/bin/hostname, /usr/bin/hostname
<service_account> ALL= NOPASSWD:/bin/host, /usr/bin/host
<service_account> ALL= NOPASSWD:/bin/touch, /usr/bin/touch
Testing sudo access on a target host
Before you schedule fleet-wide scans, test the service account elevation rules on a representative target server:
-
Open a terminal session and log in to the target server using the discovery service account.
-
Run a test command with sudo to confirm elevation works without prompting for a password:
sudo stat /etc/ssh/sshd_config
-
Verify that the command outputs file details and returns exit code 0.
IMPORTANT If the command prompts for a password or returns sudo: a password is required, agentless discovery will fail when attempting to read protected files such as /etc/ssh/sshd_config or user .ssh directories. Update your /etc/sudoers file or PAM elevation rules before running the scan.
For additional information and resources regarding sudo, visit the following websites:
Related Topics