Learn more about these different git repos.
Other Git URLs
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 } MYDOMAIN.COM = { kdc = kerberos... kdc = kerberos... kdc = kerberos.... admin_server = kerberos.... default_domain = ... } [domain_realm] example.test = EXAMPLE.TEST .example.test = EXAMPLE.TEST .mydomain.com = ... mydomain.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:
Metadata Update from @jhrozek: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1441764
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 ...)
Metadata Update from @lslebodn: - Issue set to the milestone: None
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.
It is possible even from CLI. Root just need to use su
su
What do you mean by "retrieving peer's capabilities"? Do you mean linux capabilities (man 7 capabilities)?
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).
+1 for conditional and default false.
I cannot see allowe CAP_DAC_OVERRIDE in fedora 26 SELinux policy for gssproxy. But I can see allowed CAP_SETUID and CAP_SETGID.
CAP_DAC_OVERRIDE
CAP_SETUID
CAP_SETGID
Of course it will not use su if it can use setuid/setgid :-) :-) :-)
setuid/setgid
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.
sealert
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD 1.15.4
Metadata Update from @jhrozek: - Issue priority set to: minor
Metadata Update from @jhrozek: - Issue tagged with: cleanup-one-sixteen
Metadata Update from @jhrozek: - Issue untagged with: cleanup-one-sixteen - Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)
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
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD 1.16.1 (was: SSSD 1.16.0)
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
Sigh, that's what I get for not checking. Carry on.
Metadata Update from @jhrozek: - Issue tagged with: KCM, postpone-to-2-0
Metadata Update from @jhrozek: - Issue untagged with: postpone-to-2-0 - Issue set to the milestone: SSSD 2.0 (was: SSSD 1.16.1)
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD 2.1 (was: SSSD 2.0)
https://github.com/SSSD/sssd/pull/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.
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD Patches welcome (was: SSSD 2.1)
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.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/4405
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.