You might wonder why the PAM support for special authentication method is somewhat lacking in Gentoo; the reason is that, mostly, I maintain PAM alone, which means that you get to use whatever I use myself most of the time. One of the things that I was very upset we didn’t support properly was the Smartcard/Token based authentication; unfortunately, while I got two smartcard readers in the past months to do some work, I hadn’t fetched a smartcard yet, and tokens seem to be quite difficult to find for end users like me.
Thanks to Gilles (Eva), I now have a token to play with, and that means I’m looking to write up proper support for token-based authentication (and thus, smartcard-based as well). This already started well, because I was able to get one patch (split in three) merged in pam_pkcs11 upstream (available in the gentoo 0.6.1-r1 ebuild), as well as cleaning up the ebuild to work just like it’s supposed to as a PAM ebuild (for instance not installing the .la files which are not used at all).
But since this is not yet ready to use, it’s easier if I show you how it works after a day or two of tweaking:
Please note that this is not really “production ready” in my opinion:
- the pam_pkcs11 module uses the
/etc/pam_pkcs11directory for configuration, but almost all PAM modules use/etc/securityfor their configuration; - the pkcs11_eventmgr daemon has to be started by the user manually, but it uses a single, system-wide configuration file (
/etc/pam_pkcs11/pkcs11_eventmgr.conf), this does not really seem to be the right way to handle it for me, but I’ll have to discuss that with upstream; - most likely we want to provide, based on USE flag or in a different ebuild, some scripts to handle the event manager more easily, for instance making it start on each X and console login, and making sure that the login is locked as soon as the key is removed;
- the event manager polls for the card, which is using CPU and power for no real good reason; a proper way to handle this would require for udev to send signals on plug and remove so that the event manager can handle that; since the exact key needed is unlikely to be known at rules-generation time, this might require adding a central daemon monitoring all the smartcards and tokens and passing the information to registered event managers.
This mostly means that there’s going to be a long way to go before this is ready, and I’m pretty sure I’ll have to write a complete documentation on how to set it up, rather than just a blog post with a video, but at least it’s going to be feasible, at one point.
Please feel free to comment on whether the video is useful at all or not; I’m trying to experiment with less boring methods of explaining stuff related to Gentoo and free software in general, but I have no clue whether it’s working or not, yet.
*awesome job Diego!*I’m really excited by your work to properly add a decent Gentoo support for token/smartcard authentication; I should use them for my local infrastructure and for my personal info, but I never done the “jump” due to the fact that there is not an openhardware token and closedsource solutions are really expensive.I’m available to contriibute to the writing of the documentation/guide.
I am also very excited by this! I quite agree with your comments. I work in the PKI/x509 smartcard area and have some experience that might be helpful. We use the Aladdin eToken (recently acquired by SafeNet) but have also evaluated several other vendors in both the USB form factor and the more traditional smartcard form factor. We like the eToken and have a small deployment under Windows.If you need input or suggestions based on personal experiences or enterprise deployments, I would be happy to assist. For example, one of the nice features that the eToken provides under Windows is some caching and the ability to forward credentials to remotely located servers (via RDP). This is helpful when dealing with lights out data centers and multiple machines.Please let me know how I might assist with your future pursuit of this great addition to Gentoo!Wayne Stenson
Am I the only one without sound in this video, though YouTube is working perfectly? Or is it intended so?
The sound worked fine for me. The volume could be better but is good enough.
Re using signals as a proper way to get the token state: such a signal can get lost. Therefore, a combined approach makes sense: signals for responsiveness, and periodic checks as a safety measure covering reader hardware defects. Such defects can manifest themselves when a user quickly inserts and removes a token repeatedly in order to confuse the system.
Great work!The pkcs11_eventmgr can get config_file= parameter.Also, the udev alternative is somewhat incorrect, as for pkcs11_eventmgr, as using another interface is somewhat none standard.The correct solution is to use PKCS#11 slot events, in this case the function returns only when there is a change in slot status. How the PKCS#11 provider does this should be transparent. Problem: OpenSC provider internally polls readers.There is also a problem to associate between user and specific slot…I don’t like the pam_pkcs11 code, it is very complex, and does use PKCS#11 correctly in many places. I tried to fix it once, but decided to leave it alone.
Great work, dude.I think this would be a nice feature for the incoming future.Furthermore I’d like to see this applied to some kind of security pass like truecrypt images, ciphered filesystem and so on.
Hi,I’ve been trying to add correct smart card support to KDE (esp. 3.5.10) these days for Pardus Linux.There seem to be a lot of things to do for a solid integration. pam_pkcs11 seems to work quite well but is premature as well as the pkcs11_eventmgr daemon.1. How the pkcs11_eventmgr should be started? If it’s started per-user, it should prevent itself from being killed as it’s a crucial daemon which will lock the desktop. But for easing my work, I’m currently running it as root and locking the desktops using dcop calls with the –user parameter. I’m determining which user to lock by looking at the environments of processes for the DISPLAY and PKCS11_* environment variables. Hacky but it works.Once the daemon will be auto-spawning itself when killed, I think the best place to spawn it is in the pam_sm_open_session() if possible technically. It should be terminated in pam_sm_close_session() properly.2. pkcs11_eventmgr uses polling which is bad. Ideal would be udev but the problem is that there are readers and tokens. Readers are plain USB devices detected by udev but there isn’t support for asynchronously detecting token inserts/removes. According to a blog[0], some readers supports an interrupt endpoint but still no support in udev for these events.3. How to properly detect which session should be locked upon a card remove? There may be multiple card readers and multiple tokens, but one of them actually logged the user in. In order to correctly do this there’s need a for a live database of which inserted token logged in which session based on PKCS11_* env variables and certificates. Then a daemon can understand if a removed card was really used to log in an online user. If PAM was a daemon, that would be asked to it but this is not the case :)Well that’s all, I’d like to share info on this if you’re still interested.[0]: http://ludovicrousseau.blog…