Bug 679493

Sudo 
    -Introduction-
        Sudo (su "do") allows a system administrator to delegate authority to
        give certain users (or groups of users) the ability to run some (or all)
        commands as root or another user while providing an audit trail of the 
        commands and their arguments. For more information, see the introduction 
        to Sudo.
    
    -Sudo with LDAP-
        In the past, sudo used a single local configuration file, /etc/sudoers.
        While the same sudoers file can be shared among machines, no built-in
        mechanism exists to distribute it.  Some have attempted to workaround 
        this by synchronizing changes via CVS/RSYNC/RDIST/RCP/SCP and even NFS.

        By using LDAP for sudoers we gain a centrally administered, globally 
        available configuration source for sudo.

    -LDAP schema for Sudo and its limitations-

        * Groups of users
            The current native SUDO schema relies upon LDAP stored posix
            groups for its groups of users. The limitation here is that you
            cannot use a group of users for SUDO without the users inheriting 
            potential posix rights.

        * Groups of hosts
            The current native SUDO schema does not have a concept of 
            hostgroups, instead, it relies upon the legacy LDAP
            nisNetgroupTriple to manage groups of hosts.

        * Groups of commands
            The current native SUDO schema does not have a concept of command
            groups.  This requires that individual commands be present in each
            SudoRule.  It also limits the ability of reusing a group of commands
            for multiple SudoRules.

    -IPA alternative schema. What problems it solves.-
 
        * How IPA addresses groups of users
            Groups of users can be either POSIX or NON-POSIX groups within IPA.
            This provides the flexibility of grouping users without assigning
            POSIX rights or GID information to the group.

        * How IPA addresses groups of computers
            Host groups and netgroups for purpose of SUDO - how they are 
            related (manged entries) and how they should be used with 
            examples.
            
        * How IPA addresses groups of commands
            Command groups are a new concept introduced by IPA.  These
            objects allow administrators the ability to create groups of
            SUDO commands that can be reused for multiple rules without
            the need of assigning individual commands throughout.
    
    -Compat plugin & Managed Entry plugin configuration-

        * Compat translation for native Sudo
            The native Sudo binary does not yet support SSSD or the IPA SUDO 
            Schema.  As an interim solution IPA has implimented a 
            compatabilty plugin which transparently translates IPA SUDO 
            Rules into those supported by the current Sudo binary.

        * Managed Entry for nis netgroups
            In order to seemlessly support the current implimentation of Sudo, 
            IPA provides Managed Entry plugin for NIS Netgroups.
            Whenever a IPA hostgroup is created, a translated 
            nisNetgroupTriple is also created.
        
    -Administering SUDO-

        * Overview of the CLI
            Creating SUDO objects is handled very similarly to managing HBAC.
            The first objects created should be SUDO commands.
                For example, to add 'less' as a potential SUDO command:
                ipa sudocmd-add --desc='For reading log files' /usr/bin/less
            Next up are SUDO Command Groups.
                Optionally, you can group together commands for reuse with
                the following syntax:
                ipa sudocmdgroup-add --desc='Read Only commands' readonly
            Finally a Sudo Rule is created.
                A Sudo rule should contain a minimum of the following:
                * User(s) or groups of users
                * Host(s) or groups of hosts
                * Command(s) or groups of commands
                Creating a Sudo rule works as is follows:
                
        * Overview of the UI
            <Details from Adam Young>
    
    -Deploying and configuring SUDO clients-

0) Install IPA following the instructions here: <http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#chap-Enterprise_Identity_Management_Guide-Installing_the_IPA_Server>

1) Add a client system following the instructions here: <http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#chap-Enterprise_Identity_Management_Guide-Installing_IPA_Clients>

