[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

unsubscribe



Nicolas Williams wrote:

> On Sun, 20 Aug 2000, Jeffrey Altman <jaltman@columbia.edu> wrote:
> > > Ok: I requested to login as scott, but lately entered "fred"
> > > as username and fred's password.
> > >
> > > I think that this situation is also possible with kerberized
> > > telnet, _especially_ when PAM concerned: if administrator rejects
> > > someone's access to the system (using pam_listfile etc etc),
> > > 1st login attempt will fail, and after this login will prompt
> > > for a username.  But note that if that second username will be
> > > not the same as first one, we can have at least strange things
> > > with kerberos tickets (yes, if second time login will "fallback"
> > > to plain password auth): Fred on remote machine will have access
> > > to scott's tickets etc.
> >
> > This behavior is by design.  It allows the user to authenticate to the
> > system with their credentials (scott) but login to the account of
> > another user after proving knowledge of the user's password.
> >
> > There is nothing wrong with this.  A properly installed telnetd
> > supporting the telnet AUTH option will be configured to either allow
> > this behavior or not depending on the administrator's preferences.
> > There are four levels of acceptable login:
>
> Yes, but, I think Michael was writing in the context of /bin/login,
> PAMified, instead of login.krb5.
>
> I think we need to have a liblogin and a /bin/login based on that, that
> liblogin needs to be PAMified, that telnetd should use liblogin and so
> on. The crucial issues include: how to communicate to login, and thence
> PAM, just how the user was authenticated, if at all, with what system
> and to which principal; we also need to be able to inform login, and
> PAM, about the security of the TTY.
>
> Then we could push handling of valid/user/other/unknown to PAM, where it
> belongs.
>
> [...]
>
> > > And the only reliable solution to this is to have login's
> > > functionality built-in to telnetd, so that it will have full
> > > control for tickets _and_ usernames.
> >
> > I am leaning in this direction for other reasons.
>
> I think that is a good thing to do, and if there's a liblogin, then base
> /bin/login on liblogin.
>
> [...]
>
> > Until we have a memory based cache for Unix /tmp will have to do.
>
> Or a message-based LSA.
>
> > > Kerberos tickets are short-lived things (as I know of), so the best
> > > place for them is a shared memory.  And I think that portablilty is
> > > _not_ a problem here.  Most systems have shared memory concept today;
> > > them are _very_ different from each other -- yes, this _is_ a problem,
> > > that requires a lot of careful coding.  But this problem was already
> > > solved many times in many packages.
> > > BTW, storing tickets in shared memory is good for many other places,
> > > and when only one machine involved (without telnet/etc), isn't it?
> >
> > I don't think anyone disagrees with you.  It just a question of
> > finding time to do the work.  And right now there is ample evidence
> > that before significant new code is written the current code base must
> > be audited with a fine toothed comb.
>
> Yes, but, plenty of code exists that could be fashioned into what we've
> been talking about. We can specify liblogin and its interaction with
> PAM, we can turn a PAMified login into liblogin, and we can take one of
> the various PAM_KRB5 modules, touch it up and fit it in.
>
> I don't disagree with your audit suggestion.
>
> >                   Jeffrey Altman * Sr.Software Designer
> >                  The Kermit Project * Columbia University
> >                612 West 115th St * New York, NY * 10025 * USA
> >      http://www.kermit-project.org/ * kermit-support@kermit-project.org
>
> Nico
> --
>
> _______________________________________________
> Pam-list mailing list
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []