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 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 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 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 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 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 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 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 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 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 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 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.
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.
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?
(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.
Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=714ec4bff69608160f9155b7a634e0630ec05f41 Package: mod_auth_kerb-5.4-13.fc18 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=316630
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?
Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=7954e0c420f9e453866349e893f5e95085c611fb Package: mod_auth_kerb-5.4-14.fc18 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=318422
Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=87d22fe3b89d479192f61bc67048ad1a0f6037fe Package: mod_auth_kerb-5.4-14.fc17 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=318430
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).
OK, thanks Stephen. It doesn't seem harmful to have the tmpfile in the f17 branch too so I won't bother reverting that.
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 ()
(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
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.
Rob, oops - the pstrcat call needs a , NULL at the end. I've fired off a build.
I missed your other comment. Hmmm, my patch was doubly wrong. I think it should hard-code /run/user/apache.
Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=22f4ad25e5dcd209069dd4100704edc94ac8a691 Package: mod_auth_kerb-5.4-15.fc18 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=324979
Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=7ec72fbee571525d4ea48d98987c07e576462aaa Package: mod_auth_kerb-5.4-16.fc18 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=324983
Commit: http://pkgs.fedoraproject.org/gitweb/?p=mod_auth_kerb.git;a=commitdiff;h=5fadd09e52508859eed9584b4e1c1c68e04cb21d Package: mod_auth_kerb-5.4-16.fc17 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=324987
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.
Seems to be working, initial testing looks good. Thanks for the quick turnaround.
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
Great, thanks for testing it out. I've submitted that package as an update for f17.
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.
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
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
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
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).
(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.
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 ----------------------------
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.
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.
Of course you could argue this should be in /run/service/UID rather then /run/user, since apache is not a user.
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.
The f17 mod_auth_kerb has a crasher bug per comment 10 so we need to do something there.
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.
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.
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
I'm closing this bug. We want to keep ccache type as FILE in mod_auth_kerb, as it is intentional use.