2) Create all standard entries:

    * Setup the hostgroup
        a. Add a hostgroup: ipa hostgroup-add hostgroup-name
        b. Add the client host to the hostgroup: hostgroup-add-member --hosts=host.example.com hostgroup-name

    * Setup the user
        a. Add a new user: ipa user-add username
        b. Set the temp password: ipa user-mod --password username
        c. Reset with the permanent password: kinit username
        d. Add a group: ipa group-add group-name
        e. Add the new user to the group: ipa group-add-member --users=username group-name

    * Setup a BIND user
        a. Enable the sudo bind user by setting its password:
            LDAPTLS_CACERT=/etc/ipa/ca.crt /usr/bin/ldappasswd -S -W -h ipa.example.com -ZZ -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com
            New password: <enter password>
            Re-enter new password: <confirm password>

    * Setup Sudo Commands
        a. Add a sudo command: ipa sudocmd-add --desc='For reading log files' '/usr/bin/less'
        b. Add a sudo command group: ipa sudocmdgroup-add --desc='Read Only Commands' readonly
        c. Add the commanad to the group: ipa sudocmdgroup-add-member --sudocmds='/usr/bin/less' readonly

    * Setup Sudo Rule
        a. Add a sudo rule: ipa sudorule-add sudorule-name
        b. Add the allow commands: ipa sudorule-add-allow-command --sudocmdgroups=readonly sudorule-name
        c. Add the hosts: ipa sudorule-add-host --hostgroups=hostgroup-name sudorule-name
        d. Add the users: ipa sudorule-add-user --groups=group-name sudorule-name        

3) Configure Client for SUDO

    * Configure SUDO to look to LDAP for SUDOers
        a. Add the following lines to /etc/nsswitch.conf:
            sudoers:    ldap
            
    * Configure SSSD to look for NIS Netgroups
        a. Add the following beneath the "ipa_server" entry in /etc/sssd/sssd.conf:
            ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com
        b. Restart the SSSD Daemon:
            service sssd restart
            
    * Edit the LDAP Configuration file for SUDO:
        a. Add the following to /etc/nss_ldap.conf:
            sudoers_base ou=SUDOers,dc=example,dc=com
            binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com
            bindpw bind_password
            ssl start_tls
            tls_cacertfile /etc/ipa/ca.crt
            tls_checkpeer yes
            bind_timelimit 5                                                                                                                      
            timelimit 15                                                                                                   
            uri ldap://ipa.example.com
        b. To support compatibility create a symlink for the legacy configuration:
            ln -s /etc/nss_ldap.conf /etc/ldap.conf
            
    * Setup NIS Domain
        Sudo still utilizes NIS Netgroups.
        To support the client side identification of NIS Netgroup Domains you
        must define your NIS Domain Name.  This is done via the command: 
        "nisdomainname example.com"
        There is a bug file with Fedora to address this config requirement at
        boot time.
        /etc/rc.local:
            nisdomainname example.com

4) Execute the allowed command - observe success
5) Execute a new command that is not mentioned and thus not allowed
6) Add a new command to the group of the commands that are referenced as allowed commands from the SUDO rule you have created on step 2
7) Try this command again and see that it is now allowed.

        * Best Practice & Configuration
            Just as any SUDO implimentation using LDAP, in order to use SUDO 
            with IPA, client systems must be configured approprately.
            
            The following config tells SUDO to check the local /etc/sudoers file
            then LDAP for Sudo Rules:
            
            /etc/nsswitch.conf:
                sudoers:    files ldap
            
            In order to support LDAP Sudo looks to the /etc/ldap.conf or 
            /etc/nss_ldap.conf file to determine the location of ldap server
            and configuration info.
            
            To support the client side identification of NIS Netgroup Domains you
            must define your NIS Domain Name.  This is done via the command: 
            "nisdomainname expertcity.com"
            There is a bug filed against RHEL and Fedora to address this config requirement at
            boot time without having to enable the unused native NIS client pieces.
            /etc/rc.local:
                nisdomainname expertcity.com

                
-=SUDOERS OPTIONS=-
sudo's behavior can be modified by running: ipa sudorule-add-option SUDORULE-NAME [options]

A list of all supported Defaults parameters, grouped by type, are listed below.

Boolean Flags:

always_set_home
If enabled, sudo will set the HOME environment variable to the home directory of the target user (which is root unless the -u option is used). This effectively means that the -H option is always implied. Note that HOME is already set when the the env_reset option is enabled, so always_set_home is only effective for configurations where either env_reset is disabled or HOME is present in the env_keep list. This flag is off by default.

authenticate
If set, users must authenticate themselves via a password (or other means of authentication) before they may run commands. This default may be overridden via the PASSWD and NOPASSWD tags. This flag is on by default.

closefrom_override
If set, the user may use sudo's -C option which overrides the default starting point at which sudo begins closing open file descriptors. This flag is off by default.

compress_io
If set, and sudo is configured to log a command's input or output, the I/O logs will be compressed using zlib. This flag is on by default when sudo is compiled with zlib support.

