New pambase choices

So while I’m still hoping somebody will hire me to finish do a complete audit I’ve at least started working on the new pambase code. To do so I had to make a few more choices than simply maintaining the current status-quo in running state.

First of all, I changed the backend language used to describe the rules. Up to now I abused the C preprocessor with the C macro language; this allows for arithmetic comparison of (properly formatted) version numbers but doesn’t allow for increments and decrements, and it’s not extremely flexible. The new pambase will make use instead of GNU M4 (the same language used by autoconf). M4 is designed to be a macro language by itself, which makes it very simple to implement the kind of copy-and-paste of rules that pambase needs. Not only that but it’s already part of the system set both because of autoconf and because it is one of the standard POSIX utilities.

The second decision to make is a hard one and that is to actually stop proactively support OpenPAM and the FreeBSD operating system. It’s not something I’m doing lighthearted, and I’ll make sure not to force the requirement for Linux-PAM more than it is needed, but right now there is just not enough help to support both implementations. Plus while it made totally sense to support OpenPAM when I first added support for it in Portage (with Linux-PAM series 0.78), with the most recent releases, in particular 1.1 series, Linux-PAM not only doubled up the featureset of OpenPAM, but it also provides a clean interface and very polished code. By focusing more on Linux-PAM (staying, though, as independent as possible from the operating system) it’s quite possible to handle multiple authentication schemes.

Speaking about authentication schemes, when I first implemented Kerberos support in pambase there has been a few problems to be polished with it. For once, chaining a number of authentication schemes is not easy: you cannot use the required option, obviously, because you authenticate usually only against one of the authentication schemes at once; you cannot use optional because otherwise you might login even if all the schemes fail; you cannot use sufficient because that stops the chain at the first authentication that works, and you might have further restrictions in chained services.

The only solution I could find was to move further the solution I applied to Kerberos: using Linux-PAM”s advanced result specification, if any authentication succeed, then instead of proceeding with the rest of method specifications, it jumps directly to the end of the current chain, where a pam_permit.so entry will let authentication succeed. if none of the authentication methods succeed, then there is a pam_deny call that ensures that login fails.

Another problem related to multiple authentication schemes is how to handle password changing, which is another problem that we have faced with shadow. Right now we have a lot of configuration files specifying password method chains. A lot of those have likely be added due to misunderstanding that service class as “check against the password” (which is not the case, that’s auth!). For instance, sshd by default provides a password class chain, but OpenSSH does not allow you to change your password in any way.

While cleaning up all the configuration files to ensure that they only list the services they support is something that requires the full audit that I wrote about, at least I will predispose the new pambase to handle that correctly. This means that system-auth will no longer provide password chains; instead a system-password chain will be added that will take care of that and will be used by the very few packages that allow for changing passwords (such as shadow). interestingly enough, the situation here is going to be quite different from what we have now. Many of the alternative authentication methods (PKCS#11, OTP, Yubikey) will not allow to change the authentication password, so they shouldn’t be listed there; some others have different tools to change password, such as Kerberos (kadmin) and pam_ssh, and would most likely not have to be listed there. But for those that have to be listed, including Gnome-Keyring, changing password should act on all of them, not just one, so the skip system described above cannot apply there.

Unfortunately, not only this require quite some changes on the pambase package, but it has to be coordinated with a number of other packages, such as shadow, sshd and so on. Given this, don’t expect it until mid-to-end of November. Probably later if I find some other job to follow. Once again, if somebody is interested in having better PAM support in Gentoo, it can be done faster, but not in my spare time. It’s not something a single volunteer can deal with in spare time.