What’s the plan with PAM?

Okay after quite a few days working on pambase, and a few discussions, I think I have a decent plan going forward to implement the new pambase. You can find the current status of the code in the repository but of course it is not really enough to get to test it; I’m still undecided whether I should add an overlay to the same repository, or get a PAM-only overlay where I can dump all the ebuilds for review.

So here is the rundown. First of all, as I said many times by now, I’ve replaced the C preprocessor with the M4 tool instead; this provides me a much more complete macro language, which means I can easily add further support, and mess around to disable/enable options as needed. Thanks to this, we now have a number of other authentication schemes, such as LDAP, PKCS#11 (via pam_pkcs11, I’m also going to add pam_p11 which is definitely simpler to set up even though it has less features).

But the main difference is in the services that it provides out of the box; there are now a number of new service files that will be used directly or indirectly by all the packages using PAM in the tree; while I didn’t like increasing the number of service files, there are slight differences in the behaviour of each that makes it necessary to split them around. For instance a remote login by default will not force root to login on a secure tty (although you might want to do that!), and as I said before you cannot easily use the same auth chain for both a login and a password-changer.

Another issue that I’m having trouble wrapping my head around is that you really cannot use the same authentication schemes for both interactive and automatic services; so for instance if you’re logging into a remote mail server you cannot provide an access token to do the login (since it requires it to be connected locally on the server). From one side, the same goes for ssh actually… I guess the only reason why I don’t feel as compelled to tackle it there is that I don’t use PAM for authenticating on SSH and neither should you in most cases.

What is now available in the repository is mostly working fine; although it remains a problem of interfacing it properly: I’m still unsure of the way the various modules stack up. For what it’s worth, one of the most obnoxious things I can think of is properly supporting pam_loginuid: it should be used by services both interactive and non-interactive to properly set auditing to log the user who’s acting (so even if there is privilege escalation you can track down who exploited it), but it should thus not be used by either sudo nor su, nor by things like PostgreSQL or Drizzle.

Right now what we’re going to have for certain are these services:

system-local-login (name kept for compatibility) will be used basically only by login — I’m actually tempted to provide /etc/pam.d/login directly as part of pambase, given that it is, yes, provided by shadow right now, but it’s also used by Busybox;
system-graphical-login will be used by all the graphical login managers: GDM, XDM, KDM, Slim, Qingy… the idea behind this one is that it is, by default, quiet; unlike what I originally planned, and what GDM now does, this one will not avoid running pam_mail, pam_lastlog and so on so forth; they will be, instead, put into their silent modes: the data will be updated, the variables will be set, but no output will come from them; unfortunately things like Qingy will cause double-setting of the same variables; that’s a problem for another time;
system-remote-login is the one service used by sshd (and theoretically by rsh/@rlogin@ if they made sense to be used);
system-services is the one used by the various cron daemons, atd, start-stop-daemon and so on: they have no authentication done, but they do have account validation and, most importantly, session support; as I said above, these should set the login uid to ensure that the audit framework knows who to blame for problems in here;
system-password is the service used by passwd and the other password changing tools; it only deals with the Unix stack and with (eventually) Gnome-Keyring;
system-auth-backends and system-login-backends are the two that give me more trouble to deal with; they have the actual calls to the backends used for authenticating; they are separate so that we can actually have them set up for optionality, so that only one is needed to succeed to allow the user to authenticate to the system, by using the substack option on the previous service; beside substack, the only other solution would have been to use the skip method I’ve been using up to now, and that I haven’t entirely stopped considering to be honest.

Also, among other things, I’ve removed the nullok option from the authentication and session support for pam_unix; this basically means that you can no longer have valid accounts without a password set; the idea is that this will not cause trouble with autologin features, but I’ll cross that bridge in due time. For now it should be enough to have an idea that the code is out there and how should be more or less be used.

Comments are, as usual, quite welcome.

It’s getting boring I know; more ConsoleKit braindumps

Since people insist that I don’t make myself enough verbose on the matter of how pambase gets implemented, here comes another post detailing some of the trouble me and Samuli are going through to make Gentoo a viable modern desktop.

First of all let’s make it clear what the target is: ConsoleKit is the modern implementation of the common necessity to provide different authorisation to users depending on whether they are connected on the local system or connecting from a remote system. The reason why this is useful on desktop systems is that you obviously don’t want somebody from a remote system to access your USB devices or cdroms, or soundcard while not being root.

