David Mitton | 15 Nov 2011 17:57

Login PAM interaction suspect


  I'm not sure where to discuss this, but this seemed like a venue  
that would attract some knowledgeable feedback.

  I am designing a PAM module to serve as a backup authentication  
mechanism for a device when it has lost network connectivity to it's  
LDAP server.  There is no local password containing file on the  
system. The credential used has OTP-ish properties and encodes a  
privilege level as well.
  Upon successful authentication, I planned on the module fabricating  
a one line passwd file that would be timestamped and deleted past usage.
  A helper nsslib function will deal with fronting the "user"  
information to login and the system.

  I was wondering which api service to put the logic the builds the  
authenticated user information.
  I was thinking that pam_setcred() would be appropriate.

  But then I decided to read the login code and my head exploded.   
Below is a simplified snippet of the login code we have in our distro.  
  I looked at the current code on kernel.org, and it seems to be  
rewritten and refactored into multiple subroutines, but still has the  
same logic flow.

---<snippet of login.c>----
     /*
      * Grab the user information out of the password file for future usage
      * First get the username that we are actually using, though.
      */
     retcode = pam_get_item(pamh, PAM_USER, (const void **) &username);
(Continue reading)

Nicolas François | 15 Nov 2011 22:17
Picon

Re: Login PAM interaction suspect

Hello,

On Tue, Nov 15, 2011 at 11:57:05AM -0500, David Mitton wrote:
> 
>  I am designing a PAM module to serve as a backup authentication
> mechanism for a device when it has lost network connectivity to it's
> LDAP server.  There is no local password containing file on the
> system. The credential used has OTP-ish properties and encodes a
> privilege level as well.
>  Upon successful authentication, I planned on the module fabricating
> a one line passwd file that would be timestamped and deleted past
> usage.
>  A helper nsslib function will deal with fronting the "user"
> information to login and the system.
> 
>  I was wondering which api service to put the logic the builds the
> authenticated user information.
>  I was thinking that pam_setcred() would be appropriate.

I have no strong opinion, but this could be pam_authenticate() or
pam_acct_mgmt().

> 2) The bigger picture:  notice that getpwnam() and initgroups() has
> been called before any of this.
>    So if pam_setcred() or pam_open_session() have any effect on
> PAM_USER, the user database, or the information returned by nss
> functions they will not be noticed by login.

Note also in the pam_setcred manpage:

(Continue reading)

Barry Brimer | 16 Nov 2011 14:39

Re: Login PAM interaction suspect

On Tue, 15 Nov 2011, David Mitton wrote:
> I am designing a PAM module to serve as a backup authentication mechanism 
> for a device when it has lost network connectivity to it's LDAP server.

Are you familiar with sssd?

https://fedorahosted.org/sssd/

Barry
David Mitton | 16 Nov 2011 16:11

Re: Login PAM interaction suspect

No I wasn't, thank you.  That is interesting.
Perhaps a bit more complicated that we need.

This is an industrial type application.  We intend not to put a local  
account in the box from the factory. And it's possible that the system  
never got to the LDAP server to cache any credentials.  Actual logins  
will be rather rare as
most communication is done with SNMP or data apps.

Dave.

Quoting Barry Brimer <lists <at> brimer.org>:

> On Tue, 15 Nov 2011, David Mitton wrote:
>> I am designing a PAM module to serve as a backup authentication   
>> mechanism for a device when it has lost network connectivity to   
>> it's LDAP server.
>
> Are you familiar with sssd?
>
> https://fedorahosted.org/sssd/
>
> Barry
>
> _______________________________________________
> Pam-list mailing list
> Pam-list <at> redhat.com
> https://www.redhat.com/mailman/listinfo/pam-list
David Mitton | 16 Nov 2011 16:38

Re: Login PAM interaction suspect

> From: Nicolas François <nekral lists gmail com> To: Pluggable  
> Authentication Modules <pam-list redhat com> Subject: Re: Login PAM  
> interaction suspect Date: Tue, 15 Nov 2011 22:17:52 +0100 Hello,
>
> On Tue, Nov 15, 2011 at 11:57:05AM -0500, David Mitton wrote:
>>
>>  I am designing a PAM module to serve as a backup authentication
>> mechanism for a device when it has lost network connectivity to it's
>> LDAP server.  There is no local password containing file on the
>> system. The credential used has OTP-ish properties and encodes a
>> privilege level as well.
>>  Upon successful authentication, I planned on the module fabricating
>> a one line passwd file that would be timestamped and deleted past
>> usage.
>>  A helper nsslib function will deal with fronting the "user"
>> information to login and the system.
>>
>>  I was wondering which api service to put the logic the builds the
>> authenticated user information.
>>  I was thinking that pam_setcred() would be appropriate.
>
> I have no strong opinion, but this could be pam_authenticate() or
> pam_acct_mgmt().
>
>> 2) The bigger picture:  notice that getpwnam() and initgroups() has
>> been called before any of this.
>>    So if pam_setcred() or pam_open_session() have any effect on
>> PAM_USER, the user database, or the information returned by nss
>> functions they will not be noticed by login.
>
(Continue reading)

