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

Re: non-interactive authentications...

On Wed, Aug 19, 1998 at 09:36:01AM -0700, Andrew Morgan wrote:
> Savochkin Andrey Vladimirovich writes:
> > Conversation function is introduced to display the prompt and read
> > the answer in the current environment: via a box in GUI or just
> > printing the prompt or making an appropriate request to the peer in
> > the case of a remote session.
> > The fact that a plenty of applications using PAM are broken by
> > design only shows that PAM as it is doesn't satisfy developer's
> > needs.
> Is this because PAM does not satisfy developer's needs or because
> someone with a knowledge of PAM has not taken the time to better
> integrate PAM into an application?


Well, I'm one of the persons.

I started the PAM intergation into different applications.
I dealt with sshd, rlogind, radius server and others.
I wasn't satisfied by the results at all.

Andrew, we spent some nice days patching sshd.
But can you say that our changes greatly simplify the sshd code?

I still consider all existing hacks to implement authentication
via PAM including written by me as kludges.

I consider them as kludges because all of them reduce the clearness
and robustness of the code. It's two things which I appreciate very much
for any kind of code and especially for security related.

I'm bothered very much by the fact that for current PAMification schemes
only a good specialist after deep code investigations can say
if the given application with given PAM configuration and built
with given set of external libraries (glibc vs pwdb vs libc5) with
given configuration files for the libraries will work.
Without deep investigations I can't be sure that access will be granted
when it should be and that access will be denied when it should be.

I don't flee from PAM development and the idea of pluggable authentication
is deep in my mind.
However the rate of PAM workarounds to clear solutions pushes me to
some experiments with the API itself. Even if my experiments fail
I hope some investigations in this field will help the implementation
of the existing API.

> My observation is that PAM, because it allows for quite general text
> prompts (ignore binary prompts for now), should be able to mimic the
> current authenticating behavior of any and all text based
> applications.  This may require that someone extract the
> authenticating code from the pre-PAM authenticating server application
> and turn it into a module.
> Let's take ftp (probably the archetypal offender in the "quick" PAM
> support hack):
> bash$ ftp alfred
> Connected to alfred.nowhere.org.
> 220 alfred.nowhere.org FTP server (Version wu-2.4.2-academ[BETA-11](1) Mon Dec 16 17:10:41 EST 1996) ready.
> Name (alfred:morgan):
> 331 Password required for morgan.
> Password:


> For other applications like POP, perhaps we need to beef up the
> protocol to support more elaborate authentication exchanges, but it
> should always be possible to do this in a way that we can
> transparently support the old/default authentication scheme... If it
> comes right down to it, we can write a module that will thus do
> "normal" POP authentication.

Your suggestion for ftp PAMification is nice.
But there are protocols where PAMification is much more hard thing without
changing the client side software and there are some cases where it's
impossible at all.

But this points are not so important for me as the loss of clearness
and reliability mentioned above.

> I guess I've spent too long believing that PAM can be made to work.  I
> used to have the time to just do this sort of coding... I'm still able
> to offer advice, so if anyone wants to give it a try, I'd be happy to
> look over their shoulder...

I want to continue the development of pluggable authentication techniques.
Now I want to make an experiment.
I would appreciate very much your help and suggestions.

If I'm convinced that API where possible prompts and answers are defined by
the application rather than by module isn't better I'll finish sshd
PAMification and will work under proposed ftpd PAMification.

Best wishes
					Andrey V.

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