GDM

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.

2010-11-18 by English Technical 2

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?

2010-11-11 by English Technical 3

Tightening security

I’m not sure why is it that I started being so paranoid about security; quite a few things I’ve been changing in my workflow lately, and even though I kept a decent security of my systems and network, now I’m going one step further.

Beside working on getting Kerberos-strengthened NFS working (and trying to get libvirt if it wasn’t for gtk-vnc and the other mess), I’m now considering something to strengthen the security of this laptop. Given what I’ve seen with pam_mount, it would also make sense to get that improved, fixed, maybe even integrated with the pambase, as usual for me.

But beside not actually having an idea of how to configure that up yet, it also made me think of the use case for it. Let’s say I actually encrypt the whole partition (I know there are a few options for not using an entirely encrypted partition, but since last I checked they all require patched kernels, I’d like to stay quite away from those); it gets mounted when I login (on GDM), and up to that it’s okay, but what happens when I close the laptop in suspend? It wouldn’t get unmounted because all the process are still there. And if somebody can get a new login with that, well, you’re screwed because the other sessions can see the mounted partition as well.

One option I can think of is one old friend of mine: pam_namespace. This module allows to “split” the mount namespace of user login sessions at PAM login; placed before pam_mount, it would let the partition to appear mounted for all the processes starting from the process calling the module. What this can actually achieve is that even if you have root password, and create a new session with its credentials.. the partition will not appear to be mounted at all. Cool, but pam_namespace breaks a bunch of things such as HAL. It was almost exactly one year ago that I wrote about that.

Another option is to simply logout before suspending the laptop; this should also fix the graphic card reset problems: shut down X before suspending, reopen it with a new login afterwards. It take a bit more to reopen everything of course, but that’s not the main problem — it wouldn’t be a problem at all if software actually restarted as intended, like if Gnome actually restored the session and included Chromium tabs.

Unfortunately, I actually got one good reason to think that there is some trouble for what concerns this idea. One of the first incarnations of the tinderbox I found out that it actually let some stray processes; and this was by just executing a console-only chroot, as root, and without any desktop system software running. I’m quite sure that at least the GnuPG and SSH agent software is kept running at the end of the session. Such stray processes would still make it impossible to unmount the partition.

Finally the last remaining solution is to turn off the whole system, but as you probably already know that it takes time for a cold start to work out properly.

What options are there for these situations? Anybody have suggestions? I wouldn’t mind even just using an encrypted directory tree, mounted via FUSE, and encrypting with GnuPG (and thus, with my FSFe Fellowship Smartcard).

A similar, lower-priority but maybe even of more long-term importance is encrypting my backup data; in this case, I cannot be there to input the password over and over again, so I have to find a different solution. One thing I actually thought of is to make a (sane) use of the “software protection hardware keys” that I remember from computer magazines of the final ‘90s. There is actually a manufacturer of those not far from where I live, in the same city as my sister; I wouldn’t mind buying a sample USB key from them, and if they give out the details for communicating with it, implement an open source library to talk with that and see if I can make use it as encryption key for a whole partition.

At any rate, any suggestion so that I don’t have to reinvent, or at least redocument, the wheel, is as usual very welcome.

2010-08-08 by English Technical 20

Dualhead, 16:10 and XRandR

With my move to Gnome I decided to try out again the graphical login. I used to use standard console login before because KDM lacked too many features, and while for some time I kept using GDM, it just didn’t feel right. Unless I was going to just do some system administration, or testing PAM, the only command I was going to type was startx, followed by sudo shutdown -h once I was done.

To do so, I had to give up keychain, at least for inserting the private key’s passphrase. Instead of using that, I decided to change my PAM setup to use pam_ssh (and this is also what brought me to plan removal of pam_ssh_agent .. I just remembered I forgot to add that to the Gentoo Calendar! — done!), so that instead of typing my password and my SSH key passphrase, I just have to type in my passphrase at login and I’m done. The nice thing is that the standard Unix password is also accepted, so I can use that to take me out of the lock screen that Gnome applies when I walk away from the system, which is much shorter.

Again, I will probably put up a request for an electronic ID card next september and consider using a smartcard reader (I I wonder if I can use old, invalid, credit cards as smartcards too, once they are formatted).

So okay, I’ll write at another time about pam_ssh, it’s not what I’d like to write about right now.

With GDM I’m having one problem: my current setup is a dualhead, with a 16:10 monitor (and a 4:3) and using XRandR 1.2 (radeon driver). I have the screen disposition set up in my xorg.conf, but I’m not able to set the proper mode for the 16:10 monitor in the configuration file. If I set PreferredMode in xorg.conf, X11 refuses to start, without any apparent error either.

So for now I’m running at the session manager level two xrandr commands to set up properly the screens, but there is one problem: synergys does not seem to be expecting the geometry of the screens to change, so it still wraps my pointer out on the coordinates where it should have wrapped before the xrandr fixes.

I should probably see to try the latest masked version of xorg, and check if it works there. Although I think Synergy should have considered the case of changing screen layout. Maybe one day it will be rewritten using XCB and it will consider that problem too 😉

Oh yeah I should be writing about XCB too…

2008-07-21 by English Technical 2

All your pambase are belong to us

And with this I finally given up on this omnipresent meme. But I couldn’t find a better title to present to the world my new PAM infrastructure package: sys-auth/pambase.

As I suggested yesterday I wanted to improve the way that the basic PAM configuration is handled in Gentoo to make it simpler to add caps support. Last night I decided to start working on it, and it was a quite easy target actually.

The new sys-auth/pambase package installs the basic PAM configuration files for all implementations. This means that the same basic file configuration used by Gentoo Linux is shared with Gentoo FreeBSD, and changing one will also change the other. No more duplication of the files in sys-freebsd/freebsd-pam-modules and sys-libs/pam.

Of course different implementations (Linux-PAM and OpenPAM, FreeBSD modules and NetBSD modules) implement different modules and different parameters. So instead of having the final file in the pambase package, it contains some pre-parsing files, that cpp (yes, the C Pre Processor proper) expands to the final file. Through a few directives, I can then enable or disable feature on a per-implementation basis.

In addition to the system-auth PAM configuration file (that is referred to by almost all other services to provide system-integrated configuration), pambase installs a system-login PAM configuration file. What is the difference? This configuration file should be used for services like login (from shadow), xdm, gdm, kdm, entrance, … I suppose that any of you who ever tried to get stuff like ConsoleKit working would be able to grasp what is so interesting in this.

A single consolekit USE flag on pambase could allow to switch on and off ConsoleKit authentication on all major console logins without user intervention (beside enabling the USE flag and running etc-update).

For now this is a testing framework, as I’m considering if I should have system-login plus system-console-login, so that sshd for instance can use system-login (to enable stuff like motd, userfiles and similar), but still not use ConsoleKit and similar, and it still has to be tested on Gentoo FreeBSD.

I hope to coordinate with GNOME and KDE teams later today to have gdm and kdm to use the new capability, still without any keyword, and be able to put this in production in a few months, also replacing virtual/pam step by step (as it does take care of properly depending on the right PAM implementation with its eventual modules).

One nice thing is that it will probably have a huge lot of USE flags, as it would then allow to just specify a flag (say, caps) to enable the correspondent PAM module into the main system configuration, depending on the right ebuild. While most complex configurations wouldn’t work well that way, basic stuff is likely going to make it easier to manage system login for users.

Anyway, as you’ll guess this will be my project in the next few weeks (I’ll also return on linking problems, but it’s better for my sanity if I change topic from time to time for a while).

2008-02-19 by English 0

Some more PAM plans

So, I’m still working on the PAM documentation; in particular, I’m working on splitting up what initially was a single guide, because I found it was coming too complex and too long, and it was deemed to scare the devs away. Plus, there are still some concepts that are good for users as well as developers, so it would make more sense to move it in their own “shared” guides.

I’ll probably commit some of the documentation later today, and then continue working on the rest, leaving Josh to clean the grammar up 🙂

But, while trying to reorganise documentation and packages, I also started wondering about a few other things, for instance I’m certainly going, in the next weeks, to work on a proof of concept of a pambase package, carrying system-auth, login, and xdm configuration files. The idea of this is that if PAM changes syntax, I can just change one package to handle it.

At the same time, this would allow to provide simpler management of common optional PAM modules; for instance adding consolekit support for login, GDM, XDM and KDM would just need an USE flag to pambase, and then the default installed configuration would be updated.

Of course this transition won’t happen anytime soon, considering that PAM 0.99 is scheduled to be marked stable for September, I doubt this could go in use before next year, but it’s something that might for the future.

Comments, as usual, welcome, as well as bribes and sponsors 🙂

2007-07-14 by English 2