Nicolas François | 16 Nov 2011 19:57
Picon

Re: Login PAM interaction suspect

Hello,

On Wed, Nov 16, 2011 at 10:38:55AM -0500, David Mitton wrote:
> 
> This was discussed in some other forum (which I lost my breadcrumbs to).
> It's moot to me, as I currently don't plan on changing that value.
> But login should not assume that  getpwnam(PAM_USER) will work until
> committed with a setcred.

OK. I see your point and getpwnam() should be delayed as much as possible.

However, login is required to setuid(<UID>) / setgid(<GID>) before
setcred, and <UID> or <GID> can only be found using getpwnam(PAM_USER).

Best Regards,
--

-- 
Nekral
David Mitton | 16 Nov 2011 22:43

Re: Login PAM interaction suspect

Quoting Nicolas François <nekral.lists <at> gmail.com>:

> Hello,
>
> On Wed, Nov 16, 2011 at 10:38:55AM -0500, David Mitton wrote:
>>
>> This was discussed in some other forum (which I lost my breadcrumbs to).
>> It's moot to me, as I currently don't plan on changing that value.
>> But login should not assume that  getpwnam(PAM_USER) will work until
>> committed with a setcred.
>
> OK. I see your point and getpwnam() should be delayed as much as possible.
>
> However, login is required to setuid(<UID>) / setgid(<GID>) before
> setcred, and <UID> or <GID> can only be found using getpwnam(PAM_USER).

Why would that be?  and where is it written?
Thanks

>
> Best Regards,
> --
> Nekral
>
> _______________________________________________
> Pam-list mailing list
> Pam-list <at> redhat.com
> https://www.redhat.com/mailman/listinfo/pam-list
>
(Continue reading)

Thorsten Kukuk | 17 Nov 2011 09:38
Picon

Re: Login PAM interaction suspect

On Wed, Nov 16, David Mitton wrote:

> Quoting Nicolas François <nekral.lists <at> gmail.com>:
>
>> Hello,
>>
>> On Wed, Nov 16, 2011 at 10:38:55AM -0500, David Mitton wrote:
>>>
>>> This was discussed in some other forum (which I lost my breadcrumbs to).
>>> It's moot to me, as I currently don't plan on changing that value.
>>> But login should not assume that  getpwnam(PAM_USER) will work until
>>> committed with a setcred.
>>
>> OK. I see your point and getpwnam() should be delayed as much as possible.
>>
>> However, login is required to setuid(<UID>) / setgid(<GID>) before
>> setcred, and <UID> or <GID> can only be found using getpwnam(PAM_USER).
>
> Why would that be?

Because else pam_setcred cannot modify them and calling them
afterwards would invalidate all changes pam_setcred() is doing.

> and where is it written?

Did you ever read the manual page about pam_setcred()?

"Such credentials should be established,
 by the application, prior to a call to this function. For example,
 initgroups(2) (or equivalent) should have been performed."
(Continue reading)

David Mitton | 17 Nov 2011 16:05

Re: Login PAM interaction suspect

Quoting Thorsten Kukuk <kukuk <at> suse.de>:

> On Wed, Nov 16, David Mitton wrote:
>
>> Quoting Nicolas François <nekral.lists <at> gmail.com>:
>>
>>> Hello,
>>>
>>> On Wed, Nov 16, 2011 at 10:38:55AM -0500, David Mitton wrote:
>>>>
>>>> This was discussed in some other forum (which I lost my breadcrumbs to).
>>>> It's moot to me, as I currently don't plan on changing that value.
>>>> But login should not assume that  getpwnam(PAM_USER) will work until
>>>> committed with a setcred.
>>>
>>> OK. I see your point and getpwnam() should be delayed as much as possible.
>>>
>>> However, login is required to setuid(<UID>) / setgid(<GID>) before
>>> setcred, and <UID> or <GID> can only be found using getpwnam(PAM_USER).
>>
>> Why would that be?
>
> Because else pam_setcred cannot modify them and calling them
> afterwards would invalidate all changes pam_setcred() is doing.
>
>> and where is it written?
>
> Did you ever read the manual page about pam_setcred()?
>
> "Such credentials should be established,
(Continue reading)

Thorsten Kukuk | 17 Nov 2011 16:59
Picon

Re: Login PAM interaction suspect

On Thu, Nov 17, David Mitton wrote:

> Which was the first thing I saw login do wrong.  It calls pam_open_session 
> before pam_setcred.  I'm waiting for someone to explain that.

As I think somebody wrote already here: it's a bug in login where
I did send already a patch upstream.