Interestingly, the idea of this authorisation has always been tied tightly with PAM; the first try to get this working was the RedHat-generated patch that added the infamous pam_console module to Linux-PAM; one of my first problems to solve with Linux-PAM, and one of the first patches to be killed was indeed that which added this module. Unfortunately, the method used by pam_console was a very bad one: it changed the owners of device nodes in /dev, but if a session was abruptly interrupted, then it wouldn’t set them back correctly. Besides, it didn’t work that well when multiple users were logged in on different TTYs.

ConsoleKit handles this in a much different way, even though it still uses (mostly) PAM to do the work. Basically, when you open a new login session (and just login, not authentication for services), the PAM connector connects (sorry) via D-Bus to the daemon to tell it that there is now an open session; as long as that connection is open, the session is listed, and all the processes started from there are authorised. What’s the catch here? Well, to know which session a process belongs to, you have two obvious ways; neither of which is very reliable: you can check the parent process ID (which is not going to be fun when the process detaches into background), or you can check if it has the same open tty (which is not going to work when the program makes not use of ttys at all)., or you can check for the presence of an environment variable, but you will guess it’s a very bland way to solve the problem this latter one.

Luckily, Linux already provides a decent way to identify a session: the /proc/self/sessionid virtual file — but that one needs the kernel to support the Audit framework features. This is the reason why ConsoleKit is now asking you to enable that stuff in the kernel, it’s not just a mood swing, it’s rather a requirement to have proper session isolation. Unfortunately for this to work you also need that each session is created (and destroyed) with login — and we have PAM for that; indeed the module responsible for taking care of that is pam_loginuid that has been added in the latest (non-M4) version of pambase.

The bad side is, though, that it doesn’t help if pambase is fixed, if any other maintainer of a package using PAM is not listening to me (or insist that I shouldn’t dictate the PAM policies even though I’m the only one who seem to have a clue on how things have been asked to be supported for quite a while). This means that we have to fix all the graphical login managers (gdm, kdm, wdm, xdm, entrance, slim, qingy, …) to include the correct service file (system-graphical-login), so that the proper sessions are set up. Not just that, but as we were able to debug with Samuli, we need to fix both baselayout and openrc to use the system-services stack (so finally abiding to pam_mktemp as it was supposed to do since a very long time ago), since otherwise a service started not by the rc system but rather from a running logged-in session would inherit the root’s login session id, which is obviously a bad thing.

This was designed to work correctly with system-services, but as it turns out, unless I actually pay attention to each and every package that should use them, even when I actually coordinate integration of the new services into pambase with them, or I do the original changes myself, the end result is simply bad. This is why an audit is necessary as I said before.

I was intending to end this post with a description of the incompatibilities between Qingy and ConsoleKit, but after writing a few paragraph, I decided that without enough diagrams of what’s going on, there is no way I can actually provide you with a description of it that can be understood by those who haven’t studied PAM and login themselves. So for now I’ll close on this page, and will post during the week the notes on qingy.

But I’ll also have to warn you that for the next weeks I’m quite swamped with finishing the documentation of one job and starting the work on a new one, so the normal Gentoo stuff is going to stay hidden for a while; if you wish to help with testing or motivation it’s certainly appreciated. I’ll see to provide a testing pambase ebuild on the repository itself so that those of you who feel daring enough can get to test it. As a homework for anyone who’s interested, feel free to open bugs about desktop managers in tree and official overlays – with pam-bugs@g.o in CC – if they should be migrated to system-graphical-login once the new pambase is released.

Hey host, give me a new login please!

One of the reasons why I’ve been spending all this time rewriting and extending pambase lately has been that Samuli asked for my help to sort out the ConsoleKit problems he’s been seeing for the past months. Authorisation problems with both XFCE and (less often) GNOME are mostly due to a misconfigured or misbehaving ConsoleKit, and the main cause of that seems to be PAM-related.

Indeed, after a bit of poking around I came to the idea that PAM needs a whole audit and that the new pambase was really important to work on. As it happens, most of what I wrote yesterday tied with the need for the graphical manager and the text login to differentiate their session chains — there are bonus points because we can solve a few more problems with noisy modules at the same time, but that’s beside the point now.

So there has been two main issues here:

the nox11 option given to pam_ck_connector need to be dropped for X logins;
all the desktop managers need to move to use the system-login (now system-graphical-login) service, rather than using system-auth directly.

As messed up as this might be, now that I reached the end of the alley, I guess the right questions I had to ask were:

why none of the managers used the system-local-login stack as it was intended with pambase? the answer is actually what I wrote in the previous post: the noisy modules (motd/mail/lastlog) caused hiccups and noise on login with GDM and the others; which is now solved by using a different service for them;
why was nox11 added to the system-login service? Because when I was suggested to set it up, whoever gave me the line (I don’t remember who was, I didn’t know enough about ConsoleKit to come up with it myself — and I still don’t know much about it) only considered it to be used with GDM; since GDM takes care of creating the session itself, there is no need for the PAM module to do so.

Unfortunately, as it happens, GNOME is no longer the only environment to use ConsoleKit, and thus GDM not the only desktop manager used by users that should be authorized by it. The other desktop managers, though, are not going to integrate ConsoleKit themselves (heck, PAM was designed with this need in mind) so they should be using the module without the nox11 option. So what happens if we disable it? Well, GDM will create its own session after the one from the PAM module is created; the session coming from PAM will result unused, but won’t hinder much. It’s an acceptable compromise as well. A more solid situation you’d have if you simply disable ConsoleKit by USE flags on gdm, so that only the PAM version is applied — at the time of writing this, the ebuild does not allow you to do this though. For whatever reason they decided it was a good idea to use a “same” dependency between the ConsoleKit support in GDM and pambase even though it would rather be a “either or” dependency: either in GDM or in PAM.

So this should solve the problems (once applied of course) for GDM, KDM and XDM. Unfortunately Slim, which is the manager Samuli suggested me to begin testing with, still doesn’t work. Oh, ConsoleKit creates the session, all right, but it is not marked as local at all. Why is that?

Well, among the attributes PAM applications can provide to the modules to test against is one called PAM_RHOST that stands for remote-host; XDM, GDM and KDM only set this if the DISPLAY variable does not start with a colon, which mean that we’re displaying on a remote server; ConsoleKit decides that the session isn’t local as soon as it finds a rhost value; on the other hand Slim sets the rhost to localhost in all cases (and so does the sample pam_env configuration file that we don’t actually execute anyway). This basically means that even once the PAM issues are all sorted out, Slim-initiated sessions will result non-local.

Now, where was I? Ah yes, I have to just make sure that all the ebuilds in portage call the right service. Piece of cake, right?

PAM, logging in and changing passwords

I’ve been spending the past ten days/two weeks handling two full-time job at once; one was Windows-related so it won’t have any direct effect in what I’d be posting on the blog, the other involved Amazon EC2, so you’ll be seeing more ~~rants~~ sorry I meant posts on the topic soon. But first, …

Thanks to Constanze who became a full-fledged developer (congratulations!), I’ve been able to breath a bit more widely for what concerns PAM; another positive note comes from Eray becoming developer as well, which means I can get someone looking at pam_krb5 package. Which means I can get back to work on the M4-powered pambase package so that hopefully before end of the year we’re going to get it in testing at least. Additionally, user prometheanfire on #gentoo-hardened provided me with a sample configuration for LDAP that should make it much easier to implement it on pambase.

But the situation starts to become much more complicated; for instance, the ConsoleKit situation is so intricated that making it behave as intended is actually quite difficult: the invocation of the module is different whether we’re going to authenticate a text login or an X11 login session; some time ago we also found the hard way that some graphical login managers fail badly when you print too much information on the PAM output channel (such as Messages of the Day, the last login data, and mail status). This all results in having to have different sessions for local text and local graphical logins. I have a huge headache already when I start to think about XDMCP already.

This turn of events also makes me think that I should simply drop the system-login service that I’ve used in the previous iterations. The reason to use and include this service was to avoid duplication, but with M4, duplication is avoided during build time, not after install. This should make available only the three “leaf” services: system-remote-login (with optional ABL support), system-local-login (not renamed for compatibility reasons) with text-based login, and (by default) mail/motd/lastlogin modules; system-graphical-login with support for X11-based ConsoleKit sessions as well as without the extra verbose modules.

A note here: somebody asked me why of the minimal USE flag for pambase; the reason is relatively simple: even though the output of those can easily be discarded, they will be kept loaded in memory by processes such as sshd and fcron; dropping the modules from the services mean also reducing the memory usage of those process, minimally, but it does.

After the login process is sorted out there is another problem here and it has to do with changing passwords; I’ve said that before, but I’ll repeat it here. When the new pambase will be put in place, software that is able to change password will have to be updated to use a different service to do so; this will hinder the changing of password through sshd that was noted in the comments of one of my previous posts, but it is necessary if we want to have proper restriction among login methods.

