Bug 711693

https://fedorahosted.org/freeipa/ticket/1313

Access to sudo objects can be now controlled via managed permissions. The default is to allow read access to all authenticated users, but it can be also restricted only to a group of users. See

https://fedorahosted.org/freeipa/ticket/3566

for details. To allow them only for all hosts only, a hostgroup with all hosts would need to be created first.

Using ipa-server-4.1.0-15.el7.x86_64

User two can see sudorules which are set up for user one

# ipa user-add one
First name: one
Last name: one
----------------
Added user "one"
----------------
  User login: one
  First name: one
  Last name: one
  Full name: one one
  Display name: one one
  Initials: oo
  Home directory: /home/one
  GECOS: one one
  Login shell: /bin/sh
  Kerberos principal: one
  Email address: one
  UID: 1453400006
  GID: 1453400006
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False


# ipa sudorule-add rule1
-----------------------
Added Sudo Rule "rule1"
-----------------------
  Rule name: rule1
  Enabled: TRUE


# ipa sudorule-add-user --users=one rule1
  Rule name: rule1
  Enabled: TRUE
  Users: one
-------------------------
Number of members added 1
-------------------------



# ipa sudocmd-add /bin/mkdir
-------------------------------
Added Sudo Command "/bin/mkdir"
-------------------------------
  Sudo Command: /bin/mkdir


# ipa sudorule-add-allow-command --sudocmds=/bin/mkdir rule1
  Rule name: rule1
  Enabled: TRUE
  Users: one
  Sudo Allow Commands: /bin/mkdir
-------------------------
Number of members added 1
-------------------------



# ipa user-add two
First name: two
Last name: two
----------------
Added user "two"
----------------
  User login: two
  First name: two
  Last name: two
  Full name: two two
  Display name: two two
  Initials: tt
  Home directory: /home/two
  GECOS: two two
  Login shell: /bin/sh
  Kerberos principal: two
  Email address: two
  UID: 1453400007
  GID: 1453400007
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False

# kdestory -A

# kinit two
Password for two: 
[root@qeblade6 ~]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_54IpXJy
Default principal: two

Valid starting       Expires              Service principal
01/23/2015 08:41:22  01/24/2015 08:41:19  krbtgt/TESTRELM.TEST


# ipa sudorule-find --all --raw
-------------------
1 Sudo Rule matched
-------------------
  dn: ipaUniqueID=ed237556-a303-11e4-9b27-00215e860834,cn=sudorules,cn=sudo,dc=testrelm,dc=test
  cn: rule1
  ipaenabledflag: TRUE
  memberuser: uid=one,cn=users,cn=accounts,dc=testrelm,dc=test
  ipaUniqueID: ed237556-a303-11e4-9b27-00215e860834
  memberallowcmd: ipaUniqueID=3c48404e-a304-11e4-9b27-00215e860834,cn=sudocmds,cn=sudo,dc=testrelm,dc=test
  objectClass: ipasudorule
  objectClass: ipaassociation
----------------------------
Number of entries returned 1
----------------------------


Same behaviour as reported as bz, right? Or am I missing something here?

It was decided, that all authenticated users should be able to read the SUDO rules *by default*.

In FreeIPA 4.0+ you can, however, choose to change this configuration and only enabling people with the assigned permission to read them. These are the new ACIs/permissions related to read access to SUDO:

