-
Notifications
You must be signed in to change notification settings - Fork 716
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
default module for pkcs11-tool #229
Comments
There should be no default, module argument should be mandatory. But |
why should there be no default? I found no reason for that besides the security issue mentioned in the thread where the default was removed. It makes things a lot easier for people getting started when little things like this are fixed. |
There is no such thing as default PKCS#11 provider, the whole concept |
The default would be the one most commonly used. From what I've seen, |
Commonly used is subjective per user case. It has nothing to do with |
Yes, its subjective, but if there is a default that matches what most people do, then most people will not have to think about this step, and waste a lot less of people's time. As long as its easy to change the default, which would be fully available using |
Once again, you are trying to enforce something that is not to be |
Can you give concrete reasons why? I'm not interested in customization as much as making things work as easily as possible. Then perhaps opensc will become that popular. "sensible defaults" are a cornerstone idea of making usable software. I think then my avenue will be to add a default to the Debian package. I never did anything with |
~/.opensc-tool can be added instead of what you recommend here if pkcs11-tool per its name is to load PKCS#11 module, and we loop... |
|
or perhaps |
Once again... I do not see any reason for distribution default. It is It is like you configure firefox to load specific PKCS#11 module for |
If university or company sets up a shared system and they all have a standard HSM setup that they use, then the sysadmins will want to put their defaults into a global config file. Then they don't have to set up each individual user who logs in. This would also include a default module in Firefox, I see no difference. If I want to find out which slots on my HSM exist, I use |
This university should install xxx-tool as wrapper of for |
I'm not quite sure I understand what you mean, but if you are suggesting that people should create and install per-user versions of the opensc package, that would be an insane maintenance nightmare. |
We already discussed this too long... let's see what others have to say. What I suggest is for enterprise that use a specific configuration, to It is basic enterprise customization and integration, without any need |
Douglas E. Engert [email protected] |
Without long explanations:
|
Maybe a default behaviour would be to use any module present in Now we have multi-arch |
PKCS#11 spec is explicit loading a provider, not implicit load any in directory. |
I think the best option right now would be to have OPENSC_PKCS11_TOOL_DEFAULT_MODULE environment variable. Realistically maybe just a PKCS11_MODULE would be enough. And maybe pkcs11-spy should share the name for the module to load. Whoever needs to make the utility to load something by default can set this system-wide variable for every user profile etc. |
And some distribution can set this variable by default (but this should clearly not be encouraged under usual circumstances). In the longer term it would be good to have some meaningful test suite for PKCS#11, so that the basic "does OpenSC PKCS#11 module work for my setup" smoke-test functionality of pkcs11-tool --test could be accomplished by something more meaningful and pkcs11-tool could be a separate stand-alone package, together with pkcs11-spy. IMHO they both be more viable if bundled together with some other pkcs11 toolkit/library, like p11-kit or pkcs11-helper. The only requirement I can think of is ease of self-contained build on non-posix platforms (read: windows) and this is the only question if moving it to p11-kit (if p11-kit folks would accept it, of course) or elsewhere. @stefwalter @alonbl what would you think? |
If people are to be abused by the default, such as providing their PIN to |
If you don't trust your environment, then the rest is anyway moot IMO. It makes sense to make things more convenient for a user, if it is deemed absolutely necessary by the user, thus such environment variable. If users are worried about PIN security, then anyway the only sensible solution is a dedicated pinpad device. In fact, to me it feels that having a standard environment variable which dedicates a PKCS#11 module to load (unless a more specific command is given by the user and the application would need to load one), is as meaningful and useful as having /usr/lib/pkcs11 (not a silver bullet but useful nevertheless). |
Splitting pkcs11-tool/spy from OpenSC would make it pretty obvious for most people that there should be no "by default OpenSC module" policy in those utilities. |
Please keep in mind that if you are to provide standards, you should |
Multiple providers? Why? If there is a need for multiple providers, then there is a need for a more complicated setup, which means that the simple "hint" by an environment variable is not sufficient. For the NSS case, PKCS11_MODULE=<separator like ; or :> would do, but then again, IMHO NSS is not your "average module" users want to use. Which are the similar providers that require arguments to C_Initialize ? There's also for sure modules that require certain threading setup or barf, but that's not something we need to support finetuning for, IMHO. |
If you want other tools to follow, this should be generic usage too, so Otherwise, please make sure OPENSC_ prefix is added. |
Tools != applications, like Firefox? The idea is not to provide a method for configuration of the whole application, but a hint to the application (if it wishes to use it). And I don't think that this requires multiple providers. Compare to JAVA_HOME and multiple JDK-s on the same machine? |
If someone wanted to log the PIN of a PKCS#11 provider, it would be much much simpler to just read the key events directly from the system. I don't really have an opinion on using an env var, but it is definitely very very standard on all things UNIXy to support a global config file whenever there is also a user-specific conf file supported. A global |
For PKCS#11 related things, we need to decouple it from OpenSC with clear borders. Or we end up with a similar mess as NSS. |
JAVA_HOME is to specify single JVM of your choice, bad example. |
A bad example? No, it is not. PKCS#11 as it currently exists is very much similar to the JRE problem. There are several, and which one you choose depends on a lot of factors. JAVA_HOME is a hint the same way as PKCS11_LIBRARY would be a hint. You really need to give a lot of options to your JRE as well, for a serious example. Yet for simple projects it suffices. So it is in many ways similar to the PKCS#11 issue - you need to specify from where to look a specific set of keys for a specific task. |
Hmmm.... java application MUST use single JRE, hence JAVA_HOME contains PKCS#11 aware application may use N providers, hence the example is not You seek something generic to be used by other utilities, this simple case So if you assume something of pkcs11-tool, please make it specific to this This entire discussion is quite strange... as if end user needs to run this |
I'm sorry, I don't really get your point. pkcs11-tool MUST use a PKCS#11 library to be useful. It MAY use several to be even more useful. For optimal results it MAY happen that the the utility (because this is in question right now, not a full-blown application like OpenVPN) would need more than a single provider for the key(s) it needs to perform its duty. The question right now is which module to use (instead of outright failing) if not specified by the user. Lets take another example from Unix world: there is a single $HOME yet cd command might make more sense with a different default depending on use case and requirements. I believe that having a PKCS11_MODULE (mind the name, could be something else) to be used as the default for pkcs11-tool or pkcs11-spy instead of specifying it manually from the command line or dedicated environment variable makes a lot of sense. If it doesn't work for you, don't use it. For Firefox/NSS, I hope they would fix a lot of other and more important things rather than depend on a new "suggested feature for PKCS#11-apps" which I'm sure is off their radars anyway. To re-iterate my view on this issue: it is wrong to marry OpenSC's pkcs11-tool with opensc-pkcs11.so. But it is totally reasonable to be able to give a PKCS#11-aware application such as pkcs11-tool a module path to load via and environment variable by default. The idea is not to give a "100% API-correct configuration and initialization parameters" but rather a hint to an application that might want make to use such a hint. So instead of all these long lines of discussion a simple patch of around 5 changed lines that would actually implement this feature would be more useful than this philosophical discussion. And would not harm anyone while possibly giving a benefit for someone. |
@martinpaljak +1 for a pragmatic solution! Does anyone want to submit a patch for: "use OpenSC's implementation by default and let the user configure something else"? |
It would be better to load p11-kit-proxy.so as the default provider if it's available. The p11-kit configuration specifies which modules which should be available by default to a given process, and p11-kit-proxy.so is the simple way for an existing PKCS#11 consumer to access them. $ pkg-config --variable=proxy_module p11-kit-1 /usr/lib64/p11-kit-proxy.so |
The current default also doesn't do the right thing when running pkcs11-tool from the build directory. When running from the build directory, we expect libtool (or something) to set up LD_LIBRARY_PATH such that we run with libraries and everything else from the build directory. That isn't working for opensc_pkcs11.so, which ends up finding the old version that's installed in the system. (Well, kind of. It seems to search $LD_LIBRARY_PATH but doesn't look in /usr/lib64/pkcs11/ which is where PKCS#11 modules seem to live on my system (as reported by 'pkg-config --variable=p11_module_path p11-kit-1'). |
Well, you could make a PR with improvement. Apart from adding the correct postfix to Yes, it makes sense to use p11-kit's pkcs#11module by default, if and only if we know that it will be installed along with OpenSC. This makes sense, for example when building the package for Mac OS X. However, you would only have to add |
There are many little technical details in the whole process of setting up and using an HSM with opensc, one seems to have a pretty simple answer: providing a default module so
pkcs11-tool --list-slots
does something by default. From what I read, the concern was the way it was originally implemented, it could be exploited. How about instead hardcoding a default module, i.e./usr/lib/opensc-pkcs11.so
and using that by default if it exists. Distros could then modify that path to the relevant location, i.e./usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
. I'd happily submit a patch to do this if devs here are willing to accept it.I've been working to smooth out a lot of little details like this in the whole process, you can see the documentation of my efforts here:
The text was updated successfully, but these errors were encountered: