Hello all, The long-mooted PAM merge from FreeBSD is starting _now_. This replaces the PAM password auth kludge that we have used until now with a discrete challenge-response module. This module is invoked via keyboard-interactive for protocol 2 or TIS auth for protocol 1. Warning: this is a large change and will probably break things. It has only been tested with basic password auth modules and not at all (by me) on non-Linux systems (I put out test requests on snapshots of this, but nobody responded...) On the other hand, this code has been shipping and working in FreeBSD for a while. For those interested, this is pretty much exactly what is in FreeBSD's tree, with a few s/pam_xxx/sshpam_xxx/ substitutions. These are to avoid potential namespace clashes against the PAM library itself. I have no idea whether there are any such conflicts in the symbols in auth-pam.c, but we made a similar change in the old auth-pam.c quite a while ago at the request of someone at Sun. Also note that we do not enable and have no intention of enabling the thread support - we don't want the complexity of theads in the monitor. The code is still there at the moment (#ifdef'd out), but will likely disappear from our tree in the future. I'll try to remove it in such a way that the FreeBSD developers don't end up in #ifdef hell putting it back in their tree. The repository will be tagged with BEFORE_FREEBSD_PAM_MERGE and AFTER_FREEBSD_PAM_MERGE tags to make diffing / reverting easier. We are a long way from the next release, so we have plenty of time to make this work properly. Doing this will require a lot of testing, so I encourage everyone on a PAM system to try out the new code and report back ASAP. -d
----- Original Message ----- From: "Damien Miller" <djm at mindrot.org>> Hello all, > > The long-mooted PAM merge from FreeBSD is starting _now_. This replaces > the PAM password auth kludge that we have used until now with a discrete > challenge-response module. This module is invoked via > keyboard-interactive for protocol 2 or TIS auth for protocol 1. > > Warning: this is a large change and will probably break things. It has > only been tested with basic password auth modules and not at all (by me) > on non-Linux systems (I put out test requests on snapshots of this, but > nobody responded...) On the other hand, this code has been shipping and > working in FreeBSD for a while. > > For those interested, this is pretty much exactly what is in FreeBSD's > tree, with a few s/pam_xxx/sshpam_xxx/ substitutions. These are to avoid > potential namespace clashes against the PAM library itself. I have no > idea whether there are any such conflicts in the symbols in auth-pam.c, > but we made a similar change in the old auth-pam.c quite a while ago at > the request of someone at Sun. > > Also note that we do not enable and have no intention of enabling the > thread support - we don't want the complexity of theads in the monitor. > The code is still there at the moment (#ifdef'd out), but will likely > disappear from our tree in the future. I'll try to remove it in such a > way that the FreeBSD developers don't end up in #ifdef hell putting it > back in their tree. > > The repository will be tagged with BEFORE_FREEBSD_PAM_MERGE and > AFTER_FREEBSD_PAM_MERGE tags to make diffing / reverting easier. > > We are a long way from the next release, so we have plenty of time to > make this work properly. Doing this will require a lot of testing, so I > encourage everyone on a PAM system to try out the new code and report > back ASAP. >Are there any plans to fix the "PAM needs to run as root in the session stage" as raised by me a few weeks ago. I know this is incredibly useful for ISPs who want to chroot people who login (as we do). I'm no expert on PAM and I understand the security implications but surely as someone mentioned earlier support for PAM is effectively broken without this. Regards, James Williamson www.nameonthe.net Tel: +44 208 7415453 Fax: + 44 208 7411615
On Sun, May 11, 2003 at 09:54:09AM +1000, Damien Miller wrote:> Frank Cusack wrote: > > On Sat, May 10, 2003 at 09:51:57PM +1000, Damien Miller wrote: > > > >>I think that this may be very difficult to do with privsep, as we have > >>long since given up root privs by the time we start the session. Of > >>course, I'd like to be proved wrong... > > > > The FreeBSD diff, as posted a few months ago, did exactly this. What > > has changed since then? > > The FreeBSD PAM code doesn't touch the session setup. Never did IIRC.Yup, sorry 'bout that. /fc
On Sat, May 10, 2003 at 07:20:58PM +1000, Damien Miller wrote:> The long-mooted PAM merge from FreeBSD is starting _now_. This replaces > the PAM password auth kludge that we have used until now with a discrete > challenge-response module. This module is invoked via > keyboard-interactive for protocol 2 or TIS auth for protocol 1. > > Warning: this is a large change and will probably break things. It has > only been tested with basic password auth modules and not at all (by me) > on non-Linux systems (I put out test requests on snapshots of this, but > nobody responded...)Actually, I did respond, and we got into an argument about it. Although, I didn't have an opportunity to actually test it, and I guess no one else did either. I don't see what's wrong with the existing code. Especially when you say the new code "will probably break things". Now I have to study this new code and port my bugfixes all over again. :-) I tried to download, but the latest snapshot (20030409) doesn't contain the PAM bits, and anoncvs.be.openbsd.org appears to be down. I took some time to look at the snapshot you offered previously (20030123) and found three problems: - kbdint authentication cannot be abandoned - print_pam_messages() doesn't do anything! - sshpam_query() sends the client only one pam prompt at a time; this is explicitly mentioned as wrong in the kbdint draft. As to pam_*_session(), in this new code, the auth bits run in the monitor and communicate with the unpriv child via a socket. Seeing that, I assumed pam_*_session() would have been setup to do the same. The problem seems pretty easy now that the plumbing is in place. /fc
Damien Miller <djm at mindrot.org> writes:> Also note that we do not enable and have no intention of enabling the > thread support - we don't want the complexity of theads in the monitor. > The code is still there at the moment (#ifdef'd out), but will likely > disappear from our tree in the future. I'll try to remove it in such a > way that the FreeBSD developers don't end up in #ifdef hell putting it > back in their tree.There's nothing to remove. Unless you define USE_POSIX_THREADS, the PAM code will use a child process instead of threads. At most, you may want to remove the following lines: #ifdef USE_POSIX_THREADS #include <pthread.h> #else and, further down: #endif as well as one instance of #ifndef USE_POSIX_THREADS. Also, please make sure that - - you are using the latest PAM code from FreeBSD-CURRENT - you also have my auth-chall.c patches - you also have the abandon_challenge_response() patch for auth1.c - you remove the PAMAuthenticationViaKbdInt option from servconf.c - you run #unifdef -UUSE_PAM on auth-passwd.c DES -- Dag-Erling Smorgrav - des at ofug.org