#2300 RHEL7 IPA selinuxusermap hbac rule not always matching
Closed: Fixed None Opened 10 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1082191

Description of problem:

IPA selinuxusermap entries using HBAC rules are not always properly matching.
I'm seeing the first lookup/connection fail often in automated tests and follow
up ones work.

In manual tests, I may have to run a test a few times before I see the failure.
Is there something going on with the id -Z check that is caugin

[root@ipaqa64vme ~]# ssh -l user3_1 ipaqa64vmc.testrelm.test 'id -Z'
staff_u:staff_r:staff_t:s0-s0:c0.c1023

[root@ipaqa64vme ~]# ssh -l user3_1 ipaqa64vmc.testrelm.test 'id -Z'
staff_u:staff_r:staff_t:s0-s0:c0.c1023

[root@ipaqa64vme ~]# ssh -l user3_1 ipaqa64vmc.testrelm.test 'id -Z'
staff_u:staff_r:staff_t:s0-s0:c0.c1023

[root@ipaqa64vme ~]# ssh -l user3_1 ipaqa64vmc.testrelm.test 'id -Z'
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[root@ipaqa64vmc ~]# ipa selinuxusermap-show --all
Rule name: ^C
ipa: ERROR: Could not get Rule name interactively
[root@ipaqa64vmc ~]# ipa selinuxusermap-find --all
--------------------------
1 SELinux User Map matched
--------------------------
  dn: ipaUniqueID=c3b7ac90-b6c4-11e3-ac49-021016980186,cn=usermap,cn=selinux,dc
=testrelm,dc=test
  Rule name: selinuxusermap3_1
  SELinux User: staff_u:s0-s0:c0.c1023
  HBAC Rule: hbacrule3_1
  Enabled: TRUE
  ipauniqueid: c3b7ac90-b6c4-11e3-ac49-021016980186
  objectclass: ipaassociation, ipaselinuxusermap
Number of entries returned 1
----------------------------
[root@ipaqa64vmc ~]# ipa hbacrule-find --all
--------------------
2 HBAC rules matched
--------------------
  dn:
ipaUniqueID=4183ace4-b6c2-11e3-aaa2-021016980186,cn=hbac,dc=testrelm,dc=test
  Rule name: allow_all
  User category: all
  Host category: all
  Service category: all
  Description: Allow all users to access any host from any host
  Enabled: FALSE
  accessruletype: allow
  ipauniqueid: 4183ace4-b6c2-11e3-aaa2-021016980186
  objectclass: ipaassociation, ipahbacrule

  dn:
ipaUniqueID=c021a5ea-b6c4-11e3-b738-021016980186,cn=hbac,dc=testrelm,dc=test
  Rule name: hbacrule3_1
  Enabled: TRUE
  Users: user3_1
  Hosts: ipaqa64vmc.testrelm.test
  Services: sshd
  accessruletype: allow
  ipauniqueid: c021a5ea-b6c4-11e3-b738-021016980186
  objectclass: ipaassociation, ipahbacrule
----------------------------
Number of entries returned 2
----------------------------

Version-Release number of selected component (if applicable):
ipa-server-3.3.3-27.el7.x86_64
sssd-1.11.2-63.el7.x86_64

How reproducible:
frequently but, not consistent.

Steps to Reproduce:

1.  Setup IPA Server

2.  Setup IPA Client

3.  Add IPA user and set kerberos password

echo 'Secret123'|kinit admin
echo -e 'password\npassword'|ipa user-add testuser1 --first=f --last=l
--password
echo -e 'password\nSecret123\nSecret123'|kinit testuser1

4.  Add HBAC Rule to allow user to log into IPA Client:

echo 'Secret123'|kinit admin
ipa hbacrule-add testhbac1
ipa hbacrule-add-user testhbac1 --users=testuser1
ipa hbacrule-add-host testhbac1 --hosts=$CLIENT
ipa hbacrule-add-service testhbac1 --hbacsvcs=sshd

5.  Add SELinux User Mapping rule:

ipa selinuxusermap-add testselinux1 --selinuxuser="staff_u:s0-s0:c0.c1023"
--hbacrule=testhbac1

6.  Check SELinux User Mapping via SSH:

echo 'Secret123'|kinit testuser1
ssh -l testuser1 $CLIENT id -Z

Actual results:

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Expected results:

staff_u:staff_r:staff_t:s0-s0:c0.c1023

Additional info:

Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
owner: somebody => jhrozek
patch: 0 => 1
review: True => 0
selected: =>
status: new => assigned
testsupdated: => 0

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11.5

resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.11.5

7 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/3342

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.

Login to comment on this ticket.

Metadata