env_editor
If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default editor list. Note that this may create a security hole as it allows the user to run any arbitrary command as root without logging. A safer alternative is to place a colon-separated list of editors in the editor variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. This flag is off by default.

env_reset
If set, sudo will reset the environment to only contain the LOGNAME, MAIL, SHELL, USER, USERNAME and the SUDO_ variables. Any variables in the caller's environment that match the env_keep and env_check lists are then added. The default contents of the env_keep and env_check lists are displayed when sudo is run by root with the -V option. If the secure_path option is set, its value will be used for the PATH environment variable. This flag is @env_reset@ by default.

fast_glob
Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names. However, since it accesses the file system, glob(3) can take a long time to complete for some patterns, especially when the pattern references a network file system that is mounted on demand (automounted). The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do its matching. The disadvantage of fast_glob is that it is unable to match relative path names such as ./ls or ../bin/ls. This has security implications when path names that include globbing characters are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should not be used when sudoers contains rules that contain negated path names which include globbing characters. This flag is off by default.

fqdn
Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you would use myhost.mydomain.edu. You may still use the short form if you wish (and even mix the two). Beware that turning on fqdn requires sudo to make DNS lookups which may make sudo unusable if DNS stops working (for example if the machine is not plugged into the network). Also note that you must use the host's official name as DNS knows it. That is, you may not use a host alias (CNAME entry) due to performance issues and the fact that there is no way to get all aliases from DNS. If your machine's host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn. This flag is off by default.

ignore_dot
If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH itself is not modified. This flag is off by default.

ignore_local_sudoers
If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent the usage of local sudoers files so that only LDAP is used. This thwarts the efforts of rogue operators who would attempt to add roles to /etc/sudoers. When this option is present, /etc/sudoers does not even need to exist. Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudoOption is only meaningful for the cn=defaults section. This flag is off by default.

insults
If set, sudo will insult users when they enter an incorrect password. This flag is off by default.

log_host
If set, the host name will be logged in the (non-syslog) sudo log file. This flag is off by default.

log_year
If set, the four-digit year will be logged in the (non-syslog) sudo log file. This flag is off by default.

long_otp_prompt
When validating with a One Time Password (OPT) scheme such as S/Key or OPIE, a two-line prompt is used to make it easier to cut and paste the challenge to a local window. It's not as pretty as the default but some people find it more convenient. This flag is off by default.

mail_always
Send mail to the mailto user every time a users runs sudo. This flag is off by default.

mail_badpass
Send mail to the mailto user if the user running sudo does not enter the correct password. This flag is off by default.

mail_no_host
If set, mail will be sent to the mailto user if the invoking user exists in the sudoers file, but is not allowed to run commands on the current host. This flag is off by default.

mail_no_perms
If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo but the command they are trying is not listed in their sudoers file entry or is explicitly denied. This flag is off by default.

mail_no_user
If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file. This flag is on by default.

noexec
If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden by a EXEC tag. See the description of NOEXEC and EXEC below as well as the PREVENTING SHELL ESCAPES section at the end of this manual. This flag is off by default.

path_info
Normally, sudo will tell the user when a command could not be found in their PATH environment variable. Some sites may wish to disable this as it could be used to gather information on the location of executables that the normal user does not have access to. The disadvantage is that if the executable is simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing. This flag is on by default.

passprompt_override
The password prompt specified by passprompt will normally only be used if the password prompt provided by systems such as PAM matches the string "Password:". If passprompt_override is set, passprompt will always be used. This flag is off by default.

preservegroups
By default, sudo will initialize the group vector to the list of groups the target user is in. When preservegroups is set, the user's existing group vector is left unaltered. The real and effective group IDs, however, are still set to match the target user. This flag is off by default.

pwfeedback
By default, sudo reads the password like most other Unix programs, by turning off echo until the user hits the return (or enter) key. Some users become confused by this as it appears to them that sudo has hung at this point. When pwfeedback is set, sudo will provide visual feedback when the user presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of the password being entered. This flag is off by default.

requiretty
If set, sudo will only run when the user is logged in to a real tty. When this flag is set, sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin scripts. This flag is off by default.

root_sudo
If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that turning off root_sudo will also prevent root from running sudoedit. Disabling root_sudo provides no real additional security; it exists purely for historical reasons. This flag is on by default.

