#3376 root user unable to access users kerberos cache from KCM backend
Closed: wontfix 4 years ago by pbrezina. Opened 6 years ago by jhrozek.

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

6 years ago

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

6 years ago

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

6 years ago

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.

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)?

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).

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.

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 :-) :-) :-)

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

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.

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

6 years ago

Metadata Update from @jhrozek:
- Issue priority set to: minor

6 years ago

Metadata Update from @jhrozek:
- Issue tagged with: cleanup-one-sixteen

6 years ago

Metadata Update from @jhrozek:
- Issue untagged with: cleanup-one-sixteen
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)

6 years ago

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)

6 years ago

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

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

6 years ago

Metadata Update from @jhrozek:
- Issue untagged with: postpone-to-2-0
- Issue set to the milestone: SSSD 2.0 (was: SSSD 1.16.1)

6 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 2.1 (was: SSSD 2.0)

5 years ago

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)

5 years ago

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)

4 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/4405

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