freeipa

#9650 Sudo Rule Grants Full Access When Host is Removed, Despite Empty Host List
Opened by patryk4815. Modified

Open
Close Issue

When a host is removed from a Sudo rule, and the host list is left empty, the user unexpectedly gains full sudo access to all hosts specified in the HBAC rule. This behavior is contrary to the expected outcome, where the user should have no sudo access since the host list is empty.

Steps to Reproduce

  1. Create an HBAC rule with the 'Access this host' option, including 1 to 10 hostnames.
  2. Create a Sudo rule with the 'Access this host' option, and specify server number 4, as the user should only have sudo privileges on this one server.
  3. After some time, remove server number 4 from the network or system.
  4. Observe that the Sudo rule now has an empty host list.
  5. At this point, the user gains full sudo access across all 9 servers listed in the HBAC rule, despite the Sudo rule having an empty host list.

Expected Behavior

When the host list in a Sudo rule is empty, the user should not have sudo access to any servers. The current behavior, where the user gains full access to all hosts listed in the HBAC rule, is unexpected and poses a security risk.

Actual Behavior

The user receives full sudo access to all servers listed in the HBAC rule, even though the Sudo rule’s host list is empty.

Hi,

thank you for the report. Can you add the output of ipa sudorule-show --all -raw your_sudo_rule_name before and after removing the host?

bye,
Sumit

Before:

$ ipa sudorule-show --all --raw %team_foo_sudo
  dn: ipaUniqueID=97a37106-28e7-11eb-b46f-02420a203611,cn=sudorules,cn=sudo,dc=foo,dc=com
  cn: %team_foo_sudo
  description: Team Foo
  ipaenabledflag: TRUE
  cmdcategory: all
  ipasudoopt: !authenticate
  memberhost: fqdn=some-server.foo.com,cn=computers,cn=accounts,dc=foo,dc=com
  memberuser: cn=team_foo,cn=groups,cn=accounts,dc=foo,dc=com
  ipaUniqueID: 97a37106-28e7-11eb-b46f-02420a203611
  objectClass: ipaassociation
  objectClass: ipasudorule

After:

$ ipa sudorule-show --all --raw %team_foo_sudo
  dn: ipaUniqueID=97a37106-28e7-11eb-b46f-02420a203611,cn=sudorules,cn=sudo,dc=foo,dc=com
  cn: %team_foo_sudo
  description: Team Foo
  ipaenabledflag: TRUE
  cmdcategory: all
  ipasudoopt: !authenticate
  memberuser: cn=team_foo,cn=groups,cn=accounts,dc=foo,dc=com
  ipaUniqueID: 97a37106-28e7-11eb-b46f-02420a203611
  objectClass: ipaassociation
  objectClass: ipasudorule

I think it is a bug in IPA commands that a rule is left without either memberhost or hostcategory attributes. This is what we can fix here but it is hardly a security issue in itself as you have to have admin rights to modify SUDO rules.

However, actual decision on the rule is made by SUDO, after SSSD downloads the rule and passes it to SUDO. So we have here a potentially incorrect rule (without either memberhost or hostcategory) and SSSD should probably reject (filter out) it.

I think a separate bug needs to be open for SSSD.

@abbra Nobody removed the host from sudo rule directly. We removed the host from the ipa system completely. We didn't think removing host from system will grant full access

Edited by patryk4815

@patryk4815 I understand. memberof plugin in 389-ds did remove the reference to removed LDAP object. There is nothing IPA management tools can do in that case but we can at least do checks in the management code.

The actual bug in this case is in SSSD code where it should make a defensive default ("no members in the rule and no hostcategory=all => rule does not apply"). A bug is needed for SSSD which should be created at https://github.com/SSSD/sssd/issues.

We still need to cover the case of ipa sudorule-remove-host to trigger hostcategory=all to be added. Or prevent removing the last host? And, perhaps, a healthcheck rule to find SUDO rules without hostcategory=all and without memberhosts.

Maybe removing last host from sudorule should imply removing sudorule itself?
And prevent creating empty sudorule without specifying hosts (checkbox hostcategory false)

Hi,

feel free to open a ticket for SSSD at https://github.com/SSSD/sssd/issues. So far I was not able to reproduce the issue and when SSSD is reading the sudo rules from LDAP there is a search filter which should filter out rules which neither have memberhost nor hostcategory set.

If possible, please add SSSD debug logs with debug_level = 9 in the [domain/...] and [sudo] sections of sssd.conf from a host which it not deleted. Ideally the logs should cover the state when the to be removed hosts is still present and sudo if failing and the state after the removal when sudo starts working on the unexpected host.

Thanks.

bye,
Sumit
Metadata
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.