Bug 1324486

Summary:	pam_sss set KRB5CCNAME with sudo logins
Product:	Red Hat Enterprise Linux 7	Reporter:	Mark <mark.a.sloan>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Amith <apeetham>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	grajaiya, jhrozek, kludhwan, lslebodn, mkosek, mzidek, pbrezina, sssd-qe
Target Milestone:	rc
Target Release:	7.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.15.0-2.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1329378 (view as bug list)		Environment:
Last Closed:	2017-08-01 08:58:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1329378, 1402591

Description Mark 2016-04-06 13:00:25 UTC

Description of problem:

repost of: https://fedorahosted.org/sssd/ticket/2296

because it's affecting a number of my enviroments and I can't find it in RH bugzilla. Applogies if this is a duplicate.

"
when running sudo -i pam_sss still sets the KRB5CCNAME environment variable of the user that was used for authentication. It should not set the environment variable for sudo cases or should be optionally configurable by the admin.

Otherwise with sudo -i root is given the ccache of the user, a kdestroy will wipe the user's ccache and any operation as root may change the ccache permissions or otherwise race with user processes.

This is not a security issue as the user ccache is the cache of the originating user, so nothing is really leaked, but it may cause issues and should be fixed.
"

Version-Release number of selected component (if applicable):

How reproducible:

100%.

Steps to Reproduce:
1. use pam_sss, login using a password that checks an external source.
2. sudo to another non-root user (e.g. sudo -iu myuser)
3. attempt to kinit

Actual results:

sudo to another user:
[~]$ sudo -iu someprinc

kinit -p someprinc
Password for someprinc@MITKDC:
[someprinc@ash-03-08-vm6 ~]$ klist
klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_10279_YQSYbA)

permissions are still set for the user&&group prior to running sudo.

[someprinc@someplace ~]$ ll /tmp/krb5cc_10279_YQSYbA
-rw-------. 1 msloan msloan 1438 Apr 6 08:46 /tmp/krb5cc_10279_YQSYbA

[someprinc@someplace ~]$ klist
klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_10279_YQSYbA)

the credential cache file will be set incorrectly. and permissions will fail.

Expected results:

credential cache should be set correctly after sudo'ing ..etc

Additional info:

Comment 2 Jakub Hrozek 2016-04-07 11:20:02 UTC

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2296

Comment 3 Jakub Hrozek 2016-04-07 11:46:52 UTC

Does just running sudo -i remove the ccache in your test or do you actually need to run kdestroy as root?

I can't reproduce the issue, though:

[vagrant@centos6 ~]$ su - admin
Password: 
su: warning: cannot change directory to /home/admin: No such file or directory
-bash-4.1$ klist 
Ticket cache: FILE:/tmp/krb5cc_1207000000_4Ng4rz
Default principal: admin

Valid starting     Expires            Service principal
04/07/16 11:44:10  04/08/16 11:44:10  krbtgt/IPA.TEST
-bash-4.1$ sudo -i
[root@centos6 ~]# klist 
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
[root@centos6 ~]# logout
-bash-4.1$ klist 
Ticket cache: FILE:/tmp/krb5cc_1207000000_4Ng4rz
Default principal: admin

Valid starting     Expires            Service principal
04/07/16 11:44:10  04/08/16 11:44:10  krbtgt/IPA.TEST
-bash-4.1$ 

What am I doing differently than you?

Comment 4 Mark 2016-04-08 18:08:47 UTC

it does not appear that running sudo -i will unset the KRB5CCNAME; as such it remains after sudo -i. 

I didn't open the upstream ticket, just ran into it while researching my problem and mirrored it over here. 


perhaps the issue is just that sudo -i won't unset the KRB5CCNAME, then the question is - is the the correct behavior ?

Comment 5 Jakub Hrozek 2016-04-09 19:20:40 UTC

(In reply to Mark from comment #4)
> it does not appear that running sudo -i will unset the KRB5CCNAME; as such
> it remains after sudo -i. 
> 

OK, so you're seeing a different behaviour than I? Note that in my testing KRB5CCNAME was set to /tmp/krb5cc_0 after sudo -i which is what I would expect, because sudo -i opens a login session.

> I didn't open the upstream ticket, just ran into it while researching my
> problem and mirrored it over here. 
> 

Sure, that's fine, thank you.

> 
> perhaps the issue is just that sudo -i won't unset the KRB5CCNAME, then the
> question is - is the the correct behavior ?

I would expect the correct behaviour to be what I pasted, ie sudo you'd get a new ccache.

Comment 6 Mark 2016-04-11 16:57:16 UTC

when I ssh in and use a password (not a preshared key) I get a TGT for the non default realm on the machine. 


when I sudo -iu to a different user, the environment KRB5CCNAME is not unset/changed after successful auth  and still points to a TGT owned by the original ssh login session.


.sudo su - works as expected , KRB5CCNAME is unset with su - ; sudo -iu <user> does not unset it. (for me)

Comment 7 Jakub Hrozek 2016-04-11 17:31:02 UTC

Ah, thank you for the explanation. But given the late stage of RHEL-6, I would prefer bugs to be fixed in RHEL-7 first and then backported on a case-by-case basis.

Comment 9 Mark 2016-04-13 21:01:41 UTC

I'll run my need in 6.something though our account rep or whatever that process is. 


thanks,

Comment 10 Mark 2016-04-13 21:15:01 UTC

I have no idea why this got set to 7.0 with my comment. setting back to 7.2

Comment 11 Jakub Hrozek 2016-04-14 11:56:47 UTC

(In reply to Mark from comment #9)
> I'll run my need in 6.something though our account rep or whatever that
> process is. 
> 
> 
> thanks,

Yes, please open a case.

Comment 12 Jakub Hrozek 2016-11-02 13:15:45 UTC

Fixed upstream:

master:
 * ce43f710c9638fbbeae077559cd7514370a10c0c
 * c8fe1d922b254aa92e74f428135ada3c8bde87a1
sssd-1-14:
 * 74711db46029415cc9590bb0e3f9cc662dac1d0c
 * 0157678081e299660105c753f2d2ac2081960bca 
sssd-1-13:
 * 5cbea81f6019d4c6acc94b8cec0b955d1767430b
 * 27e38ce07c3f2bb9682e2219ac2ac78e855d43b5

Comment 13 Jakub Hrozek 2016-12-08 08:03:31 UTC

*** Bug 1402591 has been marked as a duplicate of this bug. ***

Comment 15 Jakub Hrozek 2017-02-03 09:54:36 UTC

Steps to reproduce: see https://bugzilla.redhat.com/show_bug.cgi?id=1329378#c14

Comment 16 Amith 2017-06-01 13:18:24 UTC

Verified the bug on SSSD Version: sssd-1.15.2-37.el7.x86_64

Steps followed during verification:

1. Set sudo rule ALL=ALL for an ldap user. See example below:
   # sudo -l -U testuser
Matching Defaults entries for testuser on rhel-74:
    !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR........
 
User testuser may run the following commands on rhel-74:
    (ALL) ALL

2. Login as the ldap user. Check the krb ticket and variable KRB5CCNAME.

    # ssh -l testuser localhost
    testuser@localhost's password: 
    Last login: Thu Jun  1 18:14:06 2017 from ::1
    /usr/bin/id: cannot find name for group ID 21201
    $ 
    $ klist 
    Ticket cache: FILE:/tmp/krb5cc_21201_85l8NM
    Default principal: testuser

    Valid starting       Expires              Service principal
    2017-06-01T18:19:23  2017-06-02T18:19:22  krbtgt/EXAMPLE.COM
	renew until 2017-06-01T18:19:23

   $ echo $KRB5CCNAME 
   FILE:/tmp/krb5cc_21201_85l8NM

3. Now, run "sudo -iu" and login as another ldap user. Try to list the krb cache and execute kinit. You should see internal credentials cache error.

   $ sudo -iu testuser1
   We trust you have received the usual lecture from the local System
   Administrator. It usually boils .... 
   ....
   [sudo] password for testuser: 
   /usr/bin/id: cannot find name for group ID 2121
   [testuser1@rhel-74 ~]$ whoami
   testuser1

   [testuser1@rhel-74 ~]$ klist 
   klist: Credentials cache permissions incorrect (filename: /tmp/krb5cc_21201_85l8NM)

   [testuser1@rhel-74 ~]$ kinit 
   Password for testuser1: 
   kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_21201_85l8NM) while getting initial credentials

4. The new user session retains the KRB5CCNAME value. 
   [testuser1@rhel-74 ~]$ echo $KRB5CCNAME 
   FILE:/tmp/krb5cc_21201_85l8NM

5. Edit pam section of sssd.conf file and add the following:
   [pam]
   pam_response_filter = ENV:KRB5CCNAME:sudo-i

6. Clear sssd cache and restart the service.

7. Repeat the steps-2, 3 and 4.

8. With the latest sssd build, the error disappears while listing the krb cache and the variable KRB5CCNAME is unset.

   [testuser@rhel-74 ~]$ echo $KRB5CCNAME 
   FILE:/tmp/krb5cc_21201_bJfkL2
   
   [testuser@rhel-74 ~]$ sudo -iu testuser1
   [sudo] password for testuser: 
   /usr/bin/id: cannot find name for group ID 2121
   [testuser1@rhel-74 ~]$ 
   [testuser1@rhel-74 ~]$ klist 
    klist: No credentials cache found (filename: /tmp/krb5cc_2121)

   [testuser1@rhel-74 ~]$ whoami
   testuser1
   [testuser1@rhel-74 ~]$ kinit 
   Password for testuser1: 
   [testuser1@rhel-74 ~]$ klist 
   Ticket cache: FILE:/tmp/krb5cc_2121
   Default principal: testuser1
 
   Valid starting       Expires              Service principal
   2017-06-01T18:28:23  2017-06-02T18:28:22  krbtgt/EXAMPLE.COM
	   renew until 2017-06-01T18:28:23

   [testuser1@rhel-74 ~]$ echo $KRB5CCNAME
   
   [testuser1@rhel-74 ~]$

Comment 17 errata-xmlrpc 2017-08-01 08:58:07 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2294