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. 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: 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. Likewise, linebreaks that are ignored in the /etc/sudoers file are not allowed in the Identity Management configuration. 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. 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 Click the Policy tab. Click the Sudo subtab, and then select the Sudo Rules link. Click the Add link at the top of the list of sudo rules. Enter the name for the rule. 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. 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. Click the + Add link at the right of the options list. Enter the sudoers option. Click Add . In the Who area, select the users or user groups to which the sudo rule is applied. Click the + Add link at the right of the users list. 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. Click Add . It is possible to configure both IdM users and external system users ( Section 21.3.1, "About External Users" ). In the Access This Host area, select the hosts on which the sudo rule is in effect. Click the + Add link at the right of the hosts list. 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. Click Add . 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. In the Allow/Deny area, click the + Add link at the right of the commands list. 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. Click Add . Optional. The sudo rule can be configured to run the given commands as a specific, non-root user. In the As Whom area, click the + Add link at the right of the users list. 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. 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: 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. , add the commands to grant access to. This can be a single command, using --sudocmds , or a group of commands, using --sudocmdgroups . Add a host or a host group to the rule. 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. 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: 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: 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. 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: 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: 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: Obtain a Kerberos ticket for the admin user or any other user allowed to manage sudo rules. Add a new sudo rule to IdM. Define the who : specify the group of users who will be entitled to use the sudo rule. Define the where : specify the group of hosts where the users will be granted the sudo permissions. Define the what : to allow the users to run any sudo command, add the all command category to the rule. To let the sudo commands be executed as root, do not specify any run-as users or groups. Add the !authenticate sudoers option to specify that the users will not be required to authenticate when using the sudo command. Display the new sudo rule configuration to verify it is correct. 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: 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: To completely delete a rule from the command line, run a command such as the following:

Commands:
mail_badpass, mail_no_host, mail_no_perms, syslog = local2
[jsmith@server ~]USD ipa sudorule-add-option readfiles Sudo Option: mail_badpass ----------------------------------------------------- Added option "mail_badpass" to Sudo rule "readfiles" ----------------------------------------------------- [jsmith@server ~]USD ipa sudorule-add-option readfiles Sudo Option: syslog=local2 ----------------------------------------------------- Added option "syslog=local2" to Sudo rule "readfiles" -----------------------------------------------------
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"
[jsmith@server ~]USD ipa sudorule-add-option readfiles Sudo Option: env_keep="COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 ... XAUTHORITY"
ipa sudorule-add* options ruleName
[jsmith@server ~]USD kinit admin [jsmith@server ~]USD ipa sudorule-add files-commands ----------------------------------- Added sudo rule "files-commands" ----------------------------------- Rule name: files-commands Enabled: TRUE
[jsmith@server ~]USD 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 -------------------------
[jsmith@server ~]USD 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 -------------------------
[jsmith@server ~]USD 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 -------------------------
[jsmith@server ~]USD kinit admin [jsmith@server ~]USD ipa sudorule-add-allow-command --sudocmds "/usr/bin/less" readfiles [jsmith@server ~]USD ipa sudorule-add-allow-command --sudocmds "/usr/bin/tail" readfiles [jsmith@server ~]USD ipa sudorule-add-deny-command --sudocmds "/usr/bin/vim" readfiles
[jsmith@server ~]USD kinit admin [jsmith@server ~]USD ipa sudorule-add-option readfiles Sudo Option: !authenticate ----------------------------------------------------- Added option "!authenticate" to Sudo rule "readfiles" -----------------------------------------------------
ipa sudorule-add-runasuser --users=jsmith readfiles ipa sudorule-add-runasgroup --groups=ITadmins readfiles
ipa sudorule-mod --runasgroupcat=all ruleName
ipa sudorule-add-user --externaluser=ITAdmin readfiles ipa sudorule-add-runasuser --runasexternaluser=root readfiles
kinit admin Password for admin@EXAMPLE.COM:
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
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 -------------------------
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 -------------------------
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
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
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
ipa sudorule-disable files-commands
ipa sudorule-del files-commands