PAM/Kerberos `integration'? (was Re: Step5, pam_opie OPIE auth fix for review)
On Mon, Jan 21, 2002 at 01:55:53PM -0800, Terry Lambert wrote: > "Jacques A. Vidrine" wrote: > > > In the way that the author of the PAM architecture from Sun > > > spoke at the Silicon Valley BSD User's Group meeting, > > > > Do you have a reference, or do we have to guess what you are talking > > about? :-) > > I have my memory of the talk he gave, which included the idea > that Sun was not supporting work to modify the PAM architecture > to support Kerberos in the future. The PAM architecture doesn't need any modifications to support Kerberos. It supports Kerberos today. > Basically, you can use it for authentication and password change, > but for little else, and even those uses require going through > incredible hoops (e.g. abusing the authentication module API to > implement a credential cache). > > Did you need more? I guess so. There are many Kerberos 5 PAM modules in existence today, and they support interactive authentication pretty well. There is even some agreement among the authors of related modules on how the credentials cache can be exported for stacking (e.g. for DCE). I can't imagine what `incredible hoops' or `abuse' you might be talking about. The PAM API already includes entry points specificially for the management of credentials. Put another way, in your first sentence above, what might you mean by `for little else'? > Are you really just fishing for Paul Fronberg's email address? No. I'm probably just wasting my time :-) You have stood up and asked for something, but have not given any indication of what it is you want to accomplish. Curiousity has the better of me. > Maybe this release note from HP will explain the limitations > satisfactorily: > > http://docs.hp.com/hpux/onlinedocs/J5849-90001/J5849-90001.html > > NB: This is just for authentication, mostly preauthentication. These seem to be limitations of HP's pam_krb5 module, not of PAM. And again, it is unclear what limitations you might be concerned about. No account management? Well, that's not Kerberos's job. No credentials management? That's a problem with HP's implementation -- see /usr/ports/security/pam_krb5 or pam_krb5 in our base system (they are closely related) for one way it can be done. Limited preauthentication choices? That has to do with the Kerberos implementation, not PAM. I feel like I'm having my leg pulled. Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Jacques A. Vidrine" wrote: > > In the way that the author of the PAM architecture from Sun > > spoke at the Silicon Valley BSD User's Group meeting, > > Do you have a reference, or do we have to guess what you are talking > about? :-) I have my memory of the talk he gave, which included the idea that Sun was not supporting work to modify the PAM architecture to support Kerberos in the future. Basically, you can use it for authentication and password change, but for little else, and even those uses require going through incredible hoops (e.g. abusing the authentication module API to implement a credential cache). Did you need more? Are you really just fishing for Paul Fronberg's email address? Maybe this release note from HP will explain the limitations satisfactorily: http://docs.hp.com/hpux/onlinedocs/J5849-90001/J5849-90001.html NB: This is just for authentication, mostly preauthentication. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 12:48:39PM -0800, Terry Lambert wrote: > "Jacques A. Vidrine" wrote: > > > > On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote: > > > Once you guys have this all hammered out, are you going to > > > integrate PAM and Kerberos? 8-) 8-) 8-). > > > > In what way do you mean? > > In the way that the author of the PAM architecture from Sun > spoke at the Silicon Valley BSD User's Group meeting, Do you have a reference, or do we have to guess what you are talking about? :-) > and > there are just some things that can't be wedged into the > PAM framework until the framework is changed. That is certainly true. It's also true if s/PAM/foo/ for most values of foo. Cheers, -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX .Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Jacques A. Vidrine" wrote: > > On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote: > > Once you guys have this all hammered out, are you going to > > integrate PAM and Kerberos? 8-) 8-) 8-). > > In what way do you mean? In the way that the author of the PAM architecture from Sun spoke at the Silicon Valley BSD User's Group meeting, and there are just some things that can't be wedged into the PAM framework until the framework is changed. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote: > Once you guys have this all hammered out, are you going to > integrate PAM and Kerberos? 8-) 8-) 8-). In what way do you mean? -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
> On Mon, Jan 21, 2002 at 14:07:48 +0100, Dag-Erling Smorgrav wrote: > > Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > > > Umm, you can't use opiechallenge() for that. You're not supposed to > > > call opiechallenge() without also calling opieverify() (plus, I think > > > opiechallenge() "consumes" a challenge). Use opielookup() instead. > > > > Even better, opie_haskey() (which is a wrapper around opielookup()). > > New patch attached. > > Yes, this patch works as expected, but I doubt about opie_haskey() status. > It looks like non-standard FreeBSD addition since it is in the local > opieextra.c file and not in contrib/opie. If you care about > machine independance, better use opielookup() directly. No, that is OK. :-) The FreeBSD PAM modules are all written from scratch as BSD PAM modules. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 14:07:48 +0100, Dag-Erling Smorgrav wrote: > Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > > Umm, you can't use opiechallenge() for that. You're not supposed to > > call opiechallenge() without also calling opieverify() (plus, I think > > opiechallenge() "consumes" a challenge). Use opielookup() instead. > > Even better, opie_haskey() (which is a wrapper around opielookup()). > New patch attached. Yes, this patch works as expected, but I doubt about opie_haskey() status. It looks like non-standard FreeBSD addition since it is in the local opieextra.c file and not in contrib/opie. If you care about machine independance, better use opielookup() directly. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
This is looking good!
Please keep a close eye on style (there is at least one assignment in
an if () statement that needs to move out. :-)
M
> --=-=-=
>
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > Umm, you can't use opiechallenge() for that. You're not supposed to
> > call opiechallenge() without also calling opieverify() (plus, I think
> > opiechallenge() "consumes" a challenge). Use opielookup() instead.
>
> Even better, opie_haskey() (which is a wrapper around opielookup()).
> New patch attached.
>
> DES
> --
> Dag-Erling Smorgrav - [EMAIL PROTECTED]
>
>
> --=-=-=
> Content-Type: text/x-patch
> Content-Disposition: attachment; filename=pam_opieaccess.diff
>
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/lib/libpam/modules/Makefile,v
> retrieving revision 1.15
> diff -u -r1.15 Makefile
> --- Makefile 5 Dec 2001 15:55:14 - 1.15
> +++ Makefile 21 Jan 2002 00:46:54 -
> @@ -34,6 +34,7 @@
> .endif
> SUBDIR+= pam_nologin
> SUBDIR+= pam_opie
> +SUBDIR+= pam_opieaccess
> SUBDIR+= pam_permit
> SUBDIR+= pam_radius
> SUBDIR+= pam_rootok
> Index: pam_opie/pam_opie.8
> ===
> RCS file: /home/ncvs/src/lib/libpam/modules/pam_opie/pam_opie.8,v
> retrieving revision 1.4
> diff -u -r1.4 pam_opie.8
> --- pam_opie/pam_opie.8 14 Jul 2001 08:38:24 - 1.4
> +++ pam_opie/pam_opie.8 21 Jan 2002 01:18:58 -
> @@ -1,5 +1,13 @@
> .\" Copyright (c) 2001 Mark R V Murray
> .\" All rights reserved.
> +.\" Copyright (c) 2002 Networks Associates Technologies, Inc.
> +.\" All rights reserved.
> +.\"
> +.\" Portions of this software were developed for the FreeBSD Project by
> +.\" ThinkSec AS and NAI Labs, the Security Research Division of Network
> +.\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
> +.\" ("CBOSS"), as part of the DARPA CHATS research program.
> +.\"
> .\"
> .\" Redistribution and use in source and binary forms, with or without
> .\" modification, are permitted provided that the following conditions
> @@ -9,6 +17,9 @@
> .\" 2. Redistributions in binary form must reproduce the above copyright
> .\"notice, this list of conditions and the following disclaimer in the
> .\"documentation and/or other materials provided with the distribution.
> +.\" 3. The name of the author may not be used to endorse or promote
> +.\"products derived from this software without specific prior written
> +.\"permission.
> .\"
> .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> @@ -47,6 +58,13 @@
> .Dq Li auth
> feature.
> It also provides a null function for session management.
> +.Pp
> +Note that this module does not enforce
> +.Xr opieaccess 5
> +checks.
> +There is a separate module,
> +.Xr pam_opieaccess 8 ,
> +for this purpose.
> .Ss OPIE Authentication Module
> The OPIE authentication component
> provides functions to verify the identity of a user
> Index: pam_opieaccess/Makefile
> ===
> RCS file: pam_opieaccess/Makefile
> diff -N pam_opieaccess/Makefile
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ pam_opieaccess/Makefile 21 Jan 2002 00:53:49 -
> @@ -0,0 +1,10 @@
> +# $FreeBSD$
> +
> +LIB= pam_opieaccess
> +SHLIB_NAME= ${LIB}.so
> +SRCS=${LIB}.c
> +DPADD= ${LIBOPIE}
> +LDADD= -lopie
> +MAN= pam_opieaccess.8
> +
> +.include
> Index: pam_opieaccess/pam_opieaccess.8
> ===
> RCS file: pam_opieaccess/pam_opieaccess.8
> diff -N pam_opieaccess/pam_opieaccess.8
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ pam_opieaccess/pam_opieaccess.8 21 Jan 2002 13:07:06 -
> @@ -0,0 +1,116 @@
> +.\" Copyright (c) 2001 Mark R V Murray
> +.\" All rights reserved.
> +.\" Copyright (c) 2002 Networks Associates Technologies, Inc.
> +.\" All rights reserved.
> +.\"
> +.\" Portions of this software were developed for the FreeBSD Project by
> +.\" ThinkSec AS and NAI Labs, the Security Research Division of Network
> +.\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
> +.\" ("CBOSS"), as part of the DARPA CHATS research program.
> +.\"
> +.\"
> +.\" Redistribution and use in source and binary forms, with or without
> +.\" modification, are permitted provided that the following conditions
> +.\" are met:
> +.\" 1. Redistributions of source code must retain the above copyright
> +.\"notice, this list of conditions and the following disclaimer.
> +.\" 2. Redistributions in binary form must reproduce the above copyright
> +.\"notice, this list of conditions and the following disclaimer in the
> +.\"documentation and/or other materials provided with the distribution.
> +.\" 3
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 13:54:29 +0100, Dag-Erling Smorgrav wrote: > > Umm, you can't use opiechallenge() for that. You're not supposed to > call opiechallenge() without also calling opieverify() (plus, I think No, it is possible, when opieunlock() called afterwards (as I do). BTW, the same way pam_opie does, see opieunlock() inside prompts loop. > opiechallenge() "consumes" a challenge). No, it is opieverify() who consumes it. You can call opiechallenge() several times with appropriate opieunlock()'s and challenge will not changed. In fact our ftpd does it, first opiechallenge() called to generate prompt in the form pam_opie can't generate and the second is opiechallenge() called from pam_opie (invisible). > Use opielookup() instead. Ok. It will be faster then opiechallenge() for this case. I'll send modified patch. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> Umm, you can't use opiechallenge() for that. You're not supposed to
> call opiechallenge() without also calling opieverify() (plus, I think
> opiechallenge() "consumes" a challenge). Use opielookup() instead.
Even better, opie_haskey() (which is a wrapper around opielookup()).
New patch attached.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libpam/modules/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile 5 Dec 2001 15:55:14 - 1.15
+++ Makefile 21 Jan 2002 00:46:54 -
@@ -34,6 +34,7 @@
.endif
SUBDIR+= pam_nologin
SUBDIR+= pam_opie
+SUBDIR+= pam_opieaccess
SUBDIR+= pam_permit
SUBDIR+= pam_radius
SUBDIR+= pam_rootok
Index: pam_opie/pam_opie.8
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_opie/pam_opie.8,v
retrieving revision 1.4
diff -u -r1.4 pam_opie.8
--- pam_opie/pam_opie.8 14 Jul 2001 08:38:24 - 1.4
+++ pam_opie/pam_opie.8 21 Jan 2002 01:18:58 -
@@ -1,5 +1,13 @@
.\" Copyright (c) 2001 Mark R V Murray
.\" All rights reserved.
+.\" Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\" All rights reserved.
+.\"
+.\" Portions of this software were developed for the FreeBSD Project by
+.\" ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\" ("CBOSS"), as part of the DARPA CHATS research program.
+.\"
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
@@ -9,6 +17,9 @@
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"notice, this list of conditions and the following disclaimer in the
.\"documentation and/or other materials provided with the distribution.
+.\" 3. The name of the author may not be used to endorse or promote
+.\"products derived from this software without specific prior written
+.\"permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
@@ -47,6 +58,13 @@
.Dq Li auth
feature.
It also provides a null function for session management.
+.Pp
+Note that this module does not enforce
+.Xr opieaccess 5
+checks.
+There is a separate module,
+.Xr pam_opieaccess 8 ,
+for this purpose.
.Ss OPIE Authentication Module
The OPIE authentication component
provides functions to verify the identity of a user
Index: pam_opieaccess/Makefile
===
RCS file: pam_opieaccess/Makefile
diff -N pam_opieaccess/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/Makefile 21 Jan 2002 00:53:49 -
@@ -0,0 +1,10 @@
+# $FreeBSD$
+
+LIB= pam_opieaccess
+SHLIB_NAME= ${LIB}.so
+SRCS= ${LIB}.c
+DPADD= ${LIBOPIE}
+LDADD= -lopie
+MAN= pam_opieaccess.8
+
+.include
Index: pam_opieaccess/pam_opieaccess.8
===
RCS file: pam_opieaccess/pam_opieaccess.8
diff -N pam_opieaccess/pam_opieaccess.8
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/pam_opieaccess.8 21 Jan 2002 13:07:06 -
@@ -0,0 +1,116 @@
+.\" Copyright (c) 2001 Mark R V Murray
+.\" All rights reserved.
+.\" Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\" All rights reserved.
+.\"
+.\" Portions of this software were developed for the FreeBSD Project by
+.\" ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\" ("CBOSS"), as part of the DARPA CHATS research program.
+.\"
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\" 3. The name of the author may not be used to endorse or promote
+.\"products derived from this software without specific prior written
+.\"permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREM
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > 1) When OPIE turned on in the system, not neccessary all users are > OPIE-ed, only those who listed in /etc/opiekeys. It means that > pam_opieaccess() module must do something only for valid OPIE users > listed in /etc/opiekeys and do nothing for others. I use opiechallenge() > check for it, and if it fails, return PAM_IGNORE. Umm, you can't use opiechallenge() for that. You're not supposed to call opiechallenge() without also calling opieverify() (plus, I think opiechallenge() "consumes" a challenge). Use opielookup() instead. > 2) opiealways() return just opposite to what you might expect, see > /usr/src/contrib/opie/libopie/accessfile.c comment about it. Fixed by > removing "!" Right, thanks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > Please explain two moments: > > 1) What is stack reaction on this option? Is it the same like PAM_AUTH_ERR > reaction or not? Yes. > 2) Can PAM_SYSTEM_ERR be returned by pam_authenticate() ? If yes. login.c > and ftpd.c must be fixed to add this code. All PAM library calls can return PAM_SYSTEM_ERR. ...but I just realized it's the wrong code in this case - modules should return PAM_SERVICE_ERR instead of PAM_SYSTEM_ERR. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Mark Murray wrote: > > Yes. And to allow PAM stack to make right decision, pam_opie pass special > > information to PAM stack. Look at the patch, pam_opie not breaks from the > > stack by yourself, it is /etc/pam* do that using information from > > pam_opie. > > Sure - but you are making specialised use of the return value that > assumes that pam_opie will be followed by pam_unix. This violates > the PAM spec. Cool discussion. Once you guys have this all hammered out, are you going to integrate PAM and Kerberos? 8-) 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
BTW, I have a doubt about PAM_SYSTEM_ERR code you use in several places like this: > if (luser == NULL) > PAM_RETURN(PAM_SYSTEM_ERR); Please explain two moments: 1) What is stack reaction on this option? Is it the same like PAM_AUTH_ERR reaction or not? 2) Can PAM_SYSTEM_ERR be returned by pam_authenticate() ? If yes. login.c and ftpd.c must be fixed to add this code. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 02:21:34 +0100, Dag-Erling Smorgrav wrote:
>
> No need. See the attached patch.
>
Tested. I use /etc/pam.d/login for test with following OPIE lines:
authsufficient pam_opie.so no_warn
authrequisite pam_opieaccess.so no_warn
Two problems found, patch included below.
1) When OPIE turned on in the system, not neccessary all users are
OPIE-ed, only those who listed in /etc/opiekeys. It means that
pam_opieaccess() module must do something only for valid OPIE users
listed in /etc/opiekeys and do nothing for others. I use opiechallenge()
check for it, and if it fails, return PAM_IGNORE.
2) opiealways() return just opposite to what you might expect, see
/usr/src/contrib/opie/libopie/accessfile.c comment about it. Fixed by
removing "!"
Besides this two things, all works as expected.
--- pam_opieaccess.c.oldMon Jan 21 04:35:08 2002
+++ pam_opieaccess.cMon Jan 21 05:47:27 2002
@@ -55,8 +55,10 @@
PAM_EXTERN int
pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
+ struct opie opie;
struct options options;
struct passwd *pwent;
+ char challenge[OPIE_CHALLENGE_MAX];
char *luser, *rhost;
int r;
@@ -64,22 +66,32 @@
PAM_LOG("Options processed");
- r = pam_get_item(pamh, PAM_RHOST, (const void **)&rhost);
- if (r != PAM_SUCCESS)
- PAM_RETURN(r);
- if (rhost == NULL)
- PAM_RETURN(PAM_SYSTEM_ERR);
-
r = pam_get_item(pamh, PAM_USER, (const void **)&luser);
if (r != PAM_SUCCESS)
PAM_RETURN(r);
if (luser == NULL)
PAM_RETURN(PAM_SYSTEM_ERR);
+ /*
+* Don't call the OPIE atexit() handler when our program exits,
+* since the module has been unloaded and we will SEGV.
+*/
+ opiedisableaeh();
+
+ if (opiechallenge(&opie, (char *)luser, challenge) != 0)
+ PAM_RETURN(PAM_IGNORE);
+ opieunlock();
+
+ r = pam_get_item(pamh, PAM_RHOST, (const void **)&rhost);
+ if (r != PAM_SUCCESS)
+ PAM_RETURN(r);
+ if (rhost == NULL)
+ PAM_RETURN(PAM_SYSTEM_ERR);
+
if ((pwent = getpwnam(luser)) == NULL)
PAM_RETURN(PAM_SYSTEM_ERR);
- if (opieaccessfile(rhost) && !opiealways(pwent->pw_dir))
+ if (opieaccessfile(rhost) && opiealways(pwent->pw_dir))
PAM_RETURN(PAM_IGNORE);
PAM_VERBOSE_ERROR("Refused; remote host is not in opieaccess");
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 02:21:34 +0100, Dag-Erling Smorgrav wrote: > > I'm sorry, but in my opinion that should really be the admin's > decision. You can trust a machine without necessarily trusting users > coming from that machine to pick good passwords. I not advocate some my position here, I just explain how OPIE supposed to works, i.e. how people (sysadmins) know about it and know how to configure it. IMHO PAM transition should minimize differences with the documented and known by people way of how OPIE works. Generally speaking, you can submit your ideas to OPIE people and they may add some per-user mechanism in future versions. > No need. See the attached patch. Ok. I'll inform you after some testing. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> On Mon, Jan 21, 2002 at 01:42:00 +0100, Dag-Erling Smorgrav wrote:
> > The admin can't enforce "always OPIE" for a user, because the user can
> > always delete his ~/.opiealways.
> This is per-machine choice. Long time ago, for S-KEY, it was per-terminal
> choice too, but OPIE currently not have per-terminal module.
> There is no needs to enforce it for user logged from trusted machine since
> whole machine is trusted.
I'm sorry, but in my opinion that should really be the admin's
decision. You can trust a machine without necessarily trusting users
coming from that machine to pick good passwords.
> > How about I write a pam_opieaccess(8) module and you tell me what you
> > think of it? It's really the cleanest solution from PAM's point of
> > view.
> Ok, I'll write it and send for review.
No need. See the attached patch.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libpam/modules/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile 5 Dec 2001 15:55:14 - 1.15
+++ Makefile 21 Jan 2002 00:46:54 -
@@ -34,6 +34,7 @@
.endif
SUBDIR+= pam_nologin
SUBDIR+= pam_opie
+SUBDIR+= pam_opieaccess
SUBDIR+= pam_permit
SUBDIR+= pam_radius
SUBDIR+= pam_rootok
Index: pam_opie/pam_opie.8
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_opie/pam_opie.8,v
retrieving revision 1.4
diff -u -r1.4 pam_opie.8
--- pam_opie/pam_opie.8 14 Jul 2001 08:38:24 - 1.4
+++ pam_opie/pam_opie.8 21 Jan 2002 01:18:58 -
@@ -1,5 +1,13 @@
.\" Copyright (c) 2001 Mark R V Murray
.\" All rights reserved.
+.\" Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\" All rights reserved.
+.\"
+.\" Portions of this software were developed for the FreeBSD Project by
+.\" ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\" ("CBOSS"), as part of the DARPA CHATS research program.
+.\"
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
@@ -9,6 +17,9 @@
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"notice, this list of conditions and the following disclaimer in the
.\"documentation and/or other materials provided with the distribution.
+.\" 3. The name of the author may not be used to endorse or promote
+.\"products derived from this software without specific prior written
+.\"permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
@@ -47,6 +58,13 @@
.Dq Li auth
feature.
It also provides a null function for session management.
+.Pp
+Note that this module does not enforce
+.Xr opieaccess 5
+checks.
+There is a separate module,
+.Xr pam_opieaccess 8 ,
+for this purpose.
.Ss OPIE Authentication Module
The OPIE authentication component
provides functions to verify the identity of a user
Index: pam_opieaccess/Makefile
===
RCS file: pam_opieaccess/Makefile
diff -N pam_opieaccess/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/Makefile 21 Jan 2002 00:53:49 -
@@ -0,0 +1,10 @@
+# $FreeBSD$
+
+LIB= pam_opieaccess
+SHLIB_NAME= ${LIB}.so
+SRCS= ${LIB}.c
+DPADD= ${LIBOPIE}
+LDADD= -lopie
+MAN= pam_opieaccess.8
+
+.include
Index: pam_opieaccess/pam_opieaccess.8
===
RCS file: pam_opieaccess/pam_opieaccess.8
diff -N pam_opieaccess/pam_opieaccess.8
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/pam_opieaccess.8 21 Jan 2002 01:19:01 -
@@ -0,0 +1,108 @@
+.\" Copyright (c) 2001 Mark R V Murray
+.\" All rights reserved.
+.\" Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\" All rights reserved.
+.\"
+.\" Portions of this software were developed for the FreeBSD Project by
+.\" ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\" ("CBOSS"), as part of the DARPA CHATS research program.
+.\"
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\" 3. The name of the author may not be used to endorse or promote
+
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:45:37 +0100, Dag-Erling Smorgrav wrote: > > No. The "[...]" form is a Linux-PAM invention, and is tightly linked > to Linux-PAM implementation details. It does not exist in other PAM > implementations. I aim to move *away* from dependence on Linux-PAM, > not *towards* it. Well, I understand. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 03:49:08 +0300, Andrey A. Chernov wrote: > > How about I write a pam_opieaccess(8) module and you tell me what you > > think of it? It's really the cleanest solution from PAM's point of > > view. > > Ok, I'll write it and send for review. Oops, some keyboard slip. I mean: Ok, write it and I can review it. BTW, I can write it to, back to slip meaning. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:42:00 +0100, Dag-Erling Smorgrav wrote: > > The admin can't enforce "always OPIE" for a user, because the user can > always delete his ~/.opiealways. This is per-machine choice. Long time ago, for S-KEY, it was per-terminal choice too, but OPIE currently not have per-terminal module. There is no needs to enforce it for user logged from trusted machine since whole machine is trusted. But paranoid users can enforce it for themselfs. > How about I write a pam_opieaccess(8) module and you tell me what you > think of it? It's really the cleanest solution from PAM's point of > view. Ok, I'll write it and send for review. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > What you dislike in that way? This method fully described in pam(8). The fact that it is described in pam(8) does not mean we like it. We also have a man page for gets(3), but you know what BDE will say if you try to use it. > I see no differences using short forms like > > "sufficient" > > or its full long analog like > > "[default=ignore sucess=done new_authtok_reqd=done]" > > short forms are only aliases. No. The "[...]" form is a Linux-PAM invention, and is tightly linked to Linux-PAM implementation details. It does not exist in other PAM implementations. I aim to move *away* from dependence on Linux-PAM, not *towards* it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > On Mon, Jan 21, 2002 at 01:17:44 +0100, Dag-Erling Smorgrav wrote: > > The current system, BTW, leaves the policy in the hands of the user, > > as she can create or remove ~/.opie_always at will. A security policy > > which is based on letting the user decide what is sufficient > > authentication and what is not is not a proper security policy. > No, by creating ~/.opiealways user can only _increase_ its own security > level additionly to pre-setted by sysadmin for him, and can't _decrease_ > it. The admin can't enforce "always OPIE" for a user, because the user can always delete his ~/.opiealways. > > Actually, that idea won't work, because PAM will ignore PAM_AUTH_ERR > > from a "sufficient" module. A "requisite" helper module, placed after > > pam_opie, which fails if ~/.opie_always exists would do the trick, if > > one really wanted this. > ~/.opiealways checked only if opieaccess() found remote host in the > /etc/opieaccess table. Oh. I misunderstood the role of /etc/opieaccess in this. This only strengthens my opinion that this check should be in a separate module. How about I write a pam_opieaccess(8) module and you tell me what you think of it? It's really the cleanest solution from PAM's point of view. > Yes, this check can be done as separate PAM module, but why two modules in > the same area instead of one? Because they're different mechanisms that check different things, and their success or failure have different meanings. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:34:02 +0100, Dag-Erling Smorgrav wrote: > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > > [default=ignore success=done auth_err=die] > > > > works. > > > > Do you agree with this variant? > > No. That's a Linuxism. What do you mean, exactly? Long forms are well described in pam(8) and short forms are only aliases to them. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 00:29:29 +, Mark Murray wrote: > > "sufficient" will not works due to IGNORE assigned to AUTH_ERR reaction. > > > > [default=ignore success=done auth_err=die] > > > > works. > > > > Do you agree with this variant? > > Eeew. It may work, but it is really a last-ditch sort of thing. What you dislike in that way? This method fully described in pam(8). I see no differences using short forms like "sufficient" or its full long analog like "[default=ignore sucess=done new_authtok_reqd=done]" short forms are only aliases. > I much prefer an option that specifies the behaviour. I not understand enough what kind of option you mean exactly, where it whould be and how act exactly. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > [default=ignore success=done auth_err=die] > > works. > > Do you agree with this variant? No. That's a Linuxism. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
> "sufficient" will not works due to IGNORE assigned to AUTH_ERR reaction. > > [default=ignore success=done auth_err=die] > > works. > > Do you agree with this variant? Eeew. It may work, but it is really a last-ditch sort of thing. I much prefer an option that specifies the behaviour. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:17:44 +0100, Dag-Erling Smorgrav wrote: > > That's what PAM is for. If fixed (not necessary plaintext!) passwords > are allowed, the admin will mark pam_opie as "sufficient" and place > pam_unix below it; if they're not, he'll just remove pam_unix. It not allows flexible configuration because it is not depends on remote host for example. I.e. for some host pam_unix can be chained, but for some another - not. > The current system, BTW, leaves the policy in the hands of the user, > as she can create or remove ~/.opie_always at will. A security policy > which is based on letting the user decide what is sufficient > authentication and what is not is not a proper security policy. No, by creating ~/.opiealways user can only _increase_ its own security level additionly to pre-setted by sysadmin for him, and can't _decrease_ it. > Actually, that idea won't work, because PAM will ignore PAM_AUTH_ERR > from a "sufficient" module. A "requisite" helper module, placed after > pam_opie, which fails if ~/.opie_always exists would do the trick, if > one really wanted this. ~/.opiealways checked only if opieaccess() found remote host in the /etc/opieaccess table. Yes, this check can be done as separate PAM module, but why two modules in the same area instead of one? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 00:09:21 +, Mark Murray wrote: > > Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > > > In any case, if I understand what you're trying to do, it can be done > > > by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE > > > if it failed but Unix authentication is still allowed, and > > > PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. > > > In that case, if you mark pam_opie "sufficient", pam_unix will run > > > only if OPIE authentication failed but allowed Unix authentication to > > > proceed. > > > > Hmm, actually, that won't do. I need to think this over some more. > > The usual route is YES or NO, with IGNORE reserved for modules which > have no authentication (like say, pam_motd, which prints /etc/motd > during the pam_session_open() phase). IGNORE may have other uses, > but I can't remember them offhand. "sufficient" will not works due to IGNORE assigned to AUTH_ERR reaction. [default=ignore success=done auth_err=die] works. Do you agree with this variant? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > The basic OPIE/S-KEY idea under that was that normally only one-time > password is allowed, i.e. user is not allowed to type plaintext passwords > at all because connection treated as totally insecured one. > > But for very special cases configured by sysadmin, like working in the > same machine or trusted subnet, OPIE/S-KEY additionally allows plaintext > password too, depending on its own configuration. That's what PAM is for. If fixed (not necessary plaintext!) passwords are allowed, the admin will mark pam_opie as "sufficient" and place pam_unix below it; if they're not, he'll just remove pam_unix. The current system, BTW, leaves the policy in the hands of the user, as she can create or remove ~/.opie_always at will. A security policy which is based on letting the user decide what is sufficient authentication and what is not is not a proper security policy. > > In any case, if I understand what you're trying to do, it can be done > > by [...] > It sounds good, I'll run a test case and inform you about results. Actually, that idea won't work, because PAM will ignore PAM_AUTH_ERR from a "sufficient" module. A "requisite" helper module, placed after pam_opie, which fails if ~/.opie_always exists would do the trick, if one really wanted this. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > > In any case, if I understand what you're trying to do, it can be done > > by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE > > if it failed but Unix authentication is still allowed, and > > PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. > > In that case, if you mark pam_opie "sufficient", pam_unix will run > > only if OPIE authentication failed but allowed Unix authentication to > > proceed. > > Hmm, actually, that won't do. I need to think this over some more. The usual route is YES or NO, with IGNORE reserved for modules which have no authentication (like say, pam_motd, which prints /etc/motd during the pam_session_open() phase). IGNORE may have other uses, but I can't remember them offhand. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 00:56:46 +0100, Dag-Erling Smorgrav wrote: > > What I can't understand is why OPIE is making that decision in the > first place. The only answer I can think of is that it was written > before the advent of PAM, and tries to be a poor man's PAM. That is > not its place. The basic OPIE/S-KEY idea under that was that normally only one-time password is allowed, i.e. user is not allowed to type plaintext passwords at all because connection treated as totally insecured one. But for very special cases configured by sysadmin, like working in the same machine or trusted subnet, OPIE/S-KEY additionally allows plaintext password too, depending on its own configuration. > In any case, if I understand what you're trying to do, it can be done > by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE > if it failed but Unix authentication is still allowed, and > PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. > In that case, if you mark pam_opie "sufficient", pam_unix will run > only if OPIE authentication failed but allowed Unix authentication to > proceed. It sounds good, I'll run a test case and inform you about results. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
> On Sun, Jan 20, 2002 at 23:44:44 +, Mark Murray wrote: > > > > Yes. And to allow PAM stack to make right decision, pam_opie pass special > > > information to PAM stack. Look at the patch, pam_opie not breaks from the > > > stack by yourself, it is /etc/pam* do that using information from > > > pam_opie. > > > > Sure - but you are making specialised use of the return value that > > assumes that pam_opie will be followed by pam_unix. This violates > > the PAM spec. > > The alternative (yet one) way can be adding Unix (plaintext) password > checking code directly to pam_opie. It makes pam_opie fully independent of > other modules and specific position in the /etc/pam.d/* config files and > allows us to not touch them. If you agree with that way, I'll come with > the patch. No. I completely disagree with that method. that is pam_unix's job. DES's PAM_IGNORE suggestion has a lot of merit. > About other points stated in your message, my answer depends on what you > deside for above, because it is unneded to discuss them, if you agree to > make pam_opie self-containing. It must be self-contained, and it must not do stuff that is the job of other modules. Unix password checking is not pam_opie's job. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > In any case, if I understand what you're trying to do, it can be done > by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE > if it failed but Unix authentication is still allowed, and > PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. > In that case, if you mark pam_opie "sufficient", pam_unix will run > only if OPIE authentication failed but allowed Unix authentication to > proceed. Hmm, actually, that won't do. I need to think this over some more. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:44:44 +, Mark Murray wrote: > > Yes. And to allow PAM stack to make right decision, pam_opie pass special > > information to PAM stack. Look at the patch, pam_opie not breaks from the > > stack by yourself, it is /etc/pam* do that using information from > > pam_opie. > > Sure - but you are making specialised use of the return value that > assumes that pam_opie will be followed by pam_unix. This violates > the PAM spec. The alternative (yet one) way can be adding Unix (plaintext) password checking code directly to pam_opie. It makes pam_opie fully independent of other modules and specific position in the /etc/pam.d/* config files and allows us to not touch them. If you agree with that way, I'll come with the patch. About other points stated in your message, my answer depends on what you deside for above, because it is unneded to discuss them, if you agree to make pam_opie self-containing. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > Yes. And to allow PAM stack to make right decision, pam_opie pass special > information to PAM stack. Look at the patch, pam_opie not breaks from the > stack by yourself, it is /etc/pam* do that using information from > pam_opie. What I can't understand is why OPIE is making that decision in the first place. The only answer I can think of is that it was written before the advent of PAM, and tries to be a poor man's PAM. That is not its place. In any case, if I understand what you're trying to do, it can be done by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE if it failed but Unix authentication is still allowed, and PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. In that case, if you mark pam_opie "sufficient", pam_unix will run only if OPIE authentication failed but allowed Unix authentication to proceed. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
> On Sun, Jan 20, 2002 at 23:14:13 +, Mark Murray wrote: > > > > The PAM OPIE may only do OPIE authentication. It is entirely up to the > > PAM stack to decide what the login policy is. > > > > (Well, the PAM stack as specified by the pam configs in /etc/pam*) > > Yes. And to allow PAM stack to make right decision, pam_opie pass special > information to PAM stack. Look at the patch, pam_opie not breaks from the > stack by yourself, it is /etc/pam* do that using information from > pam_opie. Sure - but you are making specialised use of the return value that assumes that pam_opie will be followed by pam_unix. This violates the PAM spec. > > However - the module may pass on the authentication token (the password) > > and any following modules are allowed to use this if they find it. > > (look at the try_first_pass and use_fist_pass options). > > I was thinking about that way but not find a good solution. That way > workatround is: > > 1) In the failure case when Unix (plaintext) passwords are disabled > pam_opie can pass specially-generated incorrect password down to pam_unix. > > 2) pam_unix option must be changed from "try_first_pass" to > "use_first_pass", because it asks again for password if "try_first_pass" > active, i.e. allows user to enter Unix (plaintext) password again. So we > have the same bug, but shifted to one prompt step. You may be able to do something with options. Example: if the sysadmin allows a password to be passed down the stack, otherwise pass a dummy. (like ftpdauthrequiredpam_opie.so keep_password or similar) > I have doubts about 1): what specially-generated incorrect password > can be? It seems that any combination is legal and MAY be equal to real > password. Nope. kill the password if it is not allowed. Pass a NULL. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:14:13 +, Mark Murray wrote: > > The PAM OPIE may only do OPIE authentication. It is entirely up to the > PAM stack to decide what the login policy is. > > (Well, the PAM stack as specified by the pam configs in /etc/pam*) Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. > However - the module may pass on the authentication token (the password) > and any following modules are allowed to use this if they find it. > (look at the try_first_pass and use_fist_pass options). I was thinking about that way but not find a good solution. That way workatround is: 1) In the failure case when Unix (plaintext) passwords are disabled pam_opie can pass specially-generated incorrect password down to pam_unix. 2) pam_unix option must be changed from "try_first_pass" to "use_first_pass", because it asks again for password if "try_first_pass" active, i.e. allows user to enter Unix (plaintext) password again. So we have the same bug, but shifted to one prompt step. I have doubts about 1): what specially-generated incorrect password can be? It seems that any combination is legal and MAY be equal to real password. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
> Bug:
>
> pam_opie module _always_ allows Unix (plaintext) password, even in the
> cases which are disabled by OPIE auth procedure.
I agree that this is a bug.
> Description:
>
> How non-PAM standalone OPIE works:
>
> 1) If OPIE user exists, its remote host checked against /etc/opieaccess
> via opieaccessfile()
>
> 2) If remote host is found there, user home dir checked for ~/.opiealways
> file via opiealways()
>
> 3) If no such file, it is assumed than OPIE user is allowed to
> authenticate with plaintext (Unix) password additionly to OPIE exchange.
The PAM OPIE may only do OPIE authentication. It is entirely up to the
PAM stack to decide what the login policy is.
(Well, the PAM stack as specified by the pam configs in /etc/pam*)
> In all other cases OPIE user is not allowed to authenticate with plaintext
> (Unix) password.
> How PAM OPIE works:
>
> OPIE user can _always_ authenticate with plaintext (Unix) password which
> is is security lowering and violates OPIE way of things.
Oops. Yes. That is not good.
> Fix:
>
> It can't be fixed in current 2-state pam_opie return codes model, we need
> 3 codes:
>
> 1) For OPIE exchange success
> 2) For OPIE exchange failure, but Unix (plaintext) passwords allowed
> 3) For OPIE exchange failure, but Unix (plaintext) passwords disabled
Nope. I disagree.
1) Success.
2) Failure.
3) Failure.
> 1) and 2) works exact as in old 2-state model, so 1) is PAM_SUCCESS and 2)
> is PAM_AUTH_ERR.
2) and 3) are _both_ PAM_AUTH_ERR.
However - the module may pass on the authentication token (the password)
and any following modules are allowed to use this if they find it.
(look at the try_first_pass and use_fist_pass options).
> I choose PAM_CRED_INSUFFICIENT for case 3) which means that pam_opie
> module deside that all additionally possible auth will be insufficient and
> returns immediately from modules chain with this code.
No. This is messing with the PAM stack in a weird way. I disagree
with this method.
> --- pam_opie.c.oldSun Jan 20 23:56:47 2002
> +++ pam_opie.cMon Jan 21 00:24:51 2002
> @@ -66,13 +66,14 @@
> struct opie opie;
> struct options options;
> struct passwd *pwd;
> - int retval, i;
> + int retval, i, pwok;
> char *(promptstr[]) = { "%s\nPassword: ", "%s\nPassword [echo on]: "};
> char challenge[OPIE_CHALLENGE_MAX];
> char prompt[OPIE_CHALLENGE_MAX+22];
> char resp[OPIE_SECRET_MAX];
> const char *user;
> const char *response;
> + const char *rhost;
>
> pam_std_option(&options, other_options, argc, argv);
>
> @@ -97,6 +98,8 @@
> retval = pam_get_user(pamh, (const char **)&user, NULL);
> if (retval != PAM_SUCCESS)
> PAM_RETURN(retval);
> + if ((pwd = getpwnam(user)) == NULL)
> + PAM_RETURN(PAM_AUTH_ERR);
> }
>
> PAM_LOG("Got user: %s", user);
> @@ -107,7 +110,14 @@
>*/
> opiedisableaeh();
>
> - opiechallenge(&opie, (char *)user, challenge);
> + if (opiechallenge(&opie, (char *)user, challenge) == 0) {
> + rhost = NULL;
> + (void) pam_get_item(pamh, PAM_RHOST, (const void **)&rhost);
> + pwok = (rhost != NULL) && (*rhost != '\0') &&
> +opieaccessfile((char *)rhost) &&
> +opiealways(pwd->pw_dir);
> + } else
> + pwok = 1;
> for (i = 0; i < 2; i++) {
> snprintf(prompt, sizeof prompt, promptstr[i], challenge);
> retval = pam_get_pass(pamh, &response, prompt, &options);
> @@ -134,7 +144,10 @@
>* it expects. Thus we can't log an error and can only check for
>* success or lack thereof.
>*/
> - retval = opieverify(&opie, resp) == 0 ? PAM_SUCCESS : PAM_AUTH_ERR;
> + if (opieverify(&opie, resp) != 0)
> + retval = pwok ? PAM_AUTH_ERR : PAM_CRED_INSUFFICIENT;
> + else
> + retval = PAM_SUCCESS;
> PAM_RETURN(retval);
> }
>
> --- ftpd.c.bakSat Jan 19 21:29:50 2002
> +++ ftpd.cMon Jan 21 00:30:03 2002
> @@ -1190,6 +1190,7 @@
> break;
>
> case PAM_AUTH_ERR:
> + case PAM_CRED_INSUFFICIENT:
> case PAM_USER_UNKNOWN:
> case PAM_MAXTRIES:
> rval = 1;
> --- login.c.bak Sat Jan 19 21:05:16 2002
> +++ login.c Mon Jan 21 00:31:45 2002
> @@ -802,6 +802,7 @@
> break;
>
> case PAM_AUTH_ERR:
> + case PAM_CRED_INSUFFICIENT:
> case PAM_USER_UNKNOWN:
> case PAM_MAXTRIES:
> rval = 1;
> --- su.bakSat Jan 19 21:29:49 2002
> +++ suMon Jan 21 00:39:04 2002
> @@ -9,7 +9,7 @@
> auth requisite pam_wheel.sono_warn auth_as_self noroot_ok
> #authsufficient pam_kerberosIV.so no_warn
> #authsufficient pam_krb5.so no_warn try_first_pass
>auth_as_self
> -#authrequire
