SupportConsoleDevelopersStart a trialContact

21.3. Defining sudo Rules

sudo rules are in a sense similar to access control rules: they define users who are granted access, the commands which are within the scope of the rule, and then the target hosts to which the rule applies. In IdM, additional information can be configured in the rule, such as sudoers options and run-as settings, but the basic elements always define who, what (services), and where (hosts).

21.3.1. About External Users

sudo rules define four elements: who can do what, where, and as whom. The who is the regular user, and the as whom is the system or other user identity which the user uses to perform tasks. Those tasks are system commands that can be run (or specifically not run) on a target machine.
Three of those elements — who, as whom, and where — are identities. They are users. Most of the time, those identities are going to be entities within the IdM domain because there will be overlap between the system users in the environment and the users and hosts belonging to the IdM domain.
However, that is not necessarily the case with all identities that a sudo policy may realistically cover. For example, sudo rules could be used to grant root access to member of the IT group in IdM, and that root user is not a user in IdM. Or, for another example, administrators may want to block access to certain hosts that are on a network but are not part of the IdM domain.
The sudo rules in Identity Management support the concept of external users — meaning, users which are stored and exist outside of the IdM configuration.
External Entities

Figure 21.1. External Entities

When configuring a sudo rule, the user and run-as settings can point to an external identity to be included and evaluated in the sudo rule.

21.3.2. About sudo Options Format

The sudo rule can be configured to use any supported sudoers options. The complete list of options is in the sudoers man page.
However, the sudo rule configuration in Identity Management does not allow the same formatting as the configuration in the /etc/sudoers file. Specifically, Identity Management does not allow whitespaces in the options parameter, whether it is set in the UI or the CLI.
For example, in the /etc/sudoers file, it is permissible to list options in a comma-separated list with spaces between: 
mail_badpass, mail_no_host, mail_no_perms, syslog = local2
However, in Identity Management, that same configuration would be interpreted as different arguments — including the equals sign (=) since it has spaces around it. Instead, each option must be added individually, either through the UI or the command-line tools. 
[jsmith@server ~]$ ipa sudorule-add-option readfiles
Sudo Option: mail_badpass
-----------------------------------------------------
Added option "mail_badpass" to Sudo rule "readfiles"
-----------------------------------------------------
[jsmith@server ~]$ ipa sudorule-add-option readfiles
Sudo Option: syslog=local2
-----------------------------------------------------
Added option "syslog=local2" to Sudo rule "readfiles"
-----------------------------------------------------
...
Likewise, linebreaks that are ignored in the /etc/sudoers file are not allowed in the Identity Management configuration. 
env_keep = "COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC 
            KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 
            QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE LC_COLLATE 
            LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES 
            LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE 
            LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET 
	    XAUTHORITY"
For example, the same command in the IdM command line has all of the variables on one line and no spaces around the equals sign. 
[jsmith@server ~]$ ipa sudorule-add-option readfiles
Sudo Option: env_keep="COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 ... XAUTHORITY"
To use multiple sudoers options in Identity Management, configure each one as a separate option setting, rather than all on one line.

21.3.3. Defining sudo Rules in the Web UI

  1. Click the Policy tab.
  2. Click the Sudo subtab, and then select the Sudo Rules link.
  3. Click the Add link at the top of the list of sudo rules.
  4. Enter the name for the rule.
  5. Click the Add and Edit button to go immediately to set the configuration for the rule.
    There are a number of configuration areas for the rule. The most basic elements are set in the Who, Access This Host, and Run Commands areas; the others are optional and are used to refine the rule.
  6. Optional. In the Options area, add any sudoers options. The complete list of options is in the sudoers man page.

    Note

    As described in Section 21.3.2, “About sudo Options Format”, do not use options with whitespace in the values. Rather than adding a list of options in one line, add a single option setting for each desired option.
    1. Click the + Add link at the right of the options list.
    2. Enter the sudoers option.
    3. Click Add.
  7. In the Who area, select the users or user groups to which the sudo rule is applied.
    1. Click the + Add link at the right of the users list.
    2. Click the checkbox by the users to add to the rule, and click the right arrows button, >>, to move the users to the selection box.
    3. Click Add.
    It is possible to configure both IdM users and external system users (Section 21.3.1, “About External Users”).
  8. In the Access This Host area, select the hosts on which the sudo rule is in effect.
    1. Click the + Add link at the right of the hosts list.
    2. Click the checkbox by the hosts to include with the rule, and click the right arrows button, >>, to move the hosts to the selection box.
    3. Click Add.
  9. In the Run Commands area, select the commands which are included in the sudo rule. The sudo rule can grant access or deny access to commands, and it can grant allow access to one command and also deny access to another.
    1. In the Allow/Deny area, click the + Add link at the right of the commands list.
    2. Click the checkbox by the commands or command groups to include with the rule, and click the right arrows button, >>, to move the commands to the selection box.
    3. Click Add.
  10. Optional. The sudo rule can be configured to run the given commands as a specific, non-root user.
    1. In the As Whom area, click the + Add link at the right of the users list.
    2. Click the checkbox by the users to run the command as, and click the right arrows button, >>, to move the users to the selection box.
    3. Click Add.

