[security-discuss] PSARC/2003/674 [restart] pam_list module

[Darren J Moffat]

Mike Gerdts wrote:
> On 2/23/07, Darren J Moffat <Darren.Moffat at sun.com> wrote:
>> DESCRIPTION
>>      pam_list module implements pam_sm_acct_mgmt(), which
>>      provides  functionality to the PAM account management stack.
>>      The module provides functions to validate  that  the  user's
>>      account  is  valid on this host based on a list of users and/or
>>      netgroups in the given file.
> 
> There should be some hint in the man page that netgroups start with @.
> 
>>      The username is the value of PAM_USER.  The host is the value of
>>      PAM_RHOST or if PAM_RHOST is NOT set then the value of the localhost
>>      as returned by gethostname(3c) is used.
> 
> Would it be feasible to extend the functionality to allow address
> ranges, either in the form of bare IP addresses, IP ranges
> (192.168.200.0 - 1192.168.200.37), or net/mask (192.168.1.0/24,
> 192.168.4.0/255.255.252.0)?

Possible yes, but in this particular project case no I'm not willing to 
add that complexity.

> At best, PAM_RHOST would be difficult to use here (e.g. getpeeraddr()
> returned a hostname that resolves to multiple IP addresses).  Can you
> still do a getpeeraddr() by the time that the PAM stack is being
> processed?

You can't use getpeeraddr() inside a PAM module because it doesn't have 
access to the file descriptor that represents the peer.

>>      user_host_exact
>>         The user and hostname must be in the same netgroup.
> 
> Could this also mean user at host?  For the few cases where I need
> telnet/ftp/rsh enabled, it is not worth the trouble of a netgroup.
> user at host would make the administration much easier.

We will consider user at host for a future case, but not this one.

> A test program to verify configuration would be extremely helpful.
> Currently, as I abuse compat, I can do "getent passwd [username]" to
> get a pretty good idea who has access to a system.  This module would
> break that functionality.  A test program would likely be along the
> lines of:

Not as part of this case.

-- 
Darren J Moffat