root user unable to access users kerberos cache from KCM backend

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3376

• Created at 2017-04-19 21:50:40 by jhrozek
• Closed at 2020-03-24 14:15:49 as wontfix
• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1441764

---

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

Description of problem:

root user is unable to access normal users credential cache from KCM backend



Version-Release number of selected component (if applicable):
sssd-1.15.2-12.el7.x86_64
sssd-krb5-common-1.15.2-12.el7.x86_64
sssd-krb5-1.15.2-12.el7.x86_64
krb5-devel-1.15.1-7.el7.x86_64
krb5-libs-1.15.1-7.el7.x86_64
krb5-server-1.15.1-7.el7.x86_64
krb5-workstation-1.15.1-7.el7.x86_64
pam_krb5-2.4.8-6.el7.x86_64
sssd-kcm-1.15.2-12.el7.x86_64



Steps to Reproduce:
1. Configure RHEL7.4 system to authenticate to kerberos
2. Modify /etc/krb5.conf to use kcm
[libdefaults]
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = EXAMPLE.TEST
 default_ccache_name = KCM:

[realms]
 EXAMPLE.TEST = {
  kdc = idm1.example.test
  admin_server = idm1.example.test
}
  REDHAT.COM = {
  kdc = kerberos01.core.prod.int.sin2.redhat.com.:88
  kdc = kerberos01.core.prod.int.phx2.redhat.com.:88
  kdc = kerberos.rdu.redhat.com.:88
  admin_server = kerberos.corp.redhat.com.:749
  default_domain = redhat.com
}


[domain_realm]
 example.test = EXAMPLE.TEST
 .example.test = EXAMPLE.TEST
.redhat.com = REDHAT.COM
redhat.com = REDHAT.COM

[appdefaults]
validate = true

3. Login as non root user  (user1)

[user1@idm1 ~]$ klist
Ticket cache: KCM:14583100
Default principal: user1@EXAMPLE.TEST

Valid starting       Expires              Service principal
04/12/2017 21:31:42  04/13/2017 21:31:42  krbtgt/EXAMPLE.TEST@EXAMPLE.TEST
[user1@idm1 ~]$ id
uid=14583100(user1) gid=14564100(ldapusers) groups=14564100(ldapusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[user1@idm1 ~]$

4. From another terminal , access user1 ccache using command
[root@idm1 ~]# KRB5CCNAME=KCM:14583100  klist
klist: No credentials cache found



Actual results:
klist: No credentials cache found

Expected results:
klist should show user1's ccache.

Additional info:

Comments

---

Comment from jhrozek at 2017-04-19 21:50:42

Metadata Update from @jhrozek:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1441764

---

Comment from jhrozek at 2017-04-19 21:50:42

Metadata Update from @jhrozek:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1441764

---

Comment from lslebodn at 2017-04-20 06:35:15

I would prefer to close it as not a bug. Root has the CAP_SETUID capability and therefore can get any KCM ticket. (using setuid()/su ...)

---

Comment from lslebodn at 2017-04-20 06:35:17

Metadata Update from @lslebodn:

• Issue set to the milestone: None

---

Comment from jhrozek at 2017-04-26 22:38:24

From the CLI, sure, but it might also be beneficial for an app running as root to list other ccaches (just like it would for FILE).

That said, maybe retrieving peer's capabilities instead of UID might be also a good idea.

---

Comment from lslebodn at 2017-04-26 23:03:26

From the CLI, sure, but it might also be beneficial for an app running as root to list other ccaches (just like it would for FILE).

It is possible even from CLI. Root just need to use su

That said, maybe retrieving peer's capabilities instead of UID might be also a good idea.

What do you mean by "retrieving peer's capabilities"?
Do you mean linux capabilities (man 7 capabilities)?

---

Comment from simo at 2017-04-26 23:12:20

su is easy on the shell, but it is not something you can do to an application that runs as root but you figure out tyhat operationally it needs to access a different user cache.

For example GSS-Proxy will have this need and will not use su in some case, but relies on DAC_OVERRIDE to access user owned ccache files.

There are valid reasons to allow the root user to access other uid owned data, although I think this should be conditional (default configuration should probably not allow it).

---

Comment from lslebodn at 2017-04-26 23:33:47

There are valid reasons to allow the root user to access other uid owned data, although I think this should be conditional (default configuration should probably not allow it).

+1 for conditional and default false.

---

Comment from lslebodn at 2017-04-26 23:46:37

For example GSS-Proxy will have this need and will not use su in some case, but relies on DAC_OVERRIDE to access user owned ccache files.

I cannot see allowe CAP_DAC_OVERRIDE in fedora 26 SELinux policy for gssproxy. But I can see allowed CAP_SETUID and CAP_SETGID.

Of course it will not use su if it can use setuid/setgid :-) :-) :-)