21.3.4. Defining sudo Rules in the Command Line

Each element is added to the rule command using a different command (listed in Table 21.1, “sudo Commands”).
The basic outline of a sudo rule command is: 
$ ipa sudorule-add* options ruleName

Example 21.1. Creating Basic sudo Rules

In the most basic case, the sudo configuration is going to grant the right to one user for one command on one host.
The first step is to add the initial rule entry. 
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa sudorule-add files-commands
-----------------------------------
Added sudo rule "files-commands"
-----------------------------------
  Rule name: files-commands
  Enabled: TRUE
Next, add the commands to grant access to. This can be a single command, using --sudocmds, or a group of commands, using --sudocmdgroups. 
[jsmith@server ~]$ ipa sudorule-add-allow-command --sudocmds "/usr/bin/vim" files-commands
  Rule name: files-commands
  Enabled: TRUE
  sudo Commands: /usr/bin/vim
-------------------------
Number of members added 1
-------------------------
Add a host or a host group to the rule. 
[jsmith@server ~]$ ipa sudorule-add-host --host server.example.com files-commands
  Rule name: files-commands
  Enabled: TRUE
  Hosts: server.example.com
  sudo Commands: /usr/bin/vim
-------------------------
Number of members added 1
-------------------------
Last, add the user or group to the rule. This is the user who is allowed to use sudo as defined in the rule; if no "run-as" user is given, then this user will run the sudo commands as root. 
[jsmith@server ~]$ ipa sudorule-add-user --user jsmith files-commands
  Rule name: files-commands
  Enabled: TRUE
  Users: jsmith
  Hosts: server.example.com
  sudo Commands: /usr/bin/vim"
-------------------------
Number of members added 1
-------------------------

Example 21.2. Allowing and Denying Commands

The sudo rule can grant access or deny access to commands. For example, this rule would allow read access to files but prevent editing: 
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa sudorule-add-allow-command --sudocmds "/usr/bin/less" readfiles
[jsmith@server ~]$ ipa sudorule-add-allow-command --sudocmds "/usr/bin/tail" readfiles
[jsmith@server ~]$ ipa sudorule-add-deny-command --sudocmds "/usr/bin/vim" readfiles

Example 21.3. Using sudoers Options

The sudoers file has a lot of potential flags that can be set to control the behavior of sudo users, like requiring (or not requiring) passwords to offer a user to authenticate to sudo or using fully-qualified domain names in the sudoers file. The complete list of options is in the sudoers man page.
Any of these options can be set for the IdM sudo rule using the sudorule-add-option command. When the command is run, it prompts for the option to add: 
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa sudorule-add-option readfiles
Sudo Option: !authenticate
-----------------------------------------------------
Added option "!authenticate" to Sudo rule "readfiles"
-----------------------------------------------------

Note

As described in Section 21.3.2, “About sudo Options Format”, do not use options with whitespace in the values. Rather than adding a list of options in one line, add a single option setting for each desired option.

Example 21.4. Running as Other Users

The sudo rule also has the option of specifying a non-root user or group to run the commands as. The initial rule has the user or group specified using the --sudorule-add-runasuser or --sudorule-add-runasgroup command, respectively. 
$ ipa sudorule-add-runasuser --users=jsmith readfiles
$ ipa sudorule-add-runasgroup --groups=ITadmins readfiles
When creating a rule, the sudorule-add-runasuser or sudorule-add-runasgroup command can only set specific users or groups. However, when editing a rule, it is possible to run sudo as all users or all groups by using the --runasusercat or --runasgroupcat option. For example: 
$ ipa sudorule-mod --runasgroupcat=all ruleName

Note

The --sudorule-add-runasuser and --sudorule-add-runasgroup commands do not support an all option, only specific user or group names. Specifying all users or all groups can only be used with options with the sudorule-mod command.

Example 21.5. Referencing External Users

The "who" in a sudo rule can be an IdM user, but there are many logical and useful rules where one of the referents is a system user. Similarly, a rule may need to grant or deny access to a host machine on the network which is not an IdM client.
In those cases, the sudo policy can refer to an external user — an identity created and stored outside of IdM (Section 21.3.1, “About External Users”).
The options to add an external identity to a sudo rule are:
  • --externaluser
  • --runasexternaluser