# ipa permission-find "read sudo"
---------------------
4 permissions matched
---------------------
  Permission name: System: Read Sudo Command Groups
  Granted rights: read, compare, search
  Effective attributes: businesscategory, cn, createtimestamp, description, entryusn, ipauniqueid,
                        member, memberhost, memberuser, modifytimestamp, o, objectclass, ou, owner,
                        seealso
  Default attributes: cn, businesscategory, objectclass, description, memberuser, o, member,
                      ipauniqueid, owner, ou, memberhost, seealso
  Bind rule type: all
  Subtree: cn=sudocmdgroups,cn=sudo,dc=mkosek-f21,dc=test
  Type: sudocmdgroup

  Permission name: System: Read Sudo Commands
  Granted rights: read, compare, search
  Effective attributes: createtimestamp, description, entryusn, ipauniqueid, memberof, modifytimestamp,
                        objectclass, sudocmd
  Default attributes: objectclass, memberof, ipauniqueid, sudocmd, description
  Bind rule type: all
  Subtree: cn=sudocmds,cn=sudo,dc=mkosek-f21,dc=test
  Type: sudocmd

  Permission name: System: Read Sudo Rules
  Granted rights: read, compare, search
  Effective attributes: cmdcategory, cn, createtimestamp, description, entryusn, externalhost,
                        externaluser, hostcategory, hostmask, ipaenabledflag, ipasudoopt, ipasudorunas,
                        ipasudorunasextgroup, ipasudorunasextuser, ipasudorunasextusergroup,
                        ipasudorunasgroup, ipasudorunasgroupcategory, ipasudorunasusercategory,
                        ipauniqueid, member, memberallowcmd, memberdenycmd, memberhost, memberuser,
                        modifytimestamp, objectclass, sudonotafter, sudonotbefore, sudoorder,
                        usercategory
  Default attributes: sudonotafter, cn, hostmask, memberdenycmd, memberallowcmd, sudonotbefore,
                      ipasudorunas, cmdcategory, ipasudoopt, memberhost, externaluser, usercategory,
                      ipasudorunasextuser, member, ipasudorunasextusergroup, description,
                      ipasudorunasusercategory, hostcategory, ipauniqueid, ipaenabledflag,
                      ipasudorunasgroup, sudoorder, ipasudorunasgroupcategory, ipasudorunasextgroup,
                      memberuser, objectclass, externalhost
  Bind rule type: all
  Subtree: cn=sudorules,cn=sudo,dc=mkosek-f21,dc=test
  Type: sudorule

  Permission name: System: Read Sudoers compat tree
  Granted rights: read, compare, search
  Effective attributes: cn, createtimestamp, description, entryusn, modifytimestamp, objectclass, ou,
                        sudocommand, sudohost, sudonotafter, sudonotbefore, sudooption, sudoorder,
                        sudorunas, sudorunasgroup, sudorunasuser, sudouser
  Default attributes: sudonotafter, description, sudouser, cn, objectclass, sudooption, sudocommand,
                      sudonotbefore, sudorunas, sudorunasuser, sudohost, ou, sudoorder, sudorunasgroup
  Bind rule type: anonymous
  Subtree: dc=mkosek-f21,dc=test
  Target DN: ou=sudoers,dc=mkosek-f21,dc=test
----------------------------
Number of entries returned 4
----------------------------

Given this is by design, moving back ON_QA.

Verified using ipa-server-4.1.0-16.el7.x86_64

Steps taken to change the default configuration, and enable only people with assigned permission to read sudo rules:
# ipa user-add one --first=one --last=one --password
# ipa user-add four --first=four --last=four --password
# ipa permission-mod "System: Read Sudo Rules" --bindtype=permission
# ipa privilege-add-permission --permissions="System: Read Sudo Rules" read_sudo_rules
# ipa role-add sudo_rule_reader
# ipa role-add-privilege --privilege=read_sudo_rules sudo_rule_reader
# ipa role-add-member --users=four sudo_rule_reader
# kinit four
# ipa sudorule-find
--------------------
2 Sudo Rules matched
--------------------
  Rule name: rule1
  Enabled: TRUE
  Host category: all
  Users: two
  Sudo Allow Commands: /bin/mkdir
  RunAs External Group: nkgrpone

  Rule name: rule_for_external_group
  Enabled: TRUE
  Users: two
  User Groups: externalgroup1
----------------------------
Number of entries returned 2
----------------------------

# kdestroy -A
# kinit one
# ipa sudorule-find
--------------------
0 Sudo Rules matched
--------------------
----------------------------
Number of entries returned 0
----------------------------

Looks good. Just note that while this change is possible with the new permission system, I do not recommend users doing this change.

When
https://fedorahosted.org/sssd/ticket/1108
is fixed, SSSD will read IPA native SUDO rules and commands. If the host/ipa.client.example.test is not able to read them because they are restricted to only selected users, SUDO will not work on the clients.

The solution is then to either add the host/* principals to the new role or keep it on "authenticated" access.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0442.html