On Tue, Oct 07, 2008 at 06:29:19PM +0200, Jan Pechanec wrote: > On Mon, 6 Oct 2008, Nicolas Williams wrote: > > >sshd does fork() once after first beginning to use PKCS#11 (through > >OpenSSL) to create the monitor process (immediate child of the sshd > >master listener, but parent in this fork()) and the daemon that actually > >does most of the SSHv2 work (the child in this case). The child runs > >as the logged-in user, and with little privilege. So as long as PKCS#11 > >drops access to open devices then all should be fine. > > > >Now, PKCS#11 is not fork-safe, and libpkcs11 does do the equivalent of > >C_Finalize() on the child side of any fork(), so technically sshd should > >definitely lose access to devices that are not accessible to the > >logged-in user. > > > >BUT, Jan changed recently how this works. Specifically now the child is > >fork()ed sooner and runs with privilege longer, then drops privilege. > >So we may actually have a problem. > > Nico, I'm not sure I follow here. Are we talking about a possible > situation where sshd uses the smartcard? I doesn't make too much sense to me > to have its server side private key there, and the server doesn't need any > user's private key.
I think Doug had two concerns w.r.t. sshd: 1) That sshd (and other PKCS#11 apps) should not use smartcards for crypto unrelated to non-extractable keys stored therein; The subsequent sub-thread about pkcs11.conf covered this. I think that the current preferences of libpkcs11 should take care of this (except for smartcards which might someday be driven by pkcs11_kernel). 2) That sshd/in.telnetd/... might prompt for PINs of smartcards plugged into a local seat (console, whatever). I later posted that I think this is a matter of PAM configuration, so this should be a non-issue. Nico --