> The scope of what it means to set credentials is obscure here.
> Since typically credentials are username and password and they are either 
> stored in a local file or a remote server.

No, this are not credentials. This is the authentication stuff.
Credentials tells the system what you are allowed to do and what not.

> The UID and GID are not credentials in the typical authentication sense.

They are credentials in a typical UNIX system, but you are right
that they are not for authentication. But they tell the system later
what you are allowed to do and what not.

  Thorsten

--

-- 
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
David Mitton | 17 Nov 2011 20:04

Re: Login PAM interaction suspect

On 11/17/2011 10:59 AM, Thorsten Kukuk wrote:
> > Which was the first thing I saw login do wrong.  It calls pam_open_session
> > before pam_setcred.  I'm waiting for someone to explain that.
>
>As I think somebody wrote already here: it's a bug in login where
>I did send already a patch upstream.

Sorry, I haven't seen that.
I though I pulled the current source rev before I composed this.  But 
I could be wrong.

Are the lists archived somewhere they can be search on multi-year vs. 
month at a time basis?

Dave. 
Tomas Mraz | 18 Nov 2011 11:46
Picon
Favicon

Re: Login PAM interaction suspect

On Thu, 2011-11-17 at 16:59 +0100, Thorsten Kukuk wrote: 
> On Thu, Nov 17, David Mitton wrote:
> 
> 
> > Which was the first thing I saw login do wrong.  It calls pam_open_session 
> > before pam_setcred.  I'm waiting for someone to explain that.
> 
> As I think somebody wrote already here: it's a bug in login where
> I did send already a patch upstream.

Note that the original PAM RFC has an example where the pam_setcred() is
called AFTER the pam_open_session(). This conflict with the manual page
was never resolved one way or another. Some applications prefer calling
pam_setcred() twice with PAM_ESTABLISH_CRED before pam_open_session()
and with PAM_REINITIALIZE_CRED after pam_open_session().

Also for David, I'd really say, that what you want to do is really a
hack as the correct thing would be to write a proper nsswitch module or
to use an existing one. And if you insist on such a hack you should
really use pam_acct_mgmt() call to put the user into the
local /etc/passwd instead of relying on pam_setcred() behavior in one
way or another.
--

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
Thorsten Kukuk | 18 Nov 2011 12:37
Picon

Re: Login PAM interaction suspect

On Fri, Nov 18, Tomas Mraz wrote:

> On Thu, 2011-11-17 at 16:59 +0100, Thorsten Kukuk wrote: 
> > On Thu, Nov 17, David Mitton wrote:
> > 
> > 
> > > Which was the first thing I saw login do wrong.  It calls pam_open_session 
> > > before pam_setcred.  I'm waiting for someone to explain that.
> > 
> > As I think somebody wrote already here: it's a bug in login where
> > I did send already a patch upstream.
> 
> Note that the original PAM RFC has an example where the pam_setcred() is
> called AFTER the pam_open_session(). This conflict with the manual page
> was never resolved one way or another.

The requirement to call pam_setcred() before pam_open_session() was only
found out later, when people did recognize that you need to set the
credentials before calling pam_open_session, so that some things, which 
needs the credentials, can work in pam_open_session(). I remember
at least pam_mount and kerberos for example.

  Thorsten

--

-- 
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
David Mitton | 18 Nov 2011 15:07

Re: Login PAM interaction suspect

Quoting Tomas Mraz <tmraz <at> redhat.com>:

> On Thu, 2011-11-17 at 16:59 +0100, Thorsten Kukuk wrote:
>> On Thu, Nov 17, David Mitton wrote:
>>
>>
>> > Which was the first thing I saw login do wrong.  It calls pam_open_session
>> > before pam_setcred.  I'm waiting for someone to explain that.
>>
>> As I think somebody wrote already here: it's a bug in login where
>> I did send already a patch upstream.
>
> Note that the original PAM RFC has an example where the pam_setcred() is
> called AFTER the pam_open_session(). This conflict with the manual page
> was never resolved one way or another. Some applications prefer calling
> pam_setcred() twice with PAM_ESTABLISH_CRED before pam_open_session()
> and with PAM_REINITIALIZE_CRED after pam_open_session().
>
> Also for David, I'd really say, that what you want to do is really a
> hack as the correct thing would be to write a proper nsswitch module or
> to use an existing one. And if you insist on such a hack you should
> really use pam_acct_mgmt() call to put the user into the
> local /etc/passwd instead of relying on pam_setcred() behavior in one
> way or another.

I'm sorry, if you read my earlier messages, I am writting an nsswitch  
module, the issue was _when_ my nsswitch got the information  
_relative_ to the PAM processing.  My first read of the documentation  
was that it would make sense to do that at pam_setcred() time.  My  
read of login has convinced me otherwise.
(Continue reading)


Gmane