Created attachment 2273 [details] Handle ssh_gssapi_supported_oids in monitor for seccomp sandbox compatibility One of my test installations happens to have "GSSAPIAuthentication yes", and this breaks with the seccomp sandbox. Initially I assumed this was specific to Simon Wilkinson's GSSAPI key exchange patch (which I apply in Debian), but on further investigation I found that that just causes the failure to happen earlier. Specifically, the regression test included in the patch I'm attaching to this bug fails if applied in isolation. The syscalls that are denied are, on Linux/i386, futex and stat64. These are used by gss_indicate_mechs, called by ssh_gssapi_supported_oids. futex probably doesn't matter much, but I'm not happy about opening up stat and friends, so I think it makes more sense to add a monitor protocol command for this function so that the sandboxed network child doesn't have to call it directly. Would you consider something like the attached patch, implementing this?
Created attachment 2406 [details] Cache supported oids before privilege separation Instead of calling out to the monitor, could we do it before the privsep child is forked? ssh_gssapi_supported_oids() doesn't seem to need any context to work. This patch tries to do this, but I have no way to test it (and really no clue at all when it comes to GSSAPI/Kerberos).
Put this on the list for openssh-6.6; assuming we can find someone to test the patch.
*** Bug 2204 has been marked as a duplicate of this bug. ***
Hi, I can confirm that for me the patch fixes the issue. After I applied the patch against 6.4p1 I changed back to UsePrivilegeSeparation sandbox and restarted sshd. I was able to log into that system with my TGT without any problem. I am ready for more testing if needed. best regards Georg Hopp
The patch you applied was the "Cache supported oids before privilege separation" one, right? (I just want to make sure before committing)
Yes, that's correct. https://bugzilla.mindrot.org/attachment.cgi?id=2406
But don't commit it right now... A moment ago I realized a problem that might relate to this or not. I am now able to ssh into the machines without a TGT and without a correct password. This might also be related to pam but I am not sure about this now. Anyway a su fails as expected. The auth log of a su with a wrong password: Feb 26 10:55:52 host su[9725]: pam_unix(su:auth): authentication failure; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test rhost= user=ghopp Feb 26 10:55:52 host su[9725]: pam_sss(su:auth): system info: [Preauthentication failed] Feb 26 10:55:52 host su[9725]: pam_sss(su:auth): authentication failure; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test rhost= user=ghopp Feb 26 10:55:52 host su[9725]: pam_sss(su:auth): received for user ghopp: 17 (Failure setting user credentials) Feb 26 10:55:54 host su[9725]: pam_authenticate: Permission denied Feb 26 10:55:54 host su[9725]: FAILED su for ghopp by test Feb 26 10:55:54 host su[9725]: - /dev/pts/17 test:ghopp The auth log of a su with the correct password: Feb 26 10:57:13 host su[9729]: pam_unix(su:auth): authentication failure; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test rhost= user=ghopp Feb 26 10:57:14 host su[9729]: pam_sss(su:auth): authentication success; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test rhost= user=ghopp Feb 26 10:57:14 host su[9729]: Successful su for ghopp by test Feb 26 10:57:14 host su[9729]: + /dev/pts/17 test:ghopp Feb 26 10:57:14 host su[9729]: pam_unix(su:session): session opened for user ghopp by ghopp(uid=2001) and the auth log of an ssh without a TGT and with a wrong password: Feb 26 10:58:05 host sshd[9736]: SSH: Server;Ltype: Version;Remote: 2001:4ba0:ffff:138:1::1000-42676;Protocol: 2.0;Client: OpenSSH_6.4p1-hpn14v2 Feb 26 10:58:06 host sshd[9736]: SSH: Server;Ltype: Kex;Remote: 2001:4ba0:ffff:138:1::1000-42676;Enc: aes128-ctr;MAC: hmac-md5-etm@openssh.com;Comp: none [preauth] Feb 26 10:58:06 host sshd[9736]: SSH: Server;Ltype: Authname;Remote: 2001:4ba0:ffff:138:1::1000-42676;Name: ghopp [preauth] Feb 26 10:58:08 host sshd[9738]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=2001:4ba0:ffff:138:1::1000 user=ghopp Feb 26 10:58:09 host sshd[9738]: pam_sss(sshd:auth): system info: [Preauthentication failed] Feb 26 10:58:09 host sshd[9738]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=2001:4ba0:ffff:138:1::1000 user=ghopp Feb 26 10:58:09 host sshd[9738]: pam_sss(sshd:auth): received for user ghopp: 17 (Failure setting user credentials) Feb 26 10:58:09 host sshd[9736]: Accepted keyboard-interactive/pam for ghopp from 2001:4ba0:ffff:138:1::1000 port 42676 ssh2 Feb 26 10:58:09 host sshd[9736]: pam_unix(sshd:session): session opened for user ghopp by (uid=0) Feb 26 10:58:09 host sshd[9740]: SSH: Server;Ltype: Kex;Remote: 2001:4ba0:ffff:138:1::1000-42676;Enc: aes128-ctr;MAC: hmac-md5-etm@openssh.com;Comp: none After that I am on the machine. For me it looks like ssh accepts any password now. As no TGT is involved into this I guess that this can also be reproduced in a non kerberized environment. regards Georg
OK, the problem was in my pam configuration. I made all password checking modules sufficient and let the final pam_deny optional. After I changed it to required everything works as expected. Sorry about the confusion. I am always a little confused when configuring pam. So again, the patch fixed the issue for me and does not open a security hole for me. best regards Georg
Patch applied; this will be in openssh-6.6
Close all bugs left open from 6.6 and 6.7 releases.
It looks like I am late for the party, but this unfortunately does not address the issue completely. For some reasons, the configuration can look like this: GSSAPIAuthentication no Match User root GSSAPIAuthentication yes and in this case, the caching mechanisms will not be triggered, the separated child will try to load the data later and fail: Program received signal SIGSYS, Bad system call. [Switching to Thread 0x7f67e97f88c0 (LWP 9647)] 0x00007f67e4c3de39 in pthread_once () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f67e4c3de39 in pthread_once () from /lib64/libpthread.so.0 #1 0x00007f67e3379b68 in krb5int_pthread_loaded () from /lib64/libkrb5support.so.0 #2 0x00007f67e337a0f1 in k5_once () from /lib64/libkrb5support.so.0 #3 0x00007f67e74021e7 in gssint_mechglue_initialize_library () from /lib64/libgssapi_krb5.so.2 #4 0x00007f67e74022b5 in gss_indicate_mechs () from /lib64/libgssapi_krb5.so.2 #5 0x00005594c41f2e4f in ssh_gssapi_supported_oids ( oidset=oidset@entry=0x5594c4490088 <supported_oids>) at gss-serv.c:179 #6 0x00005594c41f2f55 in ssh_gssapi_prepare_supported_oids () at gss-serv.c:82 #7 ssh_gssapi_test_oid_supported (ms=0x7ffc60dc75f0, member=0x7ffc60dc7600, present=0x7ffc60dc75ec) at gss-serv.c:89 #8 0x00005594c41f23d8 in userauth_gssapi (authctxt=0x5594c48fe500) at auth2-gss.c:127 #9 0x00005594c41e0b1c in input_userauth_request (type=<optimized out>, seq=<optimized out>, ctxt=0x5594c48fe500) at auth2.c:295 #10 0x00005594c42227a9 in ssh_dispatch_run (ssh=ssh@entry=0x5594c49008c0, mode=mode@entry=0, done=done@entry=0x5594c48fe500, ctxt=ctxt@entry=0x5594c48fe500) at dispatch.c:119 #11 0x00005594c42227f9 in ssh_dispatch_run_fatal (ssh=0x5594c49008c0, mode=mode@entry=0, done=done@entry=0x5594c48fe500, ctxt=ctxt@entry=0x5594c48fe500) at dispatch.c:140 #12 0x00005594c41dfde9 in do_authentication2 (authctxt=authctxt@entry=0x5594c48fe500) at auth2.c:175 #13 0x00005594c41d1ee7 in main (ac=<optimized out>, av=<optimized out>) at sshd.c:2191 Collin, can you confirm you can reproduce the same issue? I can not think about sensible way around this without initializing the kerberos library and loading the OIDs unconditionally.
Created attachment 3168 [details] cache OIDs unconditionally I can't think of any reason we can't prime the cache unconditionally.
(In reply to Damien Miller from comment #12) > Created attachment 3168 [details] > cache OIDs unconditionally > > I can't think of any reason we can't prime the cache unconditionally. That is probably the only way with the downside of having some overhead for non-GSSAPI mechanisms or potentially larger attack surface, but if you are fine with this change, I would be glad to have this addressed in the next release. I will reopen the bug to make sure it will not get lost. Thank you.
Fix committed and will be in openssh-7.9 release
Close RESOLVED bugs with the release of openssh-8.0