#3376 root user unable to access users kerberos cache from KCM backend

Created 3 months ago by jhrozek
Modified 3 months ago

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:
3 months ago

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

3 months ago

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

3 months ago

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.

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.

Edited 3 months ago by lslebodn

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.

Edited 3 months ago by lslebodn
3 months ago

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

Login to comment on this ticket.

https://bugzilla.redhat.com/show_bug.cgi?id=1441764

cancel