I've been reading the Practical Linux Security Cookbook, one of the free ebooks provided by Packt. Like many of their books, it isn't as well edited or as well thought out as it should be, but it's provided me with some good pointers. In this case to the use of standard USB memory sticks as security devices on Linux.
Most of this turns out to be moot because it appears entirely abandoned by the distros I'm interested in. I did a great deal of work figuring out the details on a Bunsen Labs Linux installation: BLL is based on Debian jessie, which is now 'oldstable'. And looking into it further, it appears it's not even in the new stable 'stretch,' and likewise not in new testing ('buster').
All of which is driving me to take another look at U2F.
- any USB storage stick can be used as a security device, ie. you can authenticate simply by inserting the USB stick and typing in the username at the login prompt
- there are boat-loads of caveats
- you can choose between a mode ("sufficient") that allows you to log in just by inserting the USB key (the password without the USB key will also work), or another mode ("required") where both the USB key and the password are required
- if you choose "required" mode, it's required of all users, system-wide (in "sufficient" mode anyone without a USB key could just use a password as previously)
- not all X Display Managers were compiled to support this: while XDM and slim work, LightDM (Bunsen's default) doesn't
- rebooting to single user mode allows you to bypass this security scheme (I don't like this, but if an attacker has enough time to do this then they have physical access and you're screwed anyway)
It doesn't appear to be possible to use more than one USB stick per person, and this is where the whole thing really broke down for me ... Most implementations of U2F allow you to register more than one key, as an alternate. What if you lose one? What if you overwrite it or reformat it? Easy to do with a USB stick.
It was a good idea, but it looks to me like it was mostly one guy with a Github repo and not enough people got behind it to give it the versatility that it needed. Too bad.
Most people shouldn't bother with the details of a deceased bit of Linux functionality.
pamusb-confis used to add both devices and users
- each device is registered by a user-provided name (registration consists of registering the vendor, model, serial number, and partition UUID)
pamusb-confcan only add users and devices to /etc/pamusb.conf - it can't remove old sticks or edit the information about existing ones
pamusb-confwould create a second entry for a stick if you gave an identical name, and it appeared that neither entry would work after that (same for users)
- /etc/pamusb.conf had, by default, 644 permissions. Given that it holds full descriptions (UUIDs, partitions, vendor, name) of all sticks, that seems like a bad idea ...
- /etc/pamusb.conf is an XML file
- at each login, the existing cryptographic pad on the USB stick (.pamusb/<username>-<hostname>?) is compared to the one in the user's directory (~/.pamusb/<stickname>), and then new matching pads are recorded in the user's and on the partition
- it appears to use
pmountto mount and umount the drives as the user