The problem is that with PAM design, for what concern changing passwords, you end up with either you have to know all the currently in-use authentication methods or you have to know only one of the authentication methods and then you change all the authentication method to the new value or you change only one authentication method to the new value.

The end result is that I can’t think of any way to do what would make sense: change the token only for the systems that actually use the current password provided. Lacking this the situation is that we cannot have a single tool to do everything, so we’re going to have to stick with many different password-changing tools: passwd, chpasswd and their cousins will only require the Unix password and will only change the Unix password. You’re going to use separate tools for Kerberos, LDAP, SSH keys, PKCS#11 tokens, …

While it might sound as suboptimal it’s a compromise that actually make pambase manageable without having to resort to actual custom Linux-PAM implementations. I hope you can all agree on that.

Anyway, this only acts as a braindump; I hope I’ll be able to set up real documentation about the pambase system at one point or another, including some simple drawing to show how the authentication flow actually happens. Unfortunately if you remember, I noted that OpenOffice is the only decent software I can find to write flowcharts; unfortunately that is both cumbersome to add to a GIT repository, cumbersome to auto-produce results (when what it exports is what you wanted), and finally quite expensive in term of dependencies. I should probably try Inkscape back, possibly tied with rsvg (now that gdk-pixbuf works without X) would be a decent choice.

Gentoo PAM developments

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…

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.

Anybody hiring me for PAM?

This post might sound like a nasty plug, but I’m really doing this because it seems like the only solution up to this point.

In the past few days some trouble came up on the PAM side again. Let me try to put this into prospective: if nowadays I can actually find some use in knowing how PAM works, I joined the PAM team four years ago while working on Gentoo/FreeBSD because I needed configuration files migrated to a format that worked there as well as Linux. Since then, Azarah went missing and the whole of PAM was shoved on my back. Nowadays, I maintain the Linux-PAM package, a bunch of random PAM modules, and should oversee over the general PAM configuration in Gentoo.

Unfortunately, this requires also a lot of coordinating skils, and time to do the coordination: maintainers of other PAM modules, and maintainers of packages that use PAM themselves, should talk with me about the default configurations and the like; instead I’m usually reactive on that matter. And that is, as you might guess, not the best of the experience, nor the easiest of the tasks.

I have written before about the need of a new pambase and this is now obvious to actually implement proper support for multiple authentication methods like Kerberos, LDAP, PKCS#11, YubiKey, … I have a few ideas on how to solve this, namely changing the current situation with a few predefined, hidden chains (.gentoo-session-minimal, .gentoo-session-console .gentoo-session-graphical) wrapped on the system-* series of chains, all generated with M4 rather than the current C preprocessor (that lacks any kind of arithmetic capabilities).

But even more than fixing pambase, there is the need to review the packages that use PAM. A few days ago, Samuli complained to me that ConsoleKit was not being executed properly on login(1) — turned out the problem was that /etc/pam.d/login was not calling back into system-local-login as it was expected to. Root cause was that the modified PAM chain file was replaced with the previous ones (which didn’t use that chain) after the major bump of sys-apps/shadow when it was picked up by Debian. Dated 24 Feb 2008. Over two and a half years ago.

While I cannot get rid of the fault of missing the revert; why did I miss it? Simple enough: Portage’s confmem feature never told me that /etc/pam.d/login was changed from the one I had before. It assumed that my local version was a modified one and thus accepted that one as the good one.

Now this makes the second revision bump and second stable request that I have to take care of to fix PAM-connected trouble; the previous one, back in July (for the bump) and last month (for stable) related to the chpasswd chain that had been broken for, well, almost the same time as this one.

In fixing another ConsoleKit problem, bug #342345 I found that the GDM and KDM chains are not compatible with pambase, and they both need more fine-grained control over the sessions (console and graphical sessions have different needs, in the latter case we have to skip motd/mail/lastlog modules).

A quick check around on the tinderbox told me that there are a number of PAM chain files that should be cleaned up, reduced, optimised and so on. And that the number of files there does not correspond with the number of files installed.

Basically, what we need now is an audit of all the PAM-using packages in the tree, beside the improvement of pambase as stated above. We’re talking of a month or two worth of work. Not something I’d do myself in spare time, not something I can do as it is during work time. It’s not simply a matter of writing what I did for the original pambase; it’s a work more in line with the Ruby NG situation, and that one we haven’t completed just yet with three people working on it, including a bunch of work time thrown in by me for a few jobs I took during the year.

