Regarding PAM_TTY_KLUDGE and Solaris 8...

[Ed Phillips]

On Thu, 25 Oct 2001 mouring at etoh.eviladmin.org wrote:

> Date: Thu, 25 Oct 2001 09:04:47 -0500 (CDT)
> From: mouring at etoh.eviladmin.org
> To: Ed Phillips <ed at UDel.Edu>
> Cc: Damien Miller <djm at mindrot.org>,
>      Darren Moffat <Darren.Moffat at eng.sun.com>, openssh-unix-dev at mindrot.org
> Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
>
>
> If the patch below gives us a reasonable solution.  Then I guess that is
> as much as we can hope for in 3.0p1.
>
> Question still has to be asked is how does this patch handle password
> changes on non-interactive.  Does PAM outright fail causing the ssh
> connection to quietly fail?  Does PAM whine loud enough to echo through
> the failing ssh connection?  Or does it blow off the required password
> change and execute the command?
>
> Options #1 and #2 may be acceptable for 3.0p1 release.  Option #3 would be
> bad news since some may consider it a security flaw (mainly if you do
> passwd -f account  under solaris).
>
> In the end Option #2 would be best.

Unfortunately, it looks like it's worse that all 3.  It appears that the
crash on Sol8 is not actually due to the PAM_TTY_KLUDGE being set
improperly, but due to a bug where pam_unix.so fetches PAM_TTY and
neglects to check if it's NULL or not.  So, if we set PAM_TTY and call
pam_open_session(), then we have to put in some dummy tty name that is
meaningless and gets logged in the lastlog, but if we don't set PAM_TTY,
we get a core dump on Sol8.

This brings us right back to the question at hand - should we call
pam_open_session() for non-interactive mode?  I've previously said, "Yeah,
go ahead, someone might want to do something useful with
pam_sm_open_session later."  The problem with this is that as long as
Sun's pam_sm_open_session() returns an error if PAM_TTY is not set, then
how can we tell if the error returned by pam_open_session() is just
because we're in non-interactive mode and pam_unix.so on Sol8 returns an
error due to PAM_TTY not being set, or because something failed in another
module besides pam_unix.so that we actually care about and may not want
the user to login as a result.  My gut feeling about this is that errors
from PAM "session" modules should be treated as informational - if a user
can't login, then the "auth" or "account" modules should report the error
back to the caller and the caller should pass it on to the user and close
the connection.  PAM "session" errors should probably be ignored.
Remember, the current Sol8 "pam_unix.so" session module only makes lastlog
entries.  So we don't have a very good example to infer "intentions" from
regarding the session modules.

So, one solution, just so we can get past this and make things "work", is
to include and encourage PAM_TTY_KLUDGE fix (with "NODEVssh"), but also,
ignore any error messages returned by pam_open_session().  Later, when the
fix is available for the pam_unix.so bug in Sol8 (and I'd guess that this
is also a problem in earlier versions and probably even in Sol9), a user
could compile OpenSSH without PAM_TTY_KLUDGE on Solaris, and since we're
ignoring the errors returned by pam_sm_open_session(), it doesn't matter
that pam_unix.so can't create the lastlog entry for the non-existent
PAM_TTY.

Does this make sense?

To proceed and fix the problem where the pam_unix.so code starts prompting
the user for a password in a non-interactive session, I don't know how we
can fix that given the above strategy.  In order to make pam_unix.so "do
the right thing", I'd guess we need to avoid passing PAM_TTY - then it
should figure out there's no tty and return an error at some point.
Darren... is this true - if PAM_TTY is not set and the user needs to
change his password, will pam_sm_acct_mgmt() in pam_unix.so return an
error that sshd can detect and process?

So, a second (and probably better at this point) solution would be to NOT
call pam_open_session() for non-interactive mode (have I sufficiently went
back and forth enough to confuse everybody?).  Maybe there could be a
PAM_OPEN_SESSION_BROKEN flag in config.h, which is defined by default, and
we could document which patch needs to be applied on Solaris in order to
avoid the problem and allow pam_open_session() to be called (with NO
PAM_TTY set).

How does that sound?

