OPENSC_DRIVER environment variable prevents parsing configuration file

[Jakuje]

Problem Description

From discussion in the #1243 it appears very confusing for many people that once the OPENSC_DRIVER environment variable is used, NO configuration file is parsed and therefore the ATR matches with flags implemented in there are not effective.

Proposed Resolution

The configuration files should be parsed regardless this variable. It should only overwrite the drivers option, defined in the configuration file.

If we agree that this should be the way to go, I can have a look into possible implementation.

[Jakuje]

Reading through the source code, one thing I do not completely understand is that there are two configuration options:

• card_drivers, which affect which drivers are loaded and tried
• force_card_driver, which selects only one driver, that is always selected regardless whatever is in the rest of configuration file (such as the ATRs we have problem with in the OpenPGP x PIV-II issues).

The first option looks like it was here for some time (cd4e365, Mar 2002), and the second option was authored by jey in Apr 2002 (9c39ca7).

The environment variable that is connected to the second option (force_card_driver) was added quite recently (#882) in 2016 by @lbschenkel, probably unaware of these side effects.

Proposal

Long story short, my proposal would be to get rid of the force_card_driver configuration option (It can not do anything that could not be done with card_drivers, isn't it?) and hook the environment variable to the card_drivers option instead, overwriting the content of the configuration file. I didn't do that, but I believe I can give it a shot in coming days.

Are you against this approach for some reason? Do I miss some use case for this configuration option? @frankmorgner @dengert @mouse07410 @viktorTarasov ?

I also see that there is no Windows alternative as it was discussed in the #882. This is probably also a room for improvement, even though I have no way how to test the final product.

Also I see that this is nowhere documented. After we will resolve this, we should really update at least Environment-variables wiki page. Additionally, it should be described someplace in configuration file, what does it do.

[mouse07410]

I believe these two options aren't supposed to be used simultaneously. But it's clear that in some cases I may want to "force" exactly one driver, while in other cases I want to restrict the set of drivers to a few.

Thus, IMHO both should be there, maybe just better documented.

[Jakuje]

Am I missing something, or restricting the drivers to the single driver is something else than forcing single driver?

[mouse07410]

Ah, OK. Yes you're right.

Still, the site config may restrict the set to a few, and a particular invocation may want to force just one...

[Jakuje]

That would still work in case of configuration file as a "site configuration" and environment variable as "particular invocation", which would overwrite the single configuration option.

[lbschenkel]

Just got notified about this, I am busy and cannot write more at the moment but if you can wait a few days I can give more insight about the history of the OPENSC_DRIVER env variable. I just skimmed through this issue, and my initial reaction is that I was not aware of any side effects but I'll need to take a new look to refresh my memory, something I cannot do at this moment.

[mouse07410]

Some apps/users may rely on one, some - on the other.

I'm against messing with something that works. Suggest we leave this alone.

[mouse07410]

And if there is more than one way to accomplish something - well, fine with me.

[frankmorgner]

@Jakuje my understanding is the same, which is why I removed force_card_driver in #1257. However, I kept OPENSC_DRIVER since it seems to be used by some developers.

I agree that the configuration file should be parsed even if OPENSC_DRIVER is specified.

More generically, I wonder if we should trust environment variables at all. For example, I'm using a restricted opensc.conf that only enables the stuff that I need (and tested). But nevertheless, changing OPENSC_DRIVER may load some other code and OPENSC_CONF may even do more. A simple anti-feature would be logging of the PIN to debug_file which may be read by everyone...

[Jakuje]

oh. I was reading through that PR some time ago, but forgot you removed also the force_card_driver.

But reading through the code and changes you proposed again, you did delete the option, but you left the logic behind, which is causing this behavior (by setting the forced_driver variable in sc_set_card_driver()). My proposal was to leave this function for tools (I am not quite sure what is the use case there either -- it set the driver regardless the detection) and use the semantics of card_drivers option (merely calling del_drvs(), add_drv()). Or do that transparently in sc_set_card_driver() function.

The other question about security is more broad. While all we agree that it is very useful for debugging (both of the environment variables) and configuring different applications with different configuration/driver, the security is questionable. But do we have to defend against this attack vector? When environment is compromised, the attacker could already configure other tools to log quite much everything and do other nasty things.

Anyway, the security is not the question of this topic. The variables are there now for long time and will probably not go simply away (if one should go, it would be the OPENSC_CONF, which can be more dangerous). And most of the things we want to adjust in runtime are really the drivers selected so once the OPENSC_DRIVER will behave correctly, we can discuss if we want/can strip it more.

[mouse07410]

I say no, we do not need to defend against that attack vector.

[mouse07410]

And I cannot imagine OPENSC_CONF going away. Besides, I use that feature myself.