#3980 sudorule matching when no host or hostcat set
Closed: Fixed 6 years ago by jhrozek. Opened 6 years ago by pbrezina.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 1686154

Description of problem:

An IPA User is allowed to use sudo via a rule even if hostcat is not set and no
host or hostgroup is specified.

[root@rhel8-3 sssd]# ipa sudorule-find --all
--------------------
2 Sudo Rules matched
--------------------
  dn: ipaUniqueID=3a149d22-401c-11e9-a1d8-525400161dcd,cn=sudorules,cn=sudo,dc=
example,dc=com
  Rule name: sudorule1
  Enabled: TRUE
  Users: user1
  External host: test.example.com
  Sudo Allow Command Groups: sudogrp1
  Sudo Option: !authenticate
  ipauniqueid: 3a149d22-401c-11e9-a1d8-525400161dcd
  objectclass: ipaassociation, ipasudorule

  dn: ipaUniqueID=ea1491f6-4020-11e9-b545-525400161dcd,cn=sudorules,cn=sudo,dc=
example,dc=com
  Rule name: sudorule2
  Enabled: TRUE
  Users: user2
  Sudo Allow Command Groups: sudogrp1
  ipauniqueid: ea1491f6-4020-11e9-b545-525400161dcd
  objectclass: ipaassociation, ipasudorule
----------------------------
Number of entries returned 2
----------------------------

[root@rhel8-3 sssd]# !ssh
ssh -l user2 $(hostname)
Password:
Last login: Wed Mar  6 11:08:24 2019 from 192.168.122.83

[user2@rhel8-3 ~]$ sudo -l
[sudo] password for user2:
Matching Defaults entries for user2 on rhel8-3:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS
    LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT
LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET
    XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User user2 may run the following commands on rhel8-3:
    (root) /bin/mkdir

^^^
Here I expected to see:

Sorry, user user2 may not run sudo on rhel8-3.

Version-Release number of selected component (if applicable):
sssd-client-2.0.0-43.el8.x86_64


How reproducible:
Seems consistent.  Was seen in a test and was reproduced manually.

Steps to Reproduce:
1.  Install IPA Server
2.  Setup sudorule for user without host/hostgroup

ipa user-add user2 --first=f --last=l --password
kinit user2
kdestroy -A
kinit admin
ipa sudorule-add sudorule2
ipa sudocmd-add /bin/mkdir
ipa sudocmdgroup-add sudogrp1 --desc=sudogrp1
ipa sudocmdgroup-add-member sudogrp1 --sudocmds=/bin/mkdir
ipa sudorule-add-allow-command --sudocmdgroups=sudogrp1 sudorule2
ipa sudorule-add-user sudorule2 --users=user2

3.  sudo as user first time without host

ssh -l user2 $(hostname)
sudo -l

4.  Add hostgroup to sudorule and reset sssd

ipa hostgroup-add hostgrp1
ipa hostgroup-add-member hostgrp1 --hosts=$(hostname)
ipa sudorule-add-host sudorule2 --hostgroup=hostgrp1
systemctl stop sssd; sss_cache -E; systemctl start sssd

5.  sudo as user second time with host

ssh -l user2 $(hostname)
sudo -l

6.  remove hostgroup from rule and reset sssd

ipa sudorule-remove-host sudorule2 --hostgroup=hostgrp1
systemctl stop sssd; sss_cache -E; systemctl start sssd

7.  sudo as user third time with host removed from rule

ssh -l user2 $(hostname)
sudo -l


Actual results:

sudo as user third time (7.) works and shows list of commands that are
available to run with sudo.

Expected results:

sudo failed with error message about not permitted.

Additional info:

It appears that the first time without the host info is the only time that it
rejects the attempt.  After adding and removing the host, it passes when we
expect it to fail.

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1686154

6 years ago
master: 3b0ff29
sssd-1-16: e2f00ae

Metadata Update from @jhrozek:
- Issue assigned to pbrezina
- Issue close_status updated to: Fixed
- Issue set to the milestone: SSSD 2.2
- Issue status updated to: Closed (was: Open)
- Issue tagged with: bug

6 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4952

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Log in to comment on this ticket.

Metadata