For example: 
$ ipa sudorule-add-user --externaluser=ITAdmin readfiles
$ ipa sudorule-add-runasuser --runasexternaluser=root readfiles
Table 21.1. sudo Commands
Command Description
sudorule-add Add a sudo rule entry.
sudorule-add-user Add a user or a user group to the sudo rule. This user (or every member of the group) is then entitled to sudo any of the commands in the rule.
sudorule-add-host Add a target host for the rule. These are the hosts where the users are granted sudo permissions.
sudorule-add-runasgroup Set a group to run the sudo commands as. This must be a specific user; to specify all users, modify the rule using sudo-rule.
sudorule-add-runasuser Set a user to run the sudo commands as. This must be a specific user; to specify all users, modify the rule using sudo-rule.
sudorule-add-allow-command Add a command that users in the rule have sudo permission to run.
sudorule-add-deny-command Add a command that users in the rule are explicitly denied sudo permission to run.
sudorule-add-option Add a sudoers flag to the sudo rule.
sudorule-disable Temporarily deactivate a sudo rule entry.
sudorule-enable Activate a previously suspended sudo rule.
sudorule-del Remove a sudo rule entirely.

Example 21.6. Adding and Modifying a New sudo Rule from the Command Line

To allow a specific user group to use sudo with any command on selected servers:
  1. Obtain a Kerberos ticket for the admin user or any other user allowed to manage sudo rules. 
    $ kinit admin
Password for admin@EXAMPLE.COM:
  2. Add a new sudo rule to IdM. 
    $ ipa sudorule-add new_sudo_rule --desc="Rule for user_group"
---------------------------------
Added Sudo Rule "new_sudo_rule"
---------------------------------
  Rule name: new_sudo_rule
  Description: Rule for user_group
  Enabled: TRUE
  3. Define the who: specify the group of users who will be entitled to use the sudo rule. 
    $ ipa sudorule-add-user new_sudo_rule --groups=user_group
  Rule name: new_sudo_rule
  Description: Rule for user_group
  Enabled: TRUE
  User Groups: user_group
-------------------------
Number of members added 1
-------------------------
  4. Define the where: specify the group of hosts where the users will be granted the sudo permissions. 
    $ ipa sudorule-add-host new_sudo_rule --hostgroups=host_group
  Rule name: new_sudo_rule
  Description: Rule for user_group
  Enabled: TRUE
  User Groups: user_group
  Host Groups: host_group
-------------------------
Number of members added 1
-------------------------
  5. Define the what: to allow the users to run any sudo command, add the all command category to the rule. 
    $ ipa sudorule-mod new_sudo_rule --cmdcat=all
------------------------------
Modified Sudo Rule "new_sudo_rule"
------------------------------
  Rule name: new_sudo_rule
  Description: Rule for user_group
  Enabled: TRUE
  Command category: all
  User Groups: user_group
  Host Groups: host_group
  6. To let the sudo commands be executed as root, do not specify any run-as users or groups.
  7. Add the !authenticate sudoers option to specify that the users will not be required to authenticate when using the sudo command. 
    $ ipa sudorule-add-option new_sudo_rule
Sudo Option: !authenticate
-----------------------------------------------------
Added option "!authenticate" to Sudo Rule "new_sudo_rule"
-----------------------------------------------------
  Rule name: new_sudo_rule
  Description: Rule for user_group
  Enabled: TRUE
  Command category: all
  User Groups: user_group
  Host Groups: host_group
  Sudo Option: !authenticate
  8. Display the new sudo rule configuration to verify it is correct. 
    $ ipa sudorule-show new_sudo_rule
  Rule name: new_sudo_rule
  Description: Rule for user_group
  Enabled: TRUE
  Command category: all
  User Groups: user_group
  Host Groups: host_group
  Sudo Option: !authenticate

21.3.5. Suspending and Removing sudo Rules

Defined sudo rules can either be temporarily deactivated or entirely deleted from the web UI or from the command line. Suspended rules are removed from the ou=sudoers compat tree without a need for a server restart.

Suspending and Removing sudo Rules from the Web UI

To suspend or completely delete a rule from the web UI, use the Disable or Delete buttons at the top of the list of sudo rules:
Suspending or Deleting a sudo Rule from the Web UI

Figure 21.2. Suspending or Deleting a sudo Rule from the Web UI

Suspending and Removing sudo Rules from the Command Line

To suspend a rule from the command line, run a command such as the following: 
ipa sudorule-disable files-commands
To completely delete a rule from the command line, run a command such as the following: 
ipa sudorule-del files-commands
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.