For new tickets please use the main OpenSC Trac (direct link)

Ticket #20 (new enhancement)

Opened 3 years ago

Last modified 3 years ago

Allow to use the card transparently in "action" hooks

Reported by: noraef Owned by: somebody
Priority: normal Milestone:
Component: component1 Version:
Severity: normal Keywords:
Cc:

Description

Howdy !

First, thanks for your work with pam_pkcs11 : it is a really valuable piece of software.

Now, for a wish : an awesome feature to pkcs11_eventmgr would be to be able to use the smartcard in action = "..." hooks, if a PIN was requested from there.

This would bring SSO to a truly other level. For instance, as things are for now, pam_ssh can spawn an agent, if the right pass for a SSH key has been given, but it will not work with smartcards keys (it verifies the password corresponds to a key in ~/.ssh, and only then adds it to an agent it launches).

Well, if one was to call for an "ssh-add -s0" from pam_pkcs11 actions, and pam_pkcs11 was to give the PIN to this query (for instance, with a custom askpass like done on  http://www.debian-administration.org/articles/587 for pam_mount), the user would benefit from its smartcard right from logging, without having to issue the PIN another time, like for caching it into an agent...

This would in turn allow for pam_mount to mount an SSHFS share, for instance, if it was called subsequently, using keys from the card.

This would also be great if this could work for gpg-agent.

My abilities to code such a thing are severely limited, so I don't know what would be the best way to implement it (as for ssh-add, it seems to either need a TTY, or an askpass application... maybe built-in askpasses for gpg and ssh would do the trick), but bringing such feature would be excellent... I hope I made the idea clear enough and this is somewhat feasible.

Regards

Tuomas Noraef

Change History

comment:1 in reply to: ↑ description Changed 3 years ago by noraef

My bad... this is silly, as pkcs11_eventmgr is not yet started before actual login takes place...

Could then another set of actions be added, to be ran just after successfull authentification, but still inside pam_pkcs11, so agents could be loaded with the PIN ?

comment:2 Changed 3 years ago by ludovic

Maybe we should work on a more generic application launcher. A PAM module that would execute commands and pass them the user password or PIN fetched from the PAM environment.

This PAM module could call "ssh-add -s0" or whatever else the administartor has configured.

I don't know if such a PAM module already exists. Would that solve your problem?

comment:3 Changed 3 years ago by noraef

Thanks for such a quick answer !

What you are suggesting would basically be a pam_exec that would allow PAM_AUTHTOK export, or at least direct usage, no ?

I guess this could do the trick, but I am a bit worried by doing this without being sure the PIN is right or not... by embedding this inside pam_pkcs11, and with special care taken before launching the commands (ie verifying the PIN is correct), one would avoid launching a set of actions with the wrong PIN, that could end up locking the smartcard (though it could be avoided using "requisite" for pam_pkcs11, so it would not wreak havoc with subsequent actions... but I must confess I do not really like using "requisite").

It could be a good idea to manage this as a "session" stage of pam_pkcs11, so to do different things upon session start (SSHFS mounting, for instance) and ending (SSHFS unmounting, for instance).

But more generally, yes, I guess being able to launch the commands one wants would give the better opportunities (using ssh-add, feeding cryptsetup with pkcs11-tool gotten private objects, ... though I do not seem to find a way to force gpg-agent to pre-cache a PIN/password before using it :( ).

What do you think about it ? Anyway, such kind of SSO with smartcards would really be great :) I have always considered the management of private keys under the aspect of files on disk to be a major pain, and smartcards are a way to salvation... but if I only had to type the PIN once on login, wooaah !

While I am at it, something else worries me a bit (my smartcards and readers are still being shipped... though I already have seen OpenSC and such on a friend's computer, and have positively been impressed with it, which made me finally decide to buy some). It seems logical to me that there should only be one smartcard reader plugged when PAM is used (as there is no real way to specify which one to use then)... but as for pkcs11_eventmgr, noticeably for uncaching PIN on unplug, is there something made so one can specify the ID of the reader ?

If not, tell me : I think it would also be good to fill a new ticket for this. I intend to use smartcards and readers in addition to the casual (login, SSH, ...) one for things I do not use so often (VPN for instance, or SSH-logging to much more crucial identities than my usual one), and being able to take more aimed actions (only uncaching PIN from ssh-agent for the reader that just got unplugged, and not for the others, for instance) would be nice.

comment:4 Changed 3 years ago by ludovic

pam_exec should work with a wrapper between pam_exec and the command you want to execute. The wrapper would be used to:

  • get the PIN code from the process environment (PIN code set by pam_pkcs11)
  • pass the PIN to the executed command(s)

If the PIN is not correct then pam_pkcs11 would not set it in the environment. If no PIN is defined in the environment then the wrapper would just exit. So no wrong PIN would be given to the commands normally executed by pam_exec (to avoid card lock after 3 wrong PIN tries).

Would that work for you?

Maybe the wrapper would have to be inside pam_exec to get access to the PAM environment. But that is an implementation detail.

comment:5 Changed 3 years ago by noraef

Well, I guess that would be good.

But the wrapper idea, if integrated directly into the execution module, would turn it into something much different than pam_exec (it would be a pam_exec embedded in a condition ruled by the wrapper), I guess. Would not that require to fork pam_exec ?

I am not sure its devs would allow such a thing in genuine pam_exec :

  • kind of redondant with the "requisite" stanza, for the conditionnal aspect, though the wrapper has before most interest for the particular case of smartcards, which could get locked without it - and I thinks "requisite" may be some bit of a radical solution, towards this aspect, and even dangerous, if one was to forget to set it, during experiments ;
  • it could get a bit risky to lend the password for the kind of general use and simple module that pam_exec is ; I am not sure it has been designed with this in mind, and I can imagine some people not really liking the idea of letting this particular module be able of such things ;

... which is why I suggested integrating this into pam_pkcs11. Maybe this could turn into a pam_exec_pkcs11 or pam_exec_conditionnal (whatever it ends up called) ? There would then be no need to make pam_pkcs11 really more complicated than it is (except for declaring to the environment that it succeeded), while allowing to accomplish what I want, and without making the classic pam_exec maybe too much powerful.

To sum it up, what would work for me would be something allowing, during authentication (so to get SSO), to pass the PIN (PAM_AUTHTOK ?) to a few userland commands, but only after pam_pkcs11 has verified that the PIN is correct, so not to lock the smartcard with failed attempts... To me, this would really represent the Graal of authentication in the free world, however it ended up to happen.

Thinking of it, the "session" stage I mentionned earlier would not really be that useful, as this would not need the PIN (ideally, keys would already be in agents, for instance), and could thus be accomplished with classic pam_exec or pam_mount.

Well, your abilities at the "implementation details" undoubtfully surpass mine (I can write a few script languages, but have never really coded C/C++ or such things, except for a couple hours at school, some years ago - I am more of an enthousiast than of a real coder [which I regret... but for now, I do not really have time to start learning more advanced languages]), so there is no doubt you would come up with a better implementation than I could... or even simply with an implementation ;)

Note: See TracTickets for help on using tickets.