---

Comment from simo at 2017-04-26 23:58:56

Looks like a bug in the SELinux policy, can you open a bugzilla ?

---

Comment from lslebodn at 2017-04-27 00:12:52

Looks like a bug in the SELinux policy, can you open a bugzilla ?

Usual workflow is enable setroubleshoot-server. Reproduce AVC in enforcing mode; then in permissive mode and report. Either via GUI "SELinux trobleshooter" or manually from command line using sealert. But I do not know how to reproduce such AVC with gssproxy. If you want I can open a ticket in pagure.io/gssproxy to file one in fedora with reasonable details or better with steps to reproduce.

---

Comment from jhrozek at 2017-04-28 14:48:31

Metadata Update from @jhrozek:

• Issue set to the milestone: SSSD 1.15.4

---

Comment from jhrozek at 2017-08-18 16:39:15

Metadata Update from @jhrozek:

• Issue priority set to: minor

---

Comment from jhrozek at 2017-08-18 17:48:05

Metadata Update from @jhrozek:

• Issue tagged with: cleanup-one-sixteen

---

Comment from jhrozek at 2017-08-23 17:21:43

Metadata Update from @jhrozek:

• Issue untagged with: cleanup-one-sixteen
• Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)

---

Comment from jhrozek at 2017-10-19 20:33:25

Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1

---

Comment from jhrozek at 2017-10-19 20:33:28

Metadata Update from @jhrozek:

• Issue set to the milestone: SSSD 1.16.1 (was: SSSD 1.16.0)

---

Comment from rharwood at 2017-11-10 20:08:07

I believe this is the behavior with KEYRING caches as well - why does KCM need to be able to do this?

---

Comment from lslebodn at 2017-11-10 20:18:29

I believe this is the behavior with KEYRING caches as well - why does KCM need to be able to do this?

It is allowed with KEYRING ccache

sh# klist 
klist: No credentials cache found

sh# id -u
0

sh# KRB5CCNAME=KEYRING:persistent:1000 klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: lslebodn@EXAMPLE.COM

Valid starting       Expires              Service principal
11/10/2017 15:00:41  11/11/2017 01:00:41  krbtgt/EXAMPLE.COM@EXAMPLE.COM

---

Comment from rharwood at 2017-11-10 20:36:17

Sigh, that's what I get for not checking. Carry on.

---

Comment from jhrozek at 2017-12-18 20:30:37

Metadata Update from @jhrozek:

• Issue tagged with: KCM, postpone-to-2-0

---

Comment from jhrozek at 2018-01-08 18:21:02

Metadata Update from @jhrozek:

• Issue untagged with: postpone-to-2-0
• Issue set to the milestone: SSSD 2.0 (was: SSSD 1.16.1)

---

Comment from jhrozek at 2018-08-13 11:02:13

Metadata Update from @jhrozek:

• Issue set to the milestone: SSSD 2.1 (was: SSSD 2.0)

---

Comment from sbose at 2018-12-12 08:35:33

#713 has a patch which fixes the user switching of krb5_child during Smartcard based authentication (pkinit) so that the ccache is written with user credentials.

---

Comment from jhrozek at 2018-12-17 21:32:14

Metadata Update from @jhrozek:

• Issue set to the milestone: SSSD Patches welcome (was: SSSD 2.1)

---

Comment from pbrezina at 2020-03-24 14:15:48

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

---

Comment from pbrezina at 2020-03-24 14:15:50

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)