Thanks for your patience while I cycle closer to the target... ;-)

	Ed

>
> - Ben
>
> On Thu, 25 Oct 2001, Ed Phillips wrote:
>
> > What is the reasoning behind this?  Do we want to see a lastlog entry for
> > "ssh" whenever a user runs remote command?  Do other OSes have
> > pam_open_session that does more meaningful things than Solaris 8?
> > Well...  I guess the more I think about it, it's probably better to go
> > ahead an call pam_open_session even for the non-interactive case since
> > someone might want to implement a PAM module at their site that logs every
> > ssh connection... and if we don't call pam_open_session, then they don't
> > even have that capability if they wanted it.
> >
> > I agree.  Your patch below will avoid the SEGV on Sol8 regardless of
> > whether or not the user has installed the patch to fix pam_unix.so.
> >
> > Also, I'll check with our platinum-beta contact at Sun to see if it's okay
> > to test openssh on Sol9 Beta and report problems to this list, etc.
> >
> > 	Ed
> >
> > On Thu, 25 Oct 2001, Damien Miller wrote:
> >
> > > Date: Thu, 25 Oct 2001 10:45:34 +1000 (EST)
> > > From: Damien Miller <djm at mindrot.org>
> > > To: Darren Moffat <Darren.Moffat at eng.sun.com>
> > > Cc: openssh-unix-dev at mindrot.org
> > > Subject: Re: Regarding PAM_TTY_KLUDGE and Solaris 8...
> > >
> > > On Wed, 24 Oct 2001, Darren Moffat wrote:
> > >
> > > >
> > > > >Okay, this appears to be a problem with pam_unix.so - the code in
> > > > >pam_sm_open_session is written with the assumption that the tty name is of
> > > > >the form "/dev/" + something else on the end.  I'm not sure why the
> > > >
> > > > pam_sm_open_session in pam_unix on Solaris now does this:
> > > >
> > > >         /* report error if ttyn or rhost are not set */
> > > >         if ((ttyn == NULL) || (rhost == NULL))
> > > >                 return (PAM_SESSION_ERR);
> > > >
> > > >         /* sanity check on size of tty line */
> > > >         if (strlen(ttyn) < sizeof("/dev/"))
> > > >                 return (PAM_SESSION_ERR);
> > > >
> > > > later on it uses everything after the /dev/ as the short name tty to
> > > > write to lastlog.
> > > >
> > > > This was part of the fix for 4250887. The fix will appear in patch
> > > > 111659-03 (sparc) and 111660-03 (intel) when that patch is released.
> > >
> > > IMO until then we should enable the kludge, but change it as follows.
> > > Kevin, can you check whether the kludge works with this patch on HP/UX?
> > > (is the kludge even needed there?)
> > >
> > > Index: auth-pam.c
> > > ===================================================================
> > > RCS file: /var/cvs/openssh/auth-pam.c,v
> > > retrieving revision 1.37
> > > diff -u -r1.37 auth-pam.c
> > > --- auth-pam.c	2001/04/23 18:38:37	1.37
> > > +++ auth-pam.c	2001/10/25 00:43:55
> > > @@ -374,7 +374,7 @@
> > >  	 * not even need one (for tty-less connections)
> > >  	 * Kludge: Set a fake PAM_TTY
> > >  	 */
> > > -	pam_retval = pam_set_item(__pamh, PAM_TTY, "ssh");
> > > +	pam_retval = pam_set_item(__pamh, PAM_TTY, "NODEVssh");
> > >  	if (pam_retval != PAM_SUCCESS)
> > >  		fatal("PAM set tty failed[%d]: %.200s",
> > >  		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
> > >
> > > -d
> > >
> > > --
> > > | By convention there is color,       \\ Damien Miller <djm at mindrot.org>
> > > | By convention sweetness, By convention bitterness, \\ www.mindrot.org
> > > | But in reality there are atoms and space - Democritus (c. 400 BCE)
> > >
> >
> > Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
> > Systems Programmer III, Network and Systems Services
> > finger -l ed at polycut.nss.udel.edu for PGP public key
> >
> >
>
>

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key