The Linux Sudoer Policy lets administrators centrally manage which users and groups can run commands through sudo on managed Linux devices.

With this policy, you can:

This policy supports least-privilege access by granting users only the administrative commands required for their roles.

Important: Incorrect sudoers rules can grant unintended root access or prevent administrators from performing recovery tasks. Test every policy on a nonproduction device before broad deployment.

Behavior can vary by Linux distribution, installed sudo version, identity provider, and local sudoers configuration.

Before creating a policy:

Use the following command to find an executable’s resolved path:

Example result:

Always configure the absolute path instead of relying on the user’s PATH.

Use the following baseline for most deployments:

Avoid rules that combine all users, all hosts, unrestricted commands, root, and passwordless authentication.

A policy can contain multiple sudoer rules. Each rule defines:

Separate unrelated administrative tasks into different rules. This makes permissions easier to audit, test, and revoke.

The Rule ID uniquely identifies the rule.

Use a stable, descriptive identifier when this field is configurable, for example:

or:

Do not reuse the same identifier for unrelated rules.

Controls whether the rule is active.

The default value is enabled.

Disable a rule when temporarily suspending access without deleting its configuration.

Controls which rule takes precedence when multiple Swif sudoer rules overlap.

Higher values have higher priority. The default value is:

A practical priority model is:

Use consistent priority ranges across your organization. Avoid assigning different priorities without documenting why they are needed.

Important: Priority resolves conflicts between Swif-managed rules. Existing local sudoers entries or rules delivered by another management product may still affect the user’s effective access.

Subjects identify the users or groups to which a rule applies.

Each subject contains a Type and Value.

Enter the exact username or group name recognized by Linux.

Examples:

Prefer role-based groups over individual user rules. Group-based access is generally easier to review and revoke as responsibilities change.

Before deployment, confirm that the identity resolves correctly:

For identities supplied by LDAP, Active Directory, SSSD, or another directory service, test name resolution while the device is connected to the required network.

Hosts determine where a rule applies.

Each host entry contains a Type and Value.

Enter the hostname, IP address, or netgroup required by the selected type.

The value is optional when Type is all.

Example for all assigned devices:

Example for a named host:

Host restrictions depend on the device resolving and reporting the expected identity. Consider DHCP changes, multiple network interfaces, short and fully qualified hostnames, and directory-service availability.

Netgroup matching requires working netgroup resolution on the device. Test it before deployment:

The Run As settings define the users and groups under which the subject may execute the configured commands.

Enter one or more target usernames.

The most common target is:

However, commands should run as a less-privileged service account when root access is unnecessary.

Example:

Enter one or more target groups when the command must run with a specific group identity.

Leave this field empty if the user does not need to select a target group.

Explicitly configure the required run-as identities. Avoid granting access to a broad set of target users or groups.

Each command entry defines an allowed or denied executable and can include an exact argument list and SHA-256 digest.

Use allow entries to build a narrow permission set. Use deny entries when you must exclude a specific command from a broader Swif-managed permission.

When allow and deny rules overlap, review their priorities and test the resulting permission on the device.

Important: A deny rule does not necessarily remove access granted independently through another local sudoers file, another management product, or direct root-group membership.

Enter the executable’s absolute path.

Example:

Do not enter only:

The executable path alone does not necessarily limit what the program can do. Shells, editors, interpreters, package managers, service managers, and programs that load user-controlled configuration can provide indirect ways to execute other commands.

High-risk examples include:

Granting unrestricted access to these programs can be equivalent to granting a root shell.

Use Arguments to require an exact argument list for the command match.

For example, to allow only a restart of the NGINX service:

This should authorize:

It should not authorize unrelated actions such as:

Enter arguments in their expected order. Differences in spelling, order, paths, options, or service names can prevent a match.

Do not assume that shell wildcard characters, variables, redirection, pipes, or command substitution are interpreted safely. Use literal, narrowly scoped arguments and test the exact command users will run.

Security warning: Allowing a service restart can still be dangerous if the user can modify the service unit, executable, environment file, configuration, plugin directory, or startup script.

Optionally enter the executable’s SHA-256 digest. When configured, the executable must match the specified digest.

Generate a digest on the target platform with:

Example output:

Enter only the digest value.

Leave this field empty when hash verification is not required.

A digest can reduce the risk of an executable being replaced, but it has operational tradeoffs:

The sudoers documentation also warns that executable digest checks can be undermined if the user can modify the command during execution. Keep privileged executables and their directories writable only by trusted administrators. See the Ubuntu sudoers manual.

Controls whether sudo requires password authentication for the rule.

The default value is enabled.

Recommended value:

Use passwordless access only for a documented automation or operational requirement. A passwordless rule increases the impact of a compromised user session, account, or process.

Before disabling password authentication:

Password authentication does not replace least-privilege command restrictions. Depending on the device’s sudo timestamp configuration, a recently authenticated user may not be prompted again for a period of time.

When enabled, No Exec applies the NOEXEC sudoers tag. It is intended to prevent an allowed program from launching additional executables.

Recommended value:

Enable it when compatible with the approved command, especially for interactive programs that might otherwise provide shell escapes.

NOEXEC is a defense-in-depth control, not a complete sandbox. Its effectiveness depends on operating-system and program behavior, and it may not prevent every form of code execution. It can also break applications that legitimately start helper programs.

Test the complete workflow after enabling it.

When enabled, Set Environment applies the SETENV sudoers tag and permits the user to set or preserve environment variables that sudo would otherwise restrict.

Recommended value:

Environment variables can change library loading, interpreter behavior, configuration paths, plugin discovery, and command execution. Enabling SETENV can turn an otherwise limited command into a privilege-escalation path.

Enable it only when:

For more information about environment handling, see the Ubuntu sudoers manual.

This example allows members of web-operators to restart only nginx.service as root.

Before deploying, confirm that members of the group cannot modify the NGINX service unit, executable, configuration, or loaded modules.

This example allows a monitoring account to run one approved status command noninteractively.

The script or executable, its parent directory, and every file it loads must be protected from modification by monitoring-agent.

This example grants access only on a specific server.

Review interactive database-client features carefully. A command-line client may allow file access, shell execution, or privileged database actions beyond the initial command.

After assigning the policy:

visudo -c checks sudoers syntax and, depending on the implementation and invocation, can also validate included files, ownership, and permissions. See the Ubuntu visudo manual.

Keep an existing privileged session open during initial testing so the device can be recovered if a rule causes unexpected access problems.

Check the following:

Run:

A newly added group membership may require the user to sign out and sign back in before the session receives the updated group list.

A narrowly written Swif rule cannot remove an independent permission granted elsewhere unless the effective sudoers configuration explicitly resolves the conflict that way.

Software upgrades commonly replace executable files, producing a new digest.

Do not remove digest verification permanently merely to bypass an unexplained mismatch. First confirm that the executable came from a trusted source.

A matching rule may use NOPASSWD, or the user may have a valid cached sudo authentication timestamp.

The approved program may need to start a helper executable.

Before enabling Set Environment:

Run:

If an error is reported: