Bug 796430 - sssd and kerberos should change the default location for create the Credential Cashes to /run/user/UID/krb5cc
sssd and kerberos should change the default location for create the Credentia...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mod_auth_kerb (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
:
Depends On: 786957 786993 796429
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-22 16:21 EST by Stephen Gallagher
Modified: 2014-01-16 04:30 EST (History)
13 users (show)

See Also:
Fixed In Version: mod_auth_kerb-5.4-16.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 796429
Environment:
Last Closed: 2014-01-16 04:30:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stephen Gallagher 2012-02-22 16:21:29 EST
Cloning to mod_auth_kerb.


+++ This bug was initially created as a clone of Bug #796429 +++

Cloning to krb5. We want to change the default location for tools such as kinit to /run/user/<username>/krb5cc as well.


+++ This bug was initially created as a clone of Bug #786993 +++

+++ This bug was initially created as a clone of Bug #786957 +++

I know we are late for this as a security feature, but I have been running with this for a while and I think it is the right thing to do.

Change sssd default to put the cc file in /run/user.  If this is accepted we will have to change rpc.gssd to look in this new location.

If you want I will write up a feature page for this.

--- Additional comment from sgallagh@redhat.com on 2012-02-02 13:54:31 EST ---

It's probably too late for a feature submission, but can you open a dialog with the rpc.gssd folks about changing this? Find out whether it can be done within the F17 alpha timeframe (read: by Feb 13).

--- Additional comment from dwalsh@redhat.com on 2012-02-02 15:44:31 EST ---

Steve how much work would it be to get rpc.gssd to search /run/user/USERNAME/
before searching /tmp?

--- Additional comment from nalin@redhat.com on 2012-02-02 17:09:17 EST ---

As Stephen and Simo have noted elsewhere, when we do that we might as well have SSSD drop the unique-suffix-via-mkstemp() logic, as it's only being done to avoid a DoS that's possible in a shared /tmp, and not to ensure that ccaches are per-session.

At any rate, rpc.gssd would want to be able to search the ccache with a name along the lines of "DIR:/run/user/$LOGIN/blahblah" or "FILE:/run/user/$LOGIN/blahblah", depending on whether the agreed-upon location was a directory or a file (the exact name under /run/user/$LOGIN is not set yet).  The libraries should know the specifics of how to deal with the contents of the ccache, so long as rpc.gssd tells them to look there.

--- Additional comment from steved@redhat.com on 2012-02-03 11:39:19 EST ---

(In reply to comment #1)
> Steve how much work would it be to get rpc.gssd to search /run/user/USERNAME/
> before searching /tmp?
Changing the default path probably will not be too bad but getting the user name might be a bit time consuming since uids are passed up from the kernel. Doing that uid to username conversion very time consuming... 

/run/usr/<uid>/ would be better from rpc.gssd's perceptive

--- Additional comment from sgallagh@redhat.com on 2012-02-03 15:18:25 EST ---

This would be very easy to accomplish from SSSD's perspective, but I defer to Dan to tell us how feasible this is from SELinux's (and systemd's) point of view. I got the impression that /var/run/user/username was automatically created (and its permissions managed) by systemd.

--- Additional comment from ssorce@redhat.com on 2012-02-03 18:49:11 EST ---

(In reply to comment #3)
> (In reply to comment #1)
> > Steve how much work would it be to get rpc.gssd to search /run/user/USERNAME/
> > before searching /tmp?
> Changing the default path probably will not be too bad but getting the user
> name might be a bit time consuming since uids are passed up from the kernel.
> Doing that uid to username conversion very time consuming... 
> 
> /run/usr/<uid>/ would be better from rpc.gssd's perceptive

Maybe we can have a symlink with the userid.

--- Additional comment from bfields@redhat.com on 2012-02-06 07:58:14 EST ---

The kernel can't pass up any uids, all it has to pass up is a gss init_sec_context token, which svcgssd uses the gss/krb5 libraries to turn into some kind of gss name, which is mapped to numeric id's by libnfsidmap--see nfs-utils/utils/gssd/svcgssd_proc.c:get_ids().  (I don't really know if that's the best way to do it, but that's how it works right now.)

So if there's an easy way to map the gss name to the right form then getting the username shouldn't be too bad....

But it still might be simplest if we could continue doing the lookup by id.

--- Additional comment from ssorce@redhat.com on 2012-02-06 08:27:39 EST ---

Bruce,
I think you are describing the case of a NFS server.
Ccaches are used in the case of an NFS client. In that case the uid is the only information the kernel has about the process trying to access a specific mount point.
In gss-proxy I can do the uid->name lookup (which is very fast with either nscd or sssd+memcache patches so I don't think you should worry too much about the speed of that lookup.

HTH,
Simo

--- Additional comment from bfields@redhat.com on 2012-02-06 08:45:43 EST ---

(In reply to comment #7)
> Bruce,
> I think you are describing the case of a NFS server.
> Ccaches are used in the case of an NFS client. In that case the uid is the only
> information the kernel has about the process trying to access a specific mount
> point.

Bah, you're right, sorry for not following carefully!

> In gss-proxy I can do the uid->name lookup (which is very fast with either nscd
> or sssd+memcache patches so I don't think you should worry too much about the
> speed of that lookup.

OK.

--- Additional comment from updates@fedoraproject.org on 2012-02-22 09:36:22 EST ---

sssd-1.8.0-5.fc17.beta3 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/sssd-1.8.0-5.fc17.beta3

--- Additional comment from sgallagh@redhat.com on 2012-02-22 09:41:58 EST ---

Sorry, selected the wrong BZ for this update. It has now been correct.

But you're at least now aware that the SSSD side of this change is now in updates-testing. Please look into the nfs-utils changes ASAP.
Comment 1 Simo Sorce 2012-02-22 17:01:05 EST
Joe,
just to give you some context, this bug has been cloned for mod_auth_kerb because with the new s4u2proxy features it now needs to create a credential cache when that feature is enabled.

So what mod_auth_kerb packages should is to drop a configuration file in /etc/tmpfiles.d similar to what httpd already does.

The tmpfile for mod_auth_kerb should create a directory in /var/run/user/apache, owned by the apache user and with permissions 700

HTH.
Comment 2 Joe Orton 2012-02-23 11:36:04 EST
Thanks for the heads up.  When you say a directory "in" /var/run/user/apache, do you mean that directory name itself, i.e. the tmpfile drop-in should be:

d /var/run/user/apache 700 apache apache

There is already a hard-coded reference to the cred cache filename used in mod_auth_kerb, separate from the s4u2proxy patch, does that need to change also?

   ccname = apr_psprintf(r->pool, "FILE:%s/krb5cc_apache_XXXXXX", P_tmpdir);
   fd = mkstemp(ccname + strlen("FILE:"));

should that code be using some library interface rather than generating the filename itself?
Comment 3 Simo Sorce 2012-02-23 11:43:02 EST
(In reply to comment #2)
> Thanks for the heads up.  When you say a directory "in" /var/run/user/apache,
> do you mean that directory name itself, i.e. the tmpfile drop-in should be:
> 
> d /var/run/user/apache 700 apache apache

Yes, the directory is named after the user.

> There is already a hard-coded reference to the cred cache filename used in
> mod_auth_kerb, separate from the s4u2proxy patch, does that need to change
> also?
> 
>    ccname = apr_psprintf(r->pool, "FILE:%s/krb5cc_apache_XXXXXX", P_tmpdir);
>    fd = mkstemp(ccname + strlen("FILE:"));
> 
> should that code be using some library interface rather than generating the
> filename itself?

No the reason why you generate a filename is that this is a separate credential cache that contains the delegated credentials from the user and need to differ at each invocation. If you relied on the library you'd overwrite apache own credentials.

However I think it may make sense to change the code to use /var/run/user/apache as the P_tmpdir.
This is not strictly required. In F17 httpd is configured to use a private tmp by default so using /tmp is not terribly bad, but using [/var]/run is a tmpfs and that means the ccaches are all wiped out at reboot so there is no risk of leaving credentials around on hard resets.
Comment 5 Joe Orton 2012-05-11 05:58:57 EDT
Sorry, my script lied, this is not fixed in -13.

BTW this is filed against Raw Hide but there are mentions of f17 above, I presume this is required in f17?
Comment 8 Stephen Gallagher 2012-05-11 08:11:38 EDT
No, sorry. The original plan was to do this for F17, but when we became aware that it touched too many packages, we deferred it to F18 so we'd have time to get it right.

So this is NOT the default location in F17. That remains /tmp/krb5cc_UID[_XXXXXX]


As an aside, please also be aware of https://fedoraproject.org/wiki/Features/KRB5DirCache (I'll be opening a bug against mod_auth_kerb soon to handle this).
Comment 9 Joe Orton 2012-05-11 08:27:59 EDT
OK, thanks Stephen.  It doesn't seem harmful to have the tmpfile in the f17 branch too so I won't bother reverting that.
Comment 10 Rob Crittenden 2012-06-13 09:14:48 EDT
This patch is causing httpd to core dump. I'm testing with IPA:

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31
31              movdqu  (%rdi), %xmm1
(gdb) where
#0  __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31
#1  0x00007f1757b51e9e in apr_pstrcat () from /lib64/libapr-1.so.0
#2  0x00007f174c9e6dd9 in create_krb5_ccache (kcontext=0x7f1759fc9890,
    r=r@entry=0x7f175a100840, princ=0x7f175a088c20, 
    ccache=ccache@entry=0x7fff98e67330, 
    conf=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
    at src/mod_auth_kerb.c:895
#3  0x00007f174c9e9a01 in store_gss_creds (delegated_cred=0x7f175a0d9d80, 
    princ_name=<optimized out>, r=0x7f175a100840, conf=<optimized out>)
    at src/mod_auth_kerb.c:1220
#4  authenticate_user_gss (negotiate_ret_value=<synthetic pointer>, 
    auth_line=0x7f175a1021c9 "", conf=0x7f1759d826d8, r=0x7f175a100840)
    at src/mod_auth_kerb.c:1790
#5  kerb_authenticate_user (r=0x7f175a100840) at src/mod_auth_kerb.c:2009
#6  0x00007f1758e83770 in ap_run_check_user_id ()
#7  0x00007f1758e86450 in ap_process_request_internal ()
#8  0x00007f1758ea1598 in ap_process_async_request ()
#9  0x00007f1758ea187f in ap_process_request ()
#10 0x00007f1758e9e125 in ?? ()
#11 0x00007f1758e96250 in ap_run_process_connection ()
#12 0x00007f174ea5d727 in ?? () from /etc/httpd/modules/mod_mpm_prefork.so
#13 0x00007f174ea5d96c in ?? () from /etc/httpd/modules/mod_mpm_prefork.so
#14 0x00007f174ea5e7ae in ?? () from /etc/httpd/modules/mod_mpm_prefork.so
#15 0x00007f1758e736ae in ap_run_mpm ()
#16 0x00007f1758e6d17a in main ()
Comment 11 Simo Sorce 2012-06-13 09:48:02 EDT
(In reply to comment #8)
> No, sorry. The original plan was to do this for F17, but when we became
> aware that it touched too many packages, we deferred it to F18 so we'd have
> time to get it right.
> 
> So this is NOT the default location in F17. That remains
> /tmp/krb5cc_UID[_XXXXXX]
> 
> 
> As an aside, please also be aware of
> https://fedoraproject.org/wiki/Features/KRB5DirCache (I'll be opening a bug
> against mod_auth_kerb soon to handle this).

Steven we do not need to use a DIR: cache type for mod_auth_kerb, unless it will start handling multiple credentials, a FILE: ccache is sufficient for apache
Comment 12 Rob Crittenden 2012-06-13 10:55:13 EDT
I'm not sure why but it seems to be the apr_pstrcat() that is causing the grief. I replaced it with apr_psprintf and replaced FILE: with FILE:%s and it works.

Well, it works to a point. httpd does not have write permissions on /run/httpd so the request still fails, it can't create the ccache. chmod g+w makes it work but this doesn't quite seem like the right thing to do.
Comment 13 Joe Orton 2012-06-13 11:02:33 EDT
Rob, oops - the pstrcat call needs a , NULL at the end.  I've fired off a build.
Comment 14 Joe Orton 2012-06-13 11:06:00 EDT
I missed your other comment.  Hmmm, my patch was doubly wrong.  I think it should hard-code /run/user/apache.
Comment 18 Joe Orton 2012-06-13 11:22:42 EDT
Rob, can you try the -16 build linked above?  /run/user/apache should be created with the correct permissions and should be used for the cache.
Comment 19 Rob Crittenden 2012-06-13 11:32:40 EDT
Seems to be working, initial testing looks good. Thanks for the quick turnaround.
Comment 20 Fedora Update System 2012-06-13 11:38:13 EDT
mod_auth_kerb-5.4-16.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mod_auth_kerb-5.4-16.fc17
Comment 21 Joe Orton 2012-06-13 11:39:34 EDT
Great, thanks for testing it out.  I've submitted that package as an update for f17.
Comment 22 Rob Crittenden 2012-06-13 12:07:18 EDT
I had only tested the F-18 build. I'm getting a permission denied on F-17:

[Wed Jun 13 11:54:58 2012] [error] [client 192.168.166.44] mkstemp() failed: Permission denied, referer: https://pinto.example.com/ipa/xml

strace says:

open("/run/user/apache/krb5cc_apache_fYlDXR", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)

Permissions look ok

# ls -ld /run/
drwxr-xr-x. 28 root root 1080 Jun 13 11:53 /run/
# ls -ld /run/user
drwxr-xr-x. 6 root root 120 Jun 13 12:01 /run/user
# ls -ld /run/user/apache/
drwx------. 2 apache apache 40 Jun 13 11:19 /run/user/apache/

I didn't see any SELinux errors but as a goof I set to permissive mode and it started working. Still no AVCs logged so I set back to enforcing and it is still working. I'm a bit stumped.
Comment 23 Daniel Walsh 2012-06-14 15:47:41 EDT
If you remove the file altogether and maybe remove /run/user/apache, does the SELinux block it again.  

I would figure the problem might be related to the labeling of /run/user/apache
Comment 24 Rob Crittenden 2012-06-14 16:08:31 EDT
It appears to be ok:

# ls -ldZ /run/user/apache
drwx------. apache apache system_u:object_r:user_tmp_t:s0  apache

I tried again and it was failing again in enforcing mode but I wasn't seeing any logging in audit. I put it into permissive mode and now I see these:

type=AVC msg=audit(1339704357.328:2128): avc:  denied  { write } for  pid=27635 comm="httpd" name="apache" dev="tmpfs" ino=190674 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
type=AVC msg=audit(1339704357.328:2128): avc:  denied  { add_name } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
type=AVC msg=audit(1339704357.328:2128): avc:  denied  { create } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1339704357.328:2128): avc:  denied  { open } for  pid=27635 comm="httpd" path="/run/user/apache/krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207179 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1339704357.338:2129): avc:  denied  { remove_name } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207179 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir
type=AVC msg=audit(1339704357.338:2129): avc:  denied  { unlink } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207179 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1339704357.526:2130): avc:  denied  { setattr } for  pid=27635 comm="httpd" name="krb5cc_apache_Ka3hGH" dev="tmpfs" ino=207186 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
Comment 25 Daniel Walsh 2012-06-14 16:23:11 EDT
Right we need the /run/user/apache directory labeled as httpd_tmp_t or something else, since we currently label /run/user as user_tmp_t, we need a transition for httpd to create apache labeled httpd_tmp_t.

Fixed in selinux-policy-3.10.0-131.fc17
Comment 26 Fedora Update System 2012-06-14 20:33:05 EDT
Package mod_auth_kerb-5.4-16.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mod_auth_kerb-5.4-16.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9427/mod_auth_kerb-5.4-16.fc17
then log in and leave karma (feedback).
Comment 27 Alexander Bokovoy 2012-06-19 06:13:30 EDT
(In reply to comment #18)
> Rob, can you try the -16 build linked above?  /run/user/apache should be
> created with the correct permissions and should be used for the cache.
Incorrect. /run/user is tmpfs so you have to use /etc/tmpfiles.d entry to create the directory.

And given that /run/user/apache is for all httpd users, /run/user/apache should be created and owned by httpd package, not mod_auth_kerb.
Comment 28 Alexander Bokovoy 2012-06-19 06:19:19 EDT
I'm turning this bug back to NEW state.

Please remove ownership of /run/user/apache from mod_auth_kerb, it does not help at all.

I verified that with selinux-policy-3.1.0-132.fc17 and small change to /etc/tmpfiles.d/httpd.conf I'm able to use IPA on F17 again:

# ipa user-find
ipa: ERROR: cannot connect to 'http://head.ipa.local/ipa/xml': Internal Server Error
# ls -l /run/user/apache/
# ls: cannot access /run/user/apache: No such file or directory
# cat /etc/tmpfiles.d/httpd.conf
d /var/run/httpd   710 root apache
d /run/user/apache 770 apache apache
# systemd-tmpfiles --create /etc/tmpfiles.d/httpd.conf
# ls -laZ /run/user/apache/
drwxrwx---. apache apache system_u:object_r:httpd_tmp_t:s0 .
drwxr-xr-x. root   root   system_u:object_r:user_tmp_t:s0  ..
# ipa user-find
--------------
1 user matched
--------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 137800000
  GID: 137800000
  Account disabled: False
  Password: True
  Kerberos keys available: True
----------------------------
Number of entries returned 1
----------------------------
Comment 29 Stephen Gallagher 2012-06-19 08:52:43 EDT
One more piece here: we've determined that /run/user/username is inappropriate for a number of reasons. We are switching to /run/user/UID which is much safer (and doesn't require an nsswitch lookup either).

Updating the summary.
Comment 30 Alexander Bokovoy 2012-06-19 09:03:22 EDT
After discussing with Simo, we ask to make following changes:

0. Remove mod_auth_kerb update with the /run/user/username change from Fedora 17
1. Keep ownership of /run/user/UID in mod_auth_kerb
2. Add /etc/tmpfiles.d/mod_auth_kerb.conf with
   d /run/user/UID 770 apache apache

Note that this file should be generated upon install and marked as %ghost in the package. The reason for it that we can't really predict uid of apache prior to install.
Comment 31 Daniel Walsh 2012-06-19 09:37:57 EDT
Of course you could argue this should be in /run/service/UID rather then /run/user, since apache is not a user.
Comment 32 Stephen Gallagher 2012-06-19 09:53:56 EDT
There's also an ongoing discussion as to whether the cred caches should be in /run/auth/UID.

Please hold. I'll update the ticket when that's been hashed out.
Comment 33 Joe Orton 2012-06-19 10:49:17 EDT
The f17 mod_auth_kerb has a crasher bug per comment 10 so we need to do something there.
Comment 34 Stephen Gallagher 2012-08-20 13:13:09 EDT
Apologies for the long delay on a response here.

Paraphrasing from BZ #848226 (similar bug for krb5-appl):

As part of the Fedora 18 features https://fedoraproject.org/wiki/Features/KRB5CacheMove and https://fedoraproject.org/wiki/Features/KRB5DirCache, servers which accept delegated credentials and store them in credential caches for users will need to be taught to put them in a different location.

Specifically, they'll go in /run/user/$UID, and preferably in a "DIR" type ccache rather than the "FILE" type which is currently used.

If that fails for some reason, falling back to the current behavior is going to likely be better than nothing.
Comment 35 Nalin Dahyabhai 2012-08-20 16:01:34 EDT
FWIW, I don't know that switching from FILE: to DIR:, for this specific case, is going to gain us anything.

Using DIR: is preferable when the processes using the cache which we're setting up (typically a shell session) might want to store an additional initial TGT obtained from a different realm, and to be able to choose which is to use by default.

While it's certainly possible, I don't think it's likely that a process on the server will attempt the equivalent of a 'kinit' to get a brand-new TGT from a different realm, and when we're in the context of a server-side process that's using credentials delegated to it by a client, I'd expect the decision of which client credentials to use to have been implicitly made by the client when it decided which credentials to delegate to the server.

Given that, and the additional work involved in using DIR: ccaches, I believe that mod_auth_kerb is probably going to be better off if it sticks to creating FILE: ccaches.
Comment 36 Fedora End Of Life 2013-04-03 11:24:32 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 37 Alexander Bokovoy 2014-01-16 04:30:53 EST
I'm closing this bug. We want to keep ccache type as FILE in mod_auth_kerb, as it is intentional use.

Note You need to log in before you can comment on or make changes to this bug.