here I am blogging once again bout PAM, which seems to be my main issue nowadays. First of all I have to say I’m still looking for somebody to hire me so that the complete audit can take place, especially since, as I’ll be expressing in a moment, the situation is worse than I had anticipated.
First of all, I wanted to finalise what I started over an year ago with the pam_pkcs11 support in pambase. To do so I needed to be able to connect Gilles’s token to a virtual machine (since I didn’t want to experiment on Yamato itself). Doing so I found not one, but two libvirt bugs.
The first was a problem with passing the device bus and number; libvirt sent them prefixed with zeroes to form 3-digit numbers; but then QEmu interpreted them as octal numbers, so 001:016 became 1.14. Easy fix by swapping two sprintf() calls. The second was nastier and I was able to complete the fix just yesterday: when the kernel has support for CGROUP, libvirt uses it as a security measure, to ensure that the virtual machines can’t allocate more memory than they are supposed to, or access devices they are not supposed to. Unfortunately, if you asked libvirt to connect an USB device to QEmu, its device pair wasn’t added to the list, so QEmu was unable to use it. The first is fixed in 0.8.5; the latter in the r1 backports in Gentoo, and sent upstream to be fixed there as well.
Beside dealing with the bugs in libvirt, I also made some changes to the new pambase branch using M4, which actually works as intended now. Thanks to the comments on the previous article the situation is improving actually. In particular thanks to MK_FG, I tried again the substack/sufficient method and it works quite fine. Using simply sufficient will create a problem if you don’t want to have a stop-stack feature at the end of the system-auth (which would create other problems to other services, as I’ve learnt the hard way before), so this should be much better.
Indeed, in the new branch there is implemented support for pam_pkcs11, pam_ssh, pam_krb5 and pam_unix all together! Also, for the password-changing service now supports running both pam_passwdqc and pam_cracklib (before, only one would on the service). It doesn’t, though, work for changing the PIN of smartcards or the Kerberos password. I’m going to implement pam_p11 support soon enough.
While working on this though, and having a number of stable requests going on to fix various things (like the shadow problems and ConsoleKit), I also found that two days ago a new Linux-PAM version was released, 1.1.3, with a few security fixes that will likely require a quick stable. But more than security there is another reason why this version is notable.
You might remember that last time I stated that only two patches were applied on version 1.1.2. Well, this time around no patches are applied over the released Linux-PAM! This makes it the first version in five years that Gentoo is shipping without custom patches at all, and thus without needing re-building autotools. It is indeed a milestone for us.
Dropping the old 1.1.0 version also meant removing four extra patches from the tree; once 1.1.3 will be stabled on all arches, I’ll be removing the remaining patches, which account for about 14KiB of the tree as it is.
After all these good news, there are bad news as well; as it happens, while I’m the only person in the PAM team, the one that is following Linux-PAM, pambase and the like (soon to be joined by Constanze luckily!), there are a number of other people who add PAM modules. Lately, two fingerprint-based PAM modules were added to the tree, and both have multiple mistakes in them. Am I happy about that? Not really.
Beside, there are still problems with symbol collisions; for some packages they are easier to fix than others…
