Disable ssl-engine, re-enable kerberos5, it still crashes.
I'm pretty sure I'm running a stock OpenSSL. The only things
that I can think of that I might have done in that general
vicinity were to install xinetd, althttpd, and stunnel4, and
to obtain a host certificate from letsencrypt.org.
I'm still seeing it falling apart in EVP_Cipher. When I
allow 'socket', it unsurprisingly fails with SIGSYS on a
'connect' that follows immediately. The stack trace is
confusing. I've installed libkeyutils1-dbgsym, but it still
reports [unknown] for the locations.
But at least we know it's going through keyutils, which isn't a huge library!
What I get from a separate run using strace is also likely a usefil clue. The abort
on 'connect' shows that it's trying to connect to D-Bus. I have Absolutely No Idea
what's going on there, but it seems quite peculiar. (There are a bunch of writes
from debug3 calls that I strewed throughout cipher_crypt.)
Disable ssl-engine, re-enable kerberos5, it still crashes.
I'm pretty sure I'm running a stock OpenSSL. The only things
that I can think of that I might have done in that general
vicinity were to install xinetd, althttpd, and stunnel4, and
to obtain a host certificate from letsencrypt.org.
I'm still seeing it falling apart in EVP_Cipher. When I dbgsym, but it still
allow 'socket', it unsurprisingly fails with SIGSYS on a
'connect' that follows immediately. The stack trace is
confusing. I've installed libkeyutils1-
reports [unknown] for the locations.
sshd 9257 [006] 260133.546558: syscalls: sys_enter_ socket: family: 0x00000001, type: 0x00000001, protocol: 0x00000000
115eb7 __socket (/lib/x86_ 64-linux- gnu/libc- 2.26.so)
464e [unknown] (/lib/x86_ 64-linux- gnu/tls/ libkeyutils. so.1.5)
484b [unknown] (/lib/x86_ 64-linux- gnu/tls/ libkeyutils. so.1.5)
4be7 [unknown] (/lib/x86_ 64-linux- gnu/tls/ libkeyutils. so.1.5)
4a24a cipher_crypt (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
4feec ssh_packet_ send2_wrapped (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
500ef ssh_packet_send2 (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
52b78 ssh_packet_send (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
1a920 userauth_finish (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
1ae72 input_userauth_ request (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
56699 ssh_dispatch_run (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
56748 ssh_dispatch_ run_fatal (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
19d06 do_authentication2 (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
de67 main (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
211c0 __libc_start_main (/lib/x86_ 64-linux- gnu/libc- 2.26.so)
f2b9 _start (/home/ kennykb/ debian. org/openssh/ kevinbuild/ sshd)
ffffffffffffff ff [unknown] ([unknown])
But at least we know it's going through keyutils, which isn't a huge library!
What I get from a separate run using strace is also likely a usefil clue. The abort
on 'connect' shows that it's trying to connect to D-Bus. I have Absolutely No Idea
what's going on there, but it seems quite peculiar. (There are a bunch of writes
from debug3 calls that I strewed throughout cipher_crypt.)
[pid 9903] write(7, "\0\0\0# \0\0\0\ 7\0\0\0\ 33cipher_ crypt seqnr=7"..., 39 <unfinished ...> 26\0\0\ 0\7\0\0\ 0\16not CHACHAPOLY", 26 <unfinished ...> \0\0\0\ 7\0\0\0\ 33neither CHACHAPOLY n"..., 39) = 39 23\0\0\ 0\7\0\0\ 0\vauthlen = 0", 23) = 23 22\0\0\ 0\7\0\0\ 0\naadlen = 4", 22) = 22 31\0\0\ 0\7\0\0\ 0\21Before EVP_Cipher", 29) = 29 @"/tmp/ dbus-kZ8VEtJDOJ "}, 23) = ?
[pid 9901] <... write resumed> ) = 53
[pid 9903] <... write resumed> ) = 39
[pid 9901] write(2, "debug3: mm_request_receive enter"..., 37debug3: mm_request_receive entering
<unfinished ...>
[pid 9903] write(7, "\0\0\0\
[pid 9901] <... write resumed> ) = 37
[pid 9903] <... write resumed> ) = 26
[pid 9901] read(5, <unfinished ...>
[pid 9903] write(7, "\0\0\0#
[pid 9903] write(7, "\0\0\0\
[pid 9903] write(7, "\0\0\0\
[pid 9903] write(7, "\0\0\0\
[pid 9903] socket(AF_UNIX, SOCK_STREAM, 0) = 5
[pid 9903] connect(5, {sa_family=AF_UNIX, sun_path=
[pid 9903] +++ killed by SIGSYS (core dumped) +++
<... read resumed> "", 4) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=9903, si_uid=117, si_status=SIGSYS, si_utime=0, si_stime=0} ---
So somehow, with Kerberos5 enabled, it's trying to do some sort of IPC (for key management?)
and getting blocked by the seccomp rules?