So here’s the catch: nobody has helped me with PAM in years, and while Constanze is being ascended to developer status, I know she’s also pretty busy with her thesis so I cannot easily ask her to commit enough time to lift me from enough work. This means that we can either keep the current status-quo of just band-aiding through enough troubles so that we can keep it running, or somebody got to help me either with work or with funding. As I said, I’m already losing money with the tinderbox and I don’t want to lose time, sleep and (possible) money on working on something as ungrateful as PAM.

Don’t get me wrong, I’m not asking for donations here; I’m asking to be paid to do a job, and that job is the auditing and review of (a part of) the PAM-using ebuilds. If you’re using Gentoo (and PAM) in production, you might be interested in hiring me to get this out of the way. I don’t even have much to pretend: €1500/month, one to three months time (depending on the deepness of the work you’d want to fund), you can provide the agreement details and give me a list of priority programs to work on (those that you use in your organisation). On the same terms, I’m willing to help you package new software that is not currently in portage in the spare time.

Let me know by mail if you’re interested. Extra points if you use GPG-encrypted email because that stuff doesn’t get sent to spam.

Pambase is not that free

You probably know that I’m the PAM maintainer of Gentoo Linux, for good or bad (mostly bad, given that I don’t use most of its features, which I have to maintain nonetheless,). To ease my own work when trying to track down what users have been up to during bug triage, I created a package called pambase providing USE flags to enable standard configurations for particular, commonly used, modules.

This package got even more useful when we started having the need for particular features to integrate with our default stacks, for the users to be able to properly use them, like ConsoleKit and Gnome-Keyring, and to upgrade the hashing function to something less broken than MD5.

Now, all in all, I’m pretty happy to how pambase shaped up, it’s quite usable and I can easily make use of it to handle things like blowfish via xcrypt if wanted. Today I, indeed, received a request for pam_abl integration — well, the request was misdirected toward OpenSSH and the provided patch was totally bogus as it only added a nasty dependency, but the idea behind it is quite reasonable.

Now, we get back to the title: “pambase is not that free” does not have to do with the licenses related to pambase (which as far as I know are all well compatible) but rather with the work that goes behind it, for me and – much more – for the arch teams.

Adding support for a new (optional) module into the pambase package makes that module enter the system set; this is why, for instance, a good part of GNOME can now be considered part of the system set. You have to understand that even if it might not be in your system set, or in the default system set for what matters, the packages have to be carefully considered to not break if they are part of the possible system set, via optional USE flags as well. Adding gnome-keyring to that possible system set added a whole lot of branches in there.

Packages in the possible system set tree have to be paid special attention to: you cannot assume the presence of the entire system set for them, so things like zlib and bison have to be added to the dependencies of the ebuild (this is needed for the depgraph to be drawn correctly). Also, packages that are added to pambase need to be ready to go stable: if I were to add xcrypt or pam_abl to the possible dependencies of pambase, we got to be able to mark those two stable at some point in time.

This also adds quite a bit of burden to the maintainers of those packages, as the package will now be scrutinized much more deeply, and used by many more users (since they won’t need to know how to configure PAM to enable them).

Am I just ranting here? No I don’t think so; I just think I might have taken the wrong approach with pambase, and I’d like to see if other users have suggestion on which alternatives we could have. I guess something similar to what is done to fontconfig could be useful: get each module to provide some configuration files in, say, /usr/share/pambase/ and then have an eselect module to turn on and off the configurations.

The problem with this approach is that you have to cope with quite a few situations, which should probably be identified, modeled, considered and designed before implementation:

should the generated files in /etc/pam.d/ considered to be user-editable? or should they just be generated and the user is responsible for using the application to deal with them?
should the module packages enable themselves by default? or should they leave to the user to enable them? and at unmerge time, should they disable themselves? (I guess so, otherwise the system would be left in an unusable state);
if they get enabled at first merge, should something record that the user explicitly disabled them, so that they won’t re-enable themselves automatically the next time?
should other services be set in such a way that they can be edited, so that you can configure e.g. the mail servers to look into a particular file, while the FTP servers in another?

Given there is so much stuff to be considered, I ask everybody who has a non-default PAM setup to please let me know about it, explain me how you use PAM in Gentoo so I can judge how to proceed in the future! Either comment here or, if you have privacy concern regarding your setup, send me an email: CC pam-bugs@g.o (g.o being our distribution’s domain, obviously!) if you care or, if you really don’t want details about your setup to be read by anyone else, send it directly to me and encode it so only I can read it.