rootpw
If set, sudo will prompt for the root password instead of the password of the invoking user. This flag is off by default.

runaspw
If set, sudo will prompt for the password of the user defined by the runas_default option (defaults to root) instead of the password of the invoking user. This flag is off by default.

set_home
If enabled and sudo is invoked with the -s option the HOME environment variable will be set to the home directory of the target user (which is root unless the -u option is used). This effectively makes the -s option imply -H. Note that HOME is already set when the the env_reset option is enabled, so set_home is only effective for configurations where either env_reset is disabled or HOME is present in the env_keep list. This flag is off by default.

set_logname
Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name of the target user (usually root unless the -u option is given). However, since some programs (including the RCS revision control system) use LOGNAME to determine the real identity of the user, it may be desirable to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option has not been disabled, entries in the env_keep list will override the value of set_logname. This flag is on by default.

setenv
Allow the user to disable the env_reset option from the command line. Additionally, environment variables set via the command line are not subject to the restrictions imposed by env_check, env_delete, or env_keep. As such, only trusted users should be allowed to set variables in this manner. This flag is off by default.

shell_noargs
If set and sudo is invoked with no arguments it acts as if the -s option had been given. That is, it runs a shell as root (the shell is determined by the SHELL environment variable if it is set, falling back on the shell listed in the invoking user's /etc/passwd entry if not). This flag is off by default.

stay_setuid
Normally, when sudo executes a command the real and effective UIDs are set to the target user (root by default). This option changes that behavior such that the real UID is left as the invoking user's UID. In other words, this makes sudo act as a setuid wrapper. This can be useful on systems that disable some potentially dangerous functionality when a program is run setuid. This option is only effective on systems with either the setreuid() or setresuid() function. This flag is off by default.

targetpw
If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead of the password of the invoking user. In addition, the timestamp file name will include the target user's name. Note that this flag precludes the use of a uid not listed in the passwd database as an argument to the -u option. This flag is off by default.

log_input
If set, sudo will run the command in a pseudo tty and log all user input. If the standard input is not connected to the user's tty, due to I/O redirection or because the command is part of a pipeline, that input is also captured and stored in a separate log file.

Input is logged to the /var/log/sudo-io directory using a unique session ID that is included in the normal sudo log line, prefixed with TSID=.

log_output
If set, sudo will run the command in a pseudo tty and log all output that is sent to the screen, similar to the script(1) command. If the standard output or standard error is not connected to the user's tty, due to I/O redirection or because the command is part of a pipeline, that output is also captured and stored in separate log files.

Output is logged to the /var/log/sudo-io directory using a unique session ID that is included in the normal sudo log line, prefixed with TSID=.

Output logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.

tty_tickets
If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will use a file named for the tty the user is logged in on in the user's time stamp directory. If disabled, the time stamp of the directory is used instead. This flag is on by default.

umask_override
If set, sudo will set the umask as specified by sudoers without modification. This makes it possible to specify a more permissive umask in sudoers than the user's own umask and matches historical behavior. If umask_override is not set, sudo will set the umask to be the union of the user's umask and what is specified in sudoers. This flag is @umask_override@ by default.

use_loginclass
If set, sudo will apply the defaults specified for the target user's login class if one exists. Only available if sudo is configured with the --with-logincap option. This flag is off by default.

use_pty
If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone. A malicious program run under sudo could conceivably fork a background process that retains to the user's terminal device after the main program has finished executing. Use of this option will make that impossible.

visiblepw
By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. This flag is off by default.

I'd like to break this down into components:

1. Concepts
 - talk about SUDO, SUDO wrt IPA, benefits, etc.

2. Tasks
 - Setting up SUDO, but not to the depth gone into above (i.e., don't include all the individual add-user, kinit, add-group commands). I might do it myself just to get a handle on it, but I'll document it more in round #2.

3. Reference
 - All the different options, flags, etc., could be omitted for now (assuming they're in the man page), and I'll add them (all of them?) to the Reference section of the doc later.

When 1. & 2. are done, get them signed off (publishable) and continue with more detailed material afterwards. There's a fair chunk of work here, so I don't want to commit to more than is possible (if I'm not already).

Jr Aquino, thanks for the detailed descriptions and instructions.

David

Can someone (jr Aquino?) elaborate on the following:

* How IPA addresses groups of computers
            Host groups and netgroups for purpose of SUDO - how they are 
            related (manged entries) and how they should be used with 
            examples.

I don't really know what this is trying to say.

thanks

(In reply to comment #3)
> Can someone (jr Aquino?) elaborate on the following:
> 
> * How IPA addresses groups of computers
>             Host groups and netgroups for purpose of SUDO - how they are 
>             related (manged entries) and how they should be used with 
>             examples.
> 
> I don't really know what this is trying to say.
> 
> thanks

SUDO rules define who can run what command on what machine. To refer to the machines SUDO uses netgroups. But IPA tries to steer people away from the netgroups and tries instead to suggest using groups of hosts as it is a better and cleaner grouping mechanism. The problem is that SUDO utility does not support host groups - it expects netgroups. To solve this issue and allow people to use better grouping mechanism on the server, i.e. host groups, IPA automatically creates a "shadow netgroup" with the same name for every hostgroup you create.  Effectively this means that one can create host groups but use netgroups with SUDO without breaking anything.

JR can you add more examples please?

Hosts/Machines

A host represents a machine. It can be used in a number of contexts:
- service entries are associated with a host
- a host stores the host/ service principal
- a host can be used in Host-Based Access Control (HBAC) rules
- every enrolled client generates a host entry

ENROLLMENT:

There are three enrollment scenarios when enrolling a new client:

1. You are enrolling as a full administrator. The host entry may exist
   or not. A full administrator is a member of the hostadmin role
   or the admins group.
2. You are enrolling as a limited administrator. The host must already
   exist. A limited administrator is a member of the enrollhost role.
3. The host has been created with a one-time password.

A host can only be enrolled once. If a client has enrolled and needs to
be re-enrolled, the host entry must be removed and re-created. Note that
re-creating the host entry will result in all services for the host being
removed, and all SSL certificates associated with those services being
revoked.

A host can optionally store information such as where it is located,
the OS that it runs, etc.

EXAMPLES:

 Add a new host:
   ipa host-add --location="3rd floor lab" --locality=Dallas test.example.com

 Delete a host:
   ipa host-del test.example.com

 Add a new host with a one-time password:
   ipa host-add --os='Fedora 12' --password=Secret123 test.example.com

 Add a new host with a random one-time password:
   ipa host-add --os='Fedora 12' --random test.example.com

 Modify information about a host:
   ipa host-mod --os='Fedora 12' test.example.com

 Disable the host Kerberos key, SSL certificate and all of its services:
   ipa host-disable test.example.com

 Add a host that can manage this host's keytab and certificate:
   ipa host-add-managedby --hosts=test2 test

Topic commands:
  host-add               Add a new host.
  host-add-managedby     Add hosts that can manage this host.
  host-del               Delete a host.
  host-disable           Disable the Kerberos key, SSL certificate and all services of a host.
  host-find              Search for hosts.
  host-mod               Modify information about a host.
  host-remove-managedby  Remove hosts that can manage this host.
  host-show              Display information about a host.

Groups of hosts.

Manage groups of hosts. This is useful for applying access control to a
number of hosts by using Sudo and/or Host-based Access Control.

EXAMPLES:

 Add a new host group:
   ipa hostgroup-add --desc="Baltimore hosts" baltimore

 Add another new host group:
   ipa hostgroup-add --desc="Maryland hosts" maryland

 Add members to the hostgroup:
   ipa hostgroup-add-member --hosts=box1,box2,box3 baltimore

 Add a hostgroup as a member of another hostgroup:
   ipa hostgroup-add-member --hostgroups=baltimore maryland

 Remove a host from the hostgroup:
   ipa hostgroup-remove-member --hosts=box2 baltimore

 Display a host group:
   ipa hostgroup-show baltimore

 Delete a hostgroup:
   ipa hostgroup-del baltimore

Topic commands:
  hostgroup-add            Add a new hostgroup.
  hostgroup-add-member     Add members to a hostgroup.
  hostgroup-del            Delete a hostgroup.
  hostgroup-find           Search for hostgroups.
  hostgroup-mod            Modify a hostgroup.
  hostgroup-remove-member  Remove members from a hostgroup.
  hostgroup-show           Display information about a hostgroup.

Initial outline and draft (minus reference material) is done but not visible yet. Still needs patches and cleanups before it's ready for anyone to look at.

Ongoing...

I've added basic procedures to all the outlines. Still need to go over and make sure they "add up" and are followable.

Questions:

Re:  3) Configure Client for SUDO
Only on the client, or on all machines?

* Configure SUDO to look to LDAP for SUDOers
        a. Add the following lines to /etc/nsswitch.conf:
            sudoers:    ldap


The following file does not exist on my install. Should I create it with the specified entries, or is it missing because I haven't installed and/or configured something (what)?

    * Edit the LDAP Configuration file for SUDO:
        a. Add the following to /etc/nss_ldap.conf:

/etc/ldap.conf doesn't exist either, btw, only /etc/openldap/ldap.conf

thanks

(In reply to comment #9)
> Questions:
> 
> Re:  3) Configure Client for SUDO
> Only on the client, or on all machines?
> 
> * Configure SUDO to look to LDAP for SUDOers
>         a. Add the following lines to /etc/nsswitch.conf:
>             sudoers:    ldap
> 
> 
> The following file does not exist on my install. Should I create it with the
> specified entries, or is it missing because I haven't installed and/or
> configured something (what)?
> 
>     * Edit the LDAP Configuration file for SUDO:
>         a. Add the following to /etc/nss_ldap.conf:
> 
> /etc/ldap.conf doesn't exist either, btw, only /etc/openldap/ldap.conf
> 
> thanks

Sudo has somewhat of a bad practice in that it piggy backs on config files that are generated by 3dparty packages.

If these file do not exist, please create them as they are documented, and everything should work as expected.

I've added all of the basic procedures to section 13.2.3. Sudo Policies

I haven't done an end-to-end test because I can't get NIS to work (I don't
speak NIS and I'm trying to focus on high priority things, so I'm relying on
the "please create them as they are documented, and everything should work as
expected" approach).

I'm currently working on the "options"; adding them as a reference at the end
of the section.

To clarify. "NIS" (The service) doesn't actually need to be configured on the client side. Nor really the Server side.

NIS objects are automatically created inside of LDAP and nss_ldap or sssd fetches them out via an encrypted ldap connection.

Native NIS is actually unencrypted, and uses rpc services to function. Not only is it unnecessary for it to be running, I might even consider it a security concern if it was.

"Create them as they are documented, and everything should work as expected" is likely a very good method for accomplishing the goal.

If you would like, I could provide a small writeup / explanation of how NIS objects get created in LDAP and why the NIS protocol / Service is unneeded?

- Notes on NIS via SSSD / NSS_LDAP -

Originally called Yellow Pages or YP, NIS was created by Sun Microsystems and stands for: Network Information Service.

NIS was primarly used by Unix to centrally manage authentication/enumeration information such as user/password, host/ip address, posix groups, netgroups.

NIS is an RPC service and is insecure by today's standards. 
* It has no host authentication mechanisms. 
* It transmits all of its information over the network unencrypted, including password hashes. 

Fortunately, modern Linux / BSD systems have Name Service Switch (NSS) which provides a means of controlling and directing lookups for authentication/enumeration information.

FreeIPA's LDAP implimentation provides the schema to support NIS as defined in RFC 2307.

Utilizing SSSD or NSS_LDAP, a client system can enumerate the necessary NIS information via authenticated and encrypted queries to the backend LDAP service provided by the FreeIPA Server.

This eliminates the need of NIS Client configuration for systems able to support NIS via LDAP when utliizing FreeIPA.

Thanks Jr

I'll go over this some more today, and add what I see as important bits where they fit before making the whole lot available for you (and anyone) to have another look at. At that stage you can make recommendations about what else needs to be included, clarified, removed, etc.

Jr,
what's the source of the Options doc provided in this bug? I'm especially interested in the noexec option, because it refers to "the NOEXEC tag", the "EXEC tag" and the "PREVENTING SHELL ESCAPES section at the end of this manual." none of which appear to exist.

I've had a poke around in man sudo, the ipa help sudorule pages, etc., but can't find where this might be coming from. Has it been copied from somewhere? Are there copyright issues I need to be aware of, and what are they?

thanks

The Options documentation is directly from the SUDOers Man page:
man sudoers

or

http://www.gratisoft.us/sudo/man/1.7.5/sudoers.man.html

The section in question is located:
http://www.gratisoft.us/sudo/man/1.7.5/sudoers.man.html#preventing_shell_escapes

Licensing: Man pages are interesting bodies.  It is not completely clear to me where they fall in terms of the standard SUDO license. When in doubt, included the license file <http://www.sudo.ws/sudo/license.html>  Is documentation software? 

PREVENTING SHELL ESCAPES
Once sudo executes a program, that program is free to do whatever it pleases, including run other programs. This can be a security issue since it is not uncommon for a program to allow shell escapes, which lets a user bypass sudo's access control and logging. Common programs that permit shell escapes include shells (obviously), editors, paginators, mail and terminal programs.

There are two basic approaches to this problem:

restrict
Avoid giving users access to commands that allow the user to run arbitrary commands. Many editors have a restricted mode where shell escapes are disabled, though sudoedit is a better solution to running editors via sudo. Due to the large number of programs that offer shell escapes, restricting users to the set of programs that do not is often unworkable.

noexec
Many systems that support shared libraries have the ability to override default library functions by pointing an environment variable (usually LD_PRELOAD) to an alternate shared library. On such systems, sudo's noexec functionality can be used to prevent a program run by sudo from executing any other programs. Note, however, that this applies only to native dynamically-linked executables. Statically-linked executables and foreign executables running under binary emulation are not affected.

To tell whether or not sudo supports noexec, you can run the following as root:

    sudo -V | grep "dummy exec"
If the resulting output contains a line that begins with:

    File containing dummy exec functions:
then sudo may be able to replace the exec family of functions in the standard library with its own that simply return an error. Unfortunately, there is no foolproof way to know whether or not noexec will work at compile-time. noexec should work on SunOS, Solaris, *BSD, Linux, IRIX, Tru64 UNIX, MacOS X, and HP-UX 11.x. It is known not to work on AIX and UnixWare. noexec is expected to work on most operating systems that support the LD_PRELOAD environment variable. Check your operating system's manual pages for the dynamic linker (usually ld.so, ld.so.1, dyld, dld.sl, rld, or loader) to see if LD_PRELOAD is supported.

To enable noexec for a command, use the NOEXEC tag as documented in the User Specification section above. Here is that example again:

 aaron  shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
This allows user aaron to run /usr/bin/more and /usr/bin/vi with noexec enabled. This will prevent those two commands from executing other commands (such as a shell). If you are unsure whether or not your system is capable of supporting noexec you can always just try it out and see if it works.

Note that restricting shell escapes is not a panacea. Programs running as root are still capable of many potentially hazardous operations (such as changing or overwriting files) that could lead to unintended privilege escalation.

d'oh

and here I am looking in man sudo.

Ok, this looks more and more like a case of "Refer to man sudo and man sudoers for more info", otherwise I'm just duplicating info.

I'm going to clean this up as best I can and post the result. Other things are demanding my attention.

Pushed c3f60d0..b0af01c  master -> master
git.fedorahosted.org/git/ipadocs.git

I'll build and publish shortly for everyone's perusal and criticism.

Latest build now available on http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/Enterprise_Identity_Management_Guide/index.html

Current version:
Red_Hat_Enterprise_Linux-Enterprise_Identity_Management_Guide-96-web-en-US-0.6-25.el5

The version on documentation stage has been updated, however you might notice something strange here:

13.2.3.1.3. Benefits of the IPA Alternative Schema

"Hostgroups and netgroups for the purpose of sudo."
This is an incomplete sentence but has been updated in the source to "The IPA alternative schema also addresses the issue of host groups and netgroups for the purpose of sudo."

This will be visible after the next build.

Current version on doc-stage:
Red_Hat_Enterprise_Linux-Enterprise_Identity_Management_Guide-96-web-en-US-0.7-26.el5

Hi, here are some feedbacks:

1. In Server Configuration (13.2.3.2.1) step 1b the command parameter should be "bne_doc" instead of "bne-doc".

2. In Server Configuration step 3 it might be better to clarify which password to enter at each prompt.

   # LDAPTLS_CACERT=/etc/ipa/ca.crt /usr/bin/ldappasswd -S -W -h ipaserver.ipadocs.org -ZZ \
   -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=ipadocs,dc=org
   New password: <sudo user's password>
   Re-enter new password: <sudo user's password>
   Enter LDAP Password: <Directory Manager's password>

3. In Client Configuration (13.2.3.2.2) step 2 the suffix should match the suffix used in server Configuration.

   ldap_netgroup_search_base = cn=ng,cn=compat,dc=ipadocs,dc=org

4. In Client Configuration step 3a it might be useful to mention about the optional sudoers_debug parameter to set the debugging level to help troubleshooting. Valid values are 0-2 (see http://www.gratisoft.us/sudo/readme_ldap.html).

Some nitpicks:

5. In Client Configuration step 3a the content of /etc/nss_ldap.conf starting from line 2 contains unnecessary indentation.

6. In Server Configuration step 1a, 2a and 3 the indentations don't quite match the actual output of the commands.

7. In both Server and Client Configuration sometimes # is used to indicate command prompt and some other times $ is used. It might be better to just use $ because # could be confused with comments.

The following items are not discussed in the docs, should they be included?
 - external users & hosts
 - allow & deny commands
 - run-as users & groups

(In reply to comment #23)
> Hi, here are some feedbacks:
> 
> 1. In Server Configuration (13.2.3.2.1) step 1b the command parameter should be
> "bne_doc" instead of "bne-doc".

Fixed.

> 
> 2. In Server Configuration step 3 it might be better to clarify which password
> to enter at each prompt.
> 
>    # LDAPTLS_CACERT=/etc/ipa/ca.crt /usr/bin/ldappasswd -S -W -h
> ipaserver.ipadocs.org -ZZ \
>    -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=ipadocs,dc=org
>    New password: <sudo user's password>
>    Re-enter new password: <sudo user's password>
>    Enter LDAP Password: <Directory Manager's password>

Fixed.

> 
> 3. In Client Configuration (13.2.3.2.2) step 2 the suffix should match the
> suffix used in server Configuration.
> 
>    ldap_netgroup_search_base = cn=ng,cn=compat,dc=ipadocs,dc=org

Fixed.

> 
> 4. In Client Configuration step 3a it might be useful to mention about the
> optional sudoers_debug parameter to set the debugging level to help
> troubleshooting. Valid values are 0-2 (see
> http://www.gratisoft.us/sudo/readme_ldap.html).

Done.

> 
> Some nitpicks:
> 
> 5. In Client Configuration step 3a the content of /etc/nss_ldap.conf starting
> from line 2 contains unnecessary indentation.

Fixed.

> 
> 6. In Server Configuration step 1a, 2a and 3 the indentations don't quite match
> the actual output of the commands.

Can't fix effectively without rerunning all the commands. Don't have time right now.

> 
> 7. In both Server and Client Configuration sometimes # is used to indicate
> command prompt and some other times $ is used. It might be better to just use $
> because # could be confused with comments.

Fixed.


wrt Comment 24, this will need to be addressed in the next release. Not accepting any requests for new material at this stage.


Setting to MODIFIED for now.

Will brew and push this update probably tomorrow morning (April 8)

Sorry, one more thing, in Client Configuration step 3 the binddn should be:

uid=sudo,cn=sysaccounts,cn=etc,dc=ipadocs,dc=org

and the bindpw should be the sudo user's password entered in Server Configuration step 3. Thanks!

(In reply to comment #26)
> Sorry, one more thing, in Client Configuration step 3 the binddn should be:
> 
> uid=sudo,cn=sysaccounts,cn=etc,dc=ipadocs,dc=org
> 
> and the bindpw should be the sudo user's password entered in Server
> Configuration step 3. Thanks!

Both of these fixed. Thanks.

Red_Hat_Enterprise_Linux-Enterprise_Identity_Management_Guide-96-web-en-US-0.7-30.el5

All of the above changes should be apparent, except where indicated. e.g., request for additional doc, reformatting command output, etc.

(In reply to comment #27)
> (In reply to comment #26)
> > Sorry, one more thing, in Client Configuration step 3 the binddn should be:
> > 
> > uid=sudo,cn=sysaccounts,cn=etc,dc=ipadocs,dc=org
> > 
> > and the bindpw should be the sudo user's password entered in Server
> > Configuration step 3. Thanks!
> 
> Both of these fixed. Thanks.

http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/Enterprise_Identity_Management_Guide/sect-Enterprise_Identity_Management_Guide-Setting_up_Sudo_Rules-Client_Configuration_for_Sudo_Rules.html

Red_Hat_Enterprise_Linux-Enterprise_Identity_Management_Guide-96-web-en-US-1.0-30.el5