On Mon, Oct 06, 2008 at 02:32:49PM -0700, Anthony Scarpino wrote: > Douglas E. Engert wrote: > >>Is there any way to provide a provider preference order so that > >>smartcards are never used for crypto other than in relation to > >>non-extractable keys? > > > >Good question. And to associate a provider with a user or session, > >i.e. smart card at the console is only for the user at the console. > > > > For private keys on a keystore you'd have to provide a PIN, so I'd say > that's the easiest way.. That would limit the access to the keystore to > a particular session that did a C_Login.. > > crypto operations are whatever the provider is exporting.. If it has > it's own DES implementation and does not show that mechanism in the > mechanism list, then it wouldn't be used..
Hmmm. I would think logindevperm(4) should help. 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. Jan? Nico --