Again, thanks, and please try to get this post around so I can gather as much details as possible on what we need.

New Linux-PAM and pambase

So I noticed tonight that yesterday a new Linux-PAM (in portage as a generic sys-libs/pam, even though I want to change it one day) was released: 1.1.0. I actually was scared that it was a big overhaul, it seems instead to be little more than a feature release of the previous release, so it’s fine.

All my patches from pre-1.0 (as well as the one to disable NIS support when not found) are still outstanding and they still apply cleanly. I guess I’ll have to harass upstream more about them and see that they are applied, maybe for 1.1.1 or something.

At any rate, the new release does have a few interesting changes, like a new pam_tally module that is now wordsize-independent (that is, it works the same way both in 32- and 64- bit configurations), for this reason I’m now preparing a new pambase to make use of it instead of the old one by default if present. Unfortunately I’m finding a couple of issues that make it not easy to solve.

There is another change that might be worth nothing: I have already blogged about the sha512 support that Linux-PAM 1.0.1 has provided us with. Well, with this new release, together with sha512, sha256 and md5 hashing… there’s blowfish!

But pambase is not going to provide a way to enable it. It’s not that I don’t want people to use blowfish, but rather that upstream relies on the crypt() function provided by the C library: when it supports the above algorithms, then pam_unix will support them as well, otherwise, you’re out of luck. Since Gentoo does not provide a blowfish-patched glibc, then it won’t support the blowfish method. Until that time, this post will serve as an answer for those interested in the matter, who think that by just using “blowfish” you can gain stronger hashing.

Since this is a minor version bump (compared to the previous 1.0), I’ve also decided to change a bit the ebuild too; I’ve removed the warnings for pam_userdb and other modules that have been moved in separate packages, since they were only checked for when updating from pre-1.0 versions. I’m almost tempted to remove the safechecks for pam_stack, pam_pwdb, and pam_console; the pam_timestamp checks have been dropped because that particular module, initially present in our older versions of PAM which applied RedHat-supplied patches, is now present upstream.

I’m going to try mediating with Kukuk about the patches we apply, dropping a few, merging a few more. It’s more time spent on stuff I don’t care much about (PAM is something people detest and I don’t really have a good use for it myself), but I guess it’s something that Gentoo needs. As usual, kudos and gifts are very welcome (the latter in particular because with the recent expenses I’ve had to take care of my leisure budget reduced considerably).

Time to get going to work then, I’m afraid I’ll have to bump the pambase version to 20090621, I don’t think I can fix it before night!

PAM configuration files

Following yesterday’s post on PAM I decided to get on with the work on PAM, fixed a bug, duped another and then started looking, via the tinderbox, for the configuration files installed by many applications.

It turns out that there is a huge mess in there; some applications use the pamd_mimic function from pam.eclass (which I wrote myself) to just request the same authentication as the rest of the system. Others install similar pam.d files coming out of upstream distributions; other install the upstream-provided pam.d file that doesn’t suit the Gentoo setup at all.

This actually gave me a nasty headache: I had to open a few bugs for the most obvious bad files, but it also has shown me that I need a better system to review the actual validity of the configuration files. For instance, I see lots of password chain entries in the configuration files, but I guess that not all services would have a way to change the system’s password (anything that runs user sessions without root privileges would be unable to change the shadow passwords file).

Now, there is a negligible security concern with not outright deny password changing to those applications; if we were to tighten up security in the PAM area we should probably just add pam_deny entries for the password chain. What actually worries me is that most of the people maintaining packages using PAM don’t really know enough about it to properly write the PAM configuration files like it was supposed to. Not that I can blame them, I also would have preferred not to know, but it means that I really really really have to find time to work on the PAM documentation, so I can help developers to write the proper configuration files, knowing their software.

This review also has shown me that a lot of packages actually install the same stack: system auth with an additional precondition in the pam_nologin module. I wonder if I should add a system-service-login stack that contains that, and use that instead, to merge all these details inside the single pambase package. On a similar note, I also started wondering if it would make sense to have the mailbase and ftpbase package drop the PAM configuration files and also move those into pambase; that way it would be possible to provide fine-tuned configuration files, with the proper module used on FreeBSD to find ftpusers, and similar.

Sincerely, I don’t like having to maintain PAM, I do just because it seems nobody else cares; each time I start looking into it, I do find some things that needs to get addressed but I soon lose the motivation in it. So if you’re interested in these things being cleaned up, please speak up, at least I’ll have some reason to continue working on them.