From darrenm@sac.sfbay.sun.com Mon Apr 21 14:07:00 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3LL6xB3019061 for ; Mon, 21 Apr 2008 14:07:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3LL6vNE018614; Tue, 22 Apr 2008 05:06:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZP0020B1BJXN00@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Apr 2008 14:06:55 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZP002NK1BI5E10@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Apr 2008 14:06:55 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3LL6s9g061965; Mon, 21 Apr 2008 14:06:54 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3LL6q6l019035; Mon, 21 Apr 2008 14:06:52 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m3LL6qUG019031; Mon, 21 Apr 2008 14:06:52 -0700 (PDT) Date: Mon, 21 Apr 2008 14:06:52 -0700 (PDT) From: Darren J Moffat Subject: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] To: PSARC-ext@sun.com Cc: security-discuss@opensolaris.org Message-id: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7482 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: RADIUS PAM module (pam_radius_auth) 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 21 April, 2008 4. Technical Description Proposal -------- This project provides a PAM module for RADIUS authentication. The module is not added to the default pam.conf on Solaris. Configuration is the /etc/raddb/server file. Multiple RADIUS servers are supported with different shared secrets ports and timeouts for each one. The /etc/raddb/server file contains an unencrypted shared secret with the RADIUS server and must be installed as readable only by root. A sample configuration file is in the materials directory. The config file will be installed as an editable file with the default content all commented out. Implementation Notes -------------------- The module only supports the auth stack. pam_sm_setcred(3PAM) returns the same value as pam_sm_authenticate(3PAM) returned or PAM_SUCCESS if pam_sm_setcred(3PAM) was called without pam_sm_authenticate(3PAM). This isn't ideal as pam_sm_setcred(3PAM) should probably always return PAM_IGNORE - comments in the code indicate that the upstream project team is aware of this but wants "best compatibility" across all PAM implementations. Documentation ------------- The upstream source does not provide man page documentation. The documentation that is provided upstream is included in this proposal below the interface tables. The project team will work with the Sun man page team to turn this into a man page format, and will also contribute the resulting man page back upstream. The man page ship in Solaris will contain the ATTRIBUTES and other standard Sun man page sections. The above mentioned pam_sm_setcred issue will also be documented. Release Binding: patch +------- Exported Interfaces ----------------------------------------------+ | Interface | Taxonomy | Comment | +--------------------------------------------------------------------------+ | SUNWfreeradius-pam | UnCommitted | Package | | /usr/lib/security/$ISA/pam_radius_auth.so.1 | Committed | | | SUNWfreeradius-pam-root | UnCommitted | Package | | /etc/raddb/server | Committed | Format | | | | & Location | +--------------------------------------------------------------------------+ +------- Imported Interfaces ----------------------------------------------+ | Interface | Taxonomy | Comment | +--------------------------------------------------------------------------+ | libmd(3lib) MD5{Init,Update,Final} | Committed | | +--------------------------------------------------------------------------+ --- Upstream Documentation --- The module takes a number of configuration options. Password changing is not implemented, as the RADIUS protocol does not support it. The pam configuration can be: ... auth sufficient /lib/security/pam_radius_auth.so [options] ... account sufficient /lib/security/pam_radius_auth.so --------------------------------------------------------------------------- The 'options' section is optional, and can contain one or more of the following strings. Note that not all of these options are relevant in for all uses of the module. debug - print out extensive debugging information via pam_log. These messages generally end up being handled by sylog(), and go to /var/log/messages. Depending on your host operating system, the log messages may be elsewhere. You should generally use the debug option when first trying to install the module, as it will help enormously in tracking down problems. use_first_pass - Instead of prompting the user for a password, retrieve the password from the previous authentication module. If the password does not exist, return failure. If the password exists, try it, returning success/failure as appropriate. try_first_pass - Instead of prompting the user for a password, retrieve the password from the previous authentication module. If the password exists, try it, and return success if it passes. If there was no previous password, or the previous password fails authentication, prompt the user with "Enter RADIUS password: ", and ask for another password. Try this password, and return success/failure as appropriate. This is the default for authentication. skip_passwd - Do not prompt for a password, even if there was none retrieved from the previous layer. Send the previous one (if it exists), or else send a NULL password. If this fails, exit. If an Access-Challenge is returned, display the challenge message, and ask the user for the response. Return success/failure as appropriate. The password sent to the next authentication module will NOT be the response to the challenge. If a password from a previous authentication module exists, it is passed on. Otherwise, no password is sent to the next module. conf=foo - set the configuration filename to 'foo'. Default is /etc/raddb/server client_id=bar - send a NAS-Identifier RADIUS attribute with string 'bar'. If the client_id is not specified, the PAM_SERVICE type is used instead. ('login', 'su', 'passwd', etc.) This feature may be disabled by using 'client_id='. i.e. A blank client ID. retry = # - allow a number of retries before continuing to the next authentication module use_authtok - force the use of a previously entered password. This is needed for pluggable password strength checking i.e. try cracklib to be sure it's secure, then go update the RADIUS server. ruser - If PAM_USER is root, Use the value of PAM_RUSER instead of PAM_USER to determine the username to authenticate via RADIUS. This is to allow 'su' to act like 'sudo'. localifdown - This option tells pam_radius to return PAM_IGNORE instead of PAM_AUTHINFO_UNAVAIL if RADIUS auth failed due to network unavailability. PAM_IGNORE tells the pam stack to continue down the stack regardless of the control flag. accounting_bug - When used, the accounting response vector is NOT validated. This option will probably only be necessary on REALLY OLD (i.e. Livingston 1.16) servers. --------------------------------------------------------------------------- 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From vadud3@gmail.com Mon Apr 21 14:25:33 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3LLPXp2020224 for ; Mon, 21 Apr 2008 14:25:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3LLPVAB047041 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 21 Apr 2008 15:25:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZP00I0926KBP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 21 Apr 2008 14:25:32 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZP00HAI26KV500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 21 Apr 2008 14:25:32 -0700 (PDT) Received: from relay18i.sun.com (ip128.net129179-4.block1.us.syntegra.com [129.179.4.128]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3LLKQa4021159 for ; Mon, 21 Apr 2008 21:25:31 +0000 (GMT) Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay18i.sun.com with ESMTP id BT-MMP-150469 for PSARC-ext@sun.com; Mon, 21 Apr 2008 21:25:31 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.sun.com with ESMTP id BT-MMP-5354924 for PSARC-ext@sun.com; Mon, 21 Apr 2008 21:25:30 +0000 (Z) Received: from rv-out-0506.google.com ([209.85.198.240] [209.85.198.240]) by relay1i.sun.com with ESMTP id BT-MMP-2899392 for PSARC-ext@sun.com; Mon, 21 Apr 2008 21:25:30 +0000 (Z) Received: by rv-out-0506.google.com with SMTP id k29so1120577rvb.8 for ; Mon, 21 Apr 2008 14:24:29 -0700 (PDT) Received: by 10.141.163.12 with SMTP id q12mr3588646rvo.260.1208813069084; Mon, 21 Apr 2008 14:24:29 -0700 (PDT) Received: by 10.141.154.17 with HTTP; Mon, 21 Apr 2008 14:24:28 -0700 (PDT) Date: Mon, 21 Apr 2008 17:24:28 -0400 From: Asif Iqbal Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com, security-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_0cD7DuC9pt1HH/KAHGjsPg)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=v7WDkwc0SuRSxFguj4efFsQLye4cmFinwRX7HEFH5OI=; b=Sbrd4Dg1nA1rcRTMZY5iCDCKzUjd7oxe5sXrac0LLqT3WARuPtSCvJAtNauTqS3dGiV7B4NfhGuu3oAWsMHlZuY2Td+hRIYjMNaj9HYvgdxhpiOmy6YT4tUGf5z/lL0FK55mFyTfQRa6SO3qHPcBN8SHoZyydncUakI93G5s5bE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=X9PBtGxMqPCbsBcJLpO02efMClgHGp/XhpYfCHCDeqb5r9SXyF25T5zOCFa3wlstLwza5tIFOfSoR7G1I08Tye0C5efleTAFxxW9Wd1R0pL/Uxxg6BTXWN8Mo4G+e7oYi6sKDQDR1Kub++o4r5Bfb5yDl7Uumfid/8m54GZvCNA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.353sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> Status: RO Content-Length: 20520 --Boundary_(ID_0cD7DuC9pt1HH/KAHGjsPg) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: inline Looks so much like http://www.freeradius.org/pam_radius_auth/ On Mon, Apr 21, 2008 at 5:06 PM, Darren J Moffat wrote: > > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > RADIUS PAM module (pam_radius_auth) > 1.2. Name of Document Author/Supplier: > Author: Darren Moffat > 1.3 Date of This Document: > 21 April, 2008 > 4. Technical Description > > Proposal > -------- > This project provides a PAM module for RADIUS authentication. > The module is not added to the default pam.conf on Solaris. > Configuration is the /etc/raddb/server file. > Multiple RADIUS servers are supported with different shared secrets > ports and timeouts for each one. > > The /etc/raddb/server file contains an unencrypted shared secret with > the RADIUS server and must be installed as readable only by root. > A sample configuration file is in the materials directory. The config > file will be installed as an editable file with the default content > all commented out. > > Implementation Notes > -------------------- > The module only supports the auth stack. pam_sm_setcred(3PAM) returns > the same value as pam_sm_authenticate(3PAM) returned or PAM_SUCCESS > if pam_sm_setcred(3PAM) was called without pam_sm_authenticate(3PAM). > This isn't ideal as pam_sm_setcred(3PAM) should probably always return > PAM_IGNORE - comments in the code indicate that the upstream project > team is aware of this but wants "best compatibility" across all > PAM implementations. > > Documentation > ------------- > The upstream source does not provide man page documentation. The > documentation that is provided upstream is included in this proposal > below the interface tables. The project team will work with the Sun > man page team to turn this into a man page format, and will also > contribute > the resulting man page back upstream. The man page ship in Solaris will > contain the ATTRIBUTES and other standard Sun man page sections. The > above mentioned pam_sm_setcred issue will also be documented. > > Release Binding: patch > > +------- Exported Interfaces > ----------------------------------------------+ > | Interface | Taxonomy | Comment > | > > +--------------------------------------------------------------------------+ > | SUNWfreeradius-pam | UnCommitted | Package > | > | /usr/lib/security/$ISA/pam_radius_auth.so.1 | Committed | > | > | SUNWfreeradius-pam-root | UnCommitted | Package > | > | /etc/raddb/server | Committed | Format > | > | | | & Location > | > > +--------------------------------------------------------------------------+ > > +------- Imported Interfaces > ----------------------------------------------+ > | Interface | Taxonomy | Comment > | > > +--------------------------------------------------------------------------+ > | libmd(3lib) MD5{Init,Update,Final} | Committed | > | > > +--------------------------------------------------------------------------+ > > --- Upstream Documentation --- > > The module takes a number of configuration options. Password changing > is not implemented, as the RADIUS protocol does not support it. > > The pam configuration can be: > ... > auth sufficient /lib/security/pam_radius_auth.so [options] > ... > account sufficient /lib/security/pam_radius_auth.so > > > --------------------------------------------------------------------------- > > The 'options' section is optional, and can contain one or more of > the following strings. Note that not all of these options are > relevant in for all uses of the module. > > debug - print out extensive debugging information via pam_log. > These messages generally end up being handled by > sylog(), and go to /var/log/messages. Depending on > your host operating system, the log messages may be > elsewhere. > You should generally use the debug option when first > trying to install the module, as it will help > enormously in tracking down problems. > > use_first_pass - Instead of prompting the user for a password, retrieve > the password from the previous authentication module. > If the password does not exist, return failure. > If the password exists, try it, returning success/failure > as appropriate. > > try_first_pass - Instead of prompting the user for a password, retrieve > the password from the previous authentication module. > If the password exists, try it, and return success if it > passes. > If there was no previous password, or the previous > password > fails authentication, prompt the user with > "Enter RADIUS password: ", and ask for another password. > Try this password, and return success/failure as > appropriate. > > This is the default for authentication. > > skip_passwd - Do not prompt for a password, even if there was none > retrieved from the previous layer. > Send the previous one (if it exists), or else send a NULL > password. > If this fails, exit. > If an Access-Challenge is returned, display the challenge > message, and ask the user for the response. > Return success/failure as appropriate. > > The password sent to the next authentication module will > NOT be the response to the challenge. If a password from > a previous authentication module exists, it is passed on. > Otherwise, no password is sent to the next module. > > conf=foo - set the configuration filename to 'foo'. > Default is /etc/raddb/server > > client_id=bar - send a NAS-Identifier RADIUS attribute with string > 'bar'. If the client_id is not specified, the PAM_SERVICE > type is used instead. ('login', 'su', 'passwd', etc.) > This feature may be disabled by using 'client_id='. > i.e. A blank client ID. > > retry = # - allow a number of retries before continuing to the next > authentication module > > use_authtok - force the use of a previously entered password. > This is needed for pluggable password strength checking > i.e. try cracklib to be sure it's secure, then go update > the RADIUS server. > > ruser - If PAM_USER is root, Use the value of PAM_RUSER instead > of PAM_USER to determine the username to authenticate via > RADIUS. This is to allow 'su' to act like 'sudo'. > > localifdown - This option tells pam_radius to return PAM_IGNORE instead > of PAM_AUTHINFO_UNAVAIL if RADIUS auth failed due to > network unavailability. PAM_IGNORE tells the pam stack > to continue down the stack regardless of the control flag. > > accounting_bug - When used, the accounting response vector is NOT > validated. This option will probably only be necessary > on REALLY OLD (i.e. Livingston 1.16) servers. > > > --------------------------------------------------------------------------- > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > security-discuss mailing list > security-discuss@opensolaris.org > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu --Boundary_(ID_0cD7DuC9pt1HH/KAHGjsPg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: inline Looks so much like http://www.freeradius.org/pam_radius_auth/

On Mon, Apr 21, 2008 at 5:06 PM, Darren J Moffat <darrenm@sac.sfbay.sun.com> wrote:

Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
   1.1. Project/Component Working Name:
        RADIUS PAM module (pam_radius_auth)
   1.2. Name of Document Author/Supplier:
        Author:  Darren Moffat
   1.3  Date of This Document:
       21 April, 2008
4. Technical Description

Proposal
--------
This project provides a PAM module for RADIUS authentication.
The module is not added to the default pam.conf on Solaris.
Configuration is the /etc/raddb/server file.
Multiple RADIUS servers are supported with different shared secrets
ports and timeouts for each one.

The /etc/raddb/server file contains an unencrypted shared secret with
the RADIUS server and must be installed as readable only by root.
A sample configuration file is in the materials directory.  The config
file will be installed as an editable file with the default content
all commented out.

Implementation Notes
--------------------
The module only supports the auth stack. pam_sm_setcred(3PAM) returns
the same value as pam_sm_authenticate(3PAM) returned or PAM_SUCCESS
if pam_sm_setcred(3PAM) was called without pam_sm_authenticate(3PAM).
This isn't ideal as pam_sm_setcred(3PAM) should probably always return
PAM_IGNORE - comments in the code indicate that the upstream project
team is aware of this but wants "best compatibility" across all
PAM implementations.

Documentation
-------------
The upstream source does not provide man page documentation.  The
documentation that is provided upstream is included in this proposal
below the interface tables.  The project team will work with the Sun
man page team to turn this into a man page format, and will also contribute
the resulting man page back upstream.  The man page ship in Solaris will
contain the ATTRIBUTES and other standard Sun man page sections.  The
above mentioned pam_sm_setcred issue will also be documented.

Release Binding: patch

+------- Exported Interfaces ----------------------------------------------+
| Interface                                    | Taxonomy    | Comment     |
+--------------------------------------------------------------------------+
| SUNWfreeradius-pam                           | UnCommitted | Package     |
|  /usr/lib/security/$ISA/pam_radius_auth.so.1 | Committed   |             |
| SUNWfreeradius-pam-root                      | UnCommitted | Package     |
|  /etc/raddb/server                           | Committed   | Format      |
|                                              |             | & Location  |
+--------------------------------------------------------------------------+

+------- Imported Interfaces ----------------------------------------------+
| Interface                                    | Taxonomy    | Comment     |
+--------------------------------------------------------------------------+
| libmd(3lib)  MD5{Init,Update,Final}          | Committed   |             |
+--------------------------------------------------------------------------+

--- Upstream Documentation ---

 The module takes a number of configuration options.  Password changing
is not implemented, as the RADIUS protocol does not support it.

 The pam configuration can be:
...
auth       sufficient   /lib/security/pam_radius_auth.so [options]
...
account    sufficient   /lib/security/pam_radius_auth.so

---------------------------------------------------------------------------

 The 'options' section is optional, and can contain one or more of
the following strings.  Note that not all of these options are
relevant in for all uses of the module.

debug          - print out extensive debugging information via pam_log.
                These messages generally end up being handled by
                sylog(), and go to /var/log/messages.  Depending on
                your host operating system, the log messages may be
                elsewhere.
                You should generally use the debug option when first
                trying to install the module, as it will help
                enormously in tracking down problems.

use_first_pass - Instead of prompting the user for a password, retrieve
                the password from the previous authentication module.
                If the password does not exist, return failure.
                If the password exists, try it, returning success/failure
                as appropriate.

try_first_pass - Instead of prompting the user for a password, retrieve
                the password from the previous authentication module.
                If the password exists, try it, and return success if it
                passes.
                If there was no previous password, or the previous password
                fails authentication, prompt the user with
                "Enter RADIUS password: ", and ask for another password.
                Try this password, and return success/failure as appropriate.

                This is the default for authentication.

skip_passwd    - Do not prompt for a password, even if there was none
                retrieved from the previous layer.
                Send the previous one (if it exists), or else send a NULL
                password.
                If this fails, exit.
                If an Access-Challenge is returned, display the challenge
                message, and ask the user for the response.
                Return success/failure as appropriate.

                The password sent to the next authentication module will
                NOT be the response to the challenge.  If a password from
                a previous authentication module exists, it is passed on.
                Otherwise, no password is sent to the next module.

conf=foo       - set the configuration filename to 'foo'.
                Default is /etc/raddb/server

client_id=bar  - send a NAS-Identifier RADIUS attribute with string
                'bar'.  If the client_id is not specified, the PAM_SERVICE
                type is used instead. ('login', 'su', 'passwd', etc.)
                This feature may be disabled by using 'client_id='.
                i.e. A blank client ID.

retry = #      - allow a number of retries before continuing to the next
                authentication module

use_authtok    - force the use of a previously entered password.
                This is  needed for pluggable password strength checking
                i.e. try cracklib to be sure it's secure, then go update
                the RADIUS server.

ruser          - If PAM_USER is root, Use the value of PAM_RUSER instead
                of PAM_USER to determine the username to authenticate via
                RADIUS.  This is to allow 'su' to act like 'sudo'.

localifdown    - This option tells pam_radius to return PAM_IGNORE instead
                of PAM_AUTHINFO_UNAVAIL if RADIUS auth failed due to
                network unavailability.  PAM_IGNORE tells the pam stack
                to continue down the stack regardless of the control flag.

accounting_bug - When used, the accounting response vector is NOT
                validated.  This option will probably only be necessary
                on REALLY OLD (i.e. Livingston 1.16) servers.

---------------------------------------------------------------------------



6. Resources and Schedule
   6.4. Steering Committee requested information
       6.4.1. Consolidation C-team Name:
               ON
   6.5. ARC review type: FastTrack
   6.6. ARC Exposure: open

_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org



--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu


--Boundary_(ID_0cD7DuC9pt1HH/KAHGjsPg)-- From Nicolas.Williams@sun.com Mon Apr 21 14:36:43 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3LLagsa020260 for ; Mon, 21 Apr 2008 14:36:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3LLacoO007332 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 21 Apr 2008 22:36:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZP004072P48200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 21 Apr 2008 14:36:40 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZP0025I2P35930@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 21 Apr 2008 14:36:40 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3LLadL3017356; Mon, 21 Apr 2008 16:36:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3LLacmd017355; Mon, 21 Apr 2008 16:36:38 -0500 (CDT) Date: Mon, 21 Apr 2008 16:36:38 -0500 From: Nicolas Williams Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com, security-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , PSARC-ext@sun.com, security-discuss@opensolaris.org Message-id: <20080421213638.GN13552@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 860 On Mon, Apr 21, 2008 at 02:06:52PM -0700, Darren J Moffat wrote: > Implementation Notes > -------------------- > The module only supports the auth stack. pam_sm_setcred(3PAM) returns > the same value as pam_sm_authenticate(3PAM) returned or PAM_SUCCESS > if pam_sm_setcred(3PAM) was called without pam_sm_authenticate(3PAM). > This isn't ideal as pam_sm_setcred(3PAM) should probably always return > PAM_IGNORE - comments in the code indicate that the upstream project > team is aware of this but wants "best compatibility" across all > PAM implementations. I don't buy this "best compatibility" note. LinuxPAM fully supports PAM_IGNORE. It is a bug to return PAM_SUCCESS when the module has done nothing, and it can lead to misconfigurations that are difficult for customers to debug, and even to misconfigurations that result in security holes. Nico -- From Darren.Moffat@sun.com Mon Apr 21 14:51:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3LLpQDL020657 for ; Mon, 21 Apr 2008 14:51:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3LLpOce012586 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 21 Apr 2008 22:51:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZP00L073DOE000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 21 Apr 2008 14:51:24 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZP00HWS3DMUW10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 21 Apr 2008 14:51:23 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3LLpMEQ007449 for ; Mon, 21 Apr 2008 21:51:22 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZP000013D47W00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 21 Apr 2008 22:51:22 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZP00L373DLDC20@fe-emea-10.sun.com>; Mon, 21 Apr 2008 22:51:22 +0100 (BST) Date: Mon, 21 Apr 2008 22:51:21 +0100 From: Darren J Moffat Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: Sender: Darren.Moffat@sun.com To: Asif Iqbal Cc: Darren J Moffat , PSARC-ext@sun.com, security-discuss@opensolaris.org Message-id: <480D0C59.2040007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 125 Asif Iqbal wrote: > Looks so much like http://www.freeradius.org/pam_radius_auth/ Good, because it is. -- Darren J Moffat From Joerg.Barfurth@Sun.COM Tue Apr 22 02:41:51 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3M9fpMo009304 for ; Tue, 22 Apr 2008 02:41:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3M9foh5014769 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Apr 2008 02:41:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ00E0309RD500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 02:41:51 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ00DFO09PIZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 02:41:50 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3M9fn1C019397 for ; Tue, 22 Apr 2008 09:41:49 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZP00E01ZWS4P00@fe-emea-10.sun.com> (original mail from Joerg.Barfurth@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 10:41:49 +0100 (BST) Received: from [10.16.65.103] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZQ00J0909L67G0@fe-emea-10.sun.com>; Tue, 22 Apr 2008 10:41:46 +0100 (BST) Date: Tue, 22 Apr 2008 11:41:45 +0200 From: Joerg Barfurth Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> Sender: Joerg.Barfurth@Sun.COM To: Darren J Moffat Cc: PSARC-ext@Sun.COM, security-discuss@opensolaris.org Message-id: <480DB2D9.1090706@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1207 Hi, Darren J Moffat schrieb: [...] > Implementation Notes > -------------------- > The module only supports the auth stack. > This isn't consistent with the 'upstream documentation' section: > --- Upstream Documentation --- > [...] > ... > auth sufficient /lib/security/pam_radius_auth.so [options] > ... > account sufficient /lib/security/pam_radius_auth.so > So what is it? BTW, on the upstream site I note somewhat contradicting (wrt the section quoted by you) documentation, which mentions even more supported stacks: - There are several places that state that pam_radius_auth does support password changing and how to configure it. Is this available in your version? - There is one place that mentions that pam_radius_auth contains (Linux-only) session module support for RADIUS accounting. Is this available (and can it be ported to Solaris)? - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Joerg.Barfurth@sun.com Tue Apr 22 02:54:42 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3M9sgec009920 for ; Tue, 22 Apr 2008 02:54:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3M9sdvu002304 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Apr 2008 02:54:41 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ00K0B0V54O00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 03:54:41 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ00B9H0V4D760@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 03:54:41 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3M9seCR021540 for ; Tue, 22 Apr 2008 09:54:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZP00H01YPM6J00@fe-emea-10.sun.com> (original mail from Joerg.Barfurth@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Apr 2008 10:54:40 +0100 (BST) Received: from [10.16.46.61] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZQ004Z60UJI340@fe-emea-10.sun.com>; Tue, 22 Apr 2008 10:54:20 +0100 (BST) Date: Tue, 22 Apr 2008 11:54:19 +0200 From: =?ISO-8859-1?Q?J=F6rg_Barfurth?= Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: <20080421213638.GN13552@Sun.COM> Sender: Joerg.Barfurth@sun.com To: Darren J Moffat , PSARC-ext@sun.com, security-discuss@opensolaris.org Message-id: <480DB5CB.4090709@sun.com> Organization: Sun Microsystems GmbH MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> <20080421213638.GN13552@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 2588 Nicolas Williams schrieb: > On Mon, Apr 21, 2008 at 02:06:52PM -0700, Darren J Moffat wrote: >> Implementation Notes >> -------------------- >> The module only supports the auth stack. pam_sm_setcred(3PAM) returns >> the same value as pam_sm_authenticate(3PAM) returned or PAM_SUCCESS >> if pam_sm_setcred(3PAM) was called without pam_sm_authenticate(3PAM). >> This isn't ideal as pam_sm_setcred(3PAM) should probably always return >> PAM_IGNORE - comments in the code indicate that the upstream project >> team is aware of this but wants "best compatibility" across all >> PAM implementations. > > I don't buy this "best compatibility" note. LinuxPAM fully supports > PAM_IGNORE. > But it appears to have interactions between pam_authenticate processing and pam_setcred processing not seen in Solaris PAM. The one I recall is that modules not called during pam_authenticate processing (due to a preceding 'sufficient' success) are not called during pam_setcred processing, even if the 'sufficient' module returns PAM_IGNORE now. Result is that pam_setcred fails because not a single PAM_SUCCESS return has been seen in the shortened stack. Additionally Linux-PAM has an extended control flags syntax that allows specifying details of stack behavior for various return codes. As pam_authenticate and pam_setcred share the auth entry (and thus the control flag), returning a different result (including PAM_IGNORE) from pam_sm_setcred than from pam_sm_authenticate may create behavior that surprises users. > It is a bug to return PAM_SUCCESS when the module has done nothing, and > it can lead to misconfigurations that are difficult for customers to > debug, and even to misconfigurations that result in security holes. > Due to the scenario described above, I have a module that returns PAM_IGNORE from pam_sm_setcred on Solaris, but had to be tweaked to return PAM_SUCCESS on Linux. It looks as if the pam_radius_auth developer had the same issue. But I also agree that returning anything but PAM_IGNORE on Solaris, which doesn't have that pam_setcred processing wart, is a bug. - Jörg -- Joerg Barfurth Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering From Nicolas.Williams@sun.com Tue Apr 22 05:49:11 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MCnBLL013995 for ; Tue, 22 Apr 2008 05:49:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MCn9rH000971; Tue, 22 Apr 2008 05:49:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ0040X8XXKC00@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Apr 2008 05:49:09 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ002AB8XXN630@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Apr 2008 05:49:09 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3MCn8Gp017954; Tue, 22 Apr 2008 07:49:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3MCn7U1017953; Tue, 22 Apr 2008 07:49:07 -0500 (CDT) Date: Tue, 22 Apr 2008 07:49:07 -0500 From: Nicolas Williams Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: <480DB5CB.4090709@sun.com> To: =?iso-8859-1?Q?J=F6rg?= Barfurth Cc: Darren J Moffat , PSARC-ext@sun.com, security-discuss@opensolaris.org Mail-followup-to: =?iso-8859-1?Q?J=F6rg?= Barfurth , Darren J Moffat , PSARC-ext@sun.com, security-discuss@opensolaris.org Message-id: <20080422124907.GR13552@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> <20080421213638.GN13552@Sun.COM> <480DB5CB.4090709@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1924 On Tue, Apr 22, 2008 at 11:54:19AM +0200, Jörg Barfurth wrote: > > I don't buy this "best compatibility" note. LinuxPAM fully supports > > PAM_IGNORE. > > But it appears to have interactions between pam_authenticate processing > and pam_setcred processing not seen in Solaris PAM. The one I recall is > that modules not called during pam_authenticate processing (due to a > preceding 'sufficient' success) are not called during pam_setcred > processing, even if the 'sufficient' module returns PAM_IGNORE now. > > Result is that pam_setcred fails because not a single PAM_SUCCESS return > has been seen in the shortened stack. That's a problems on LinuxPAM. Let them provide a module that does the right thing if need be. > Additionally Linux-PAM has an extended control flags syntax that allows > specifying details of stack behavior for various return codes. As > pam_authenticate and pam_setcred share the auth entry (and thus the > control flag), returning a different result (including PAM_IGNORE) from > pam_sm_setcred than from pam_sm_authenticate may create behavior that > surprises users. We should not allow modules that return PAM_SUCCESS when they have done nothing. Especially account modules (fortunately that's not the problem here). > > It is a bug to return PAM_SUCCESS when the module has done nothing, and > > it can lead to misconfigurations that are difficult for customers to > > debug, and even to misconfigurations that result in security holes. > > > > Due to the scenario described above, I have a module that returns > PAM_IGNORE from pam_sm_setcred on Solaris, but had to be tweaked to > return PAM_SUCCESS on Linux. It looks as if the pam_radius_auth > developer had the same issue. But I also agree that returning anything > but PAM_IGNORE on Solaris, which doesn't have that pam_setcred > processing wart, is a bug. Exactly. So #ifdef this if you must. Nico -- From Darren.Moffat@sun.com Tue Apr 22 10:34:39 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MHYc58025745 for ; Tue, 22 Apr 2008 10:34:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3MHYZrk007282 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Apr 2008 11:34:38 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ00F0DM5P7100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 22 Apr 2008 10:34:37 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ00ERPM5NSM50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 22 Apr 2008 10:34:36 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MHYZMp014109 for ; Tue, 22 Apr 2008 17:34:35 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZQ00L01M492H00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 22 Apr 2008 18:34:35 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZQ001T1M5NF410@fe-emea-10.sun.com>; Tue, 22 Apr 2008 18:34:35 +0100 (BST) Date: Tue, 22 Apr 2008 18:34:34 +0100 From: Darren J Moffat Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: <480DB2D9.1090706@sun.com> Sender: Darren.Moffat@sun.com To: Joerg Barfurth Cc: Darren J Moffat , PSARC-ext@sun.com, security-discuss@opensolaris.org Message-id: <480E21AA.3000204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> <480DB2D9.1090706@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1939 Joerg Barfurth wrote: > Hi, > > Darren J Moffat schrieb: > [...] >> Implementation Notes >> -------------------- >> The module only supports the auth stack. >> > > This isn't consistent with the 'upstream documentation' section: My mistake. >> --- Upstream Documentation --- >> > [...] >> ... >> auth sufficient /lib/security/pam_radius_auth.so [options] >> ... >> account sufficient /lib/security/pam_radius_auth.so No further code inspection pam_sm_acct_mgmt() does nothing so I don't know why the documentation suggests that. Actually it is worse it return PAM_SUCCESS, I'll fix it to return PAM_IGNORE. > So what is it? > > BTW, on the upstream site I note somewhat contradicting (wrt the section > quoted by you) documentation, which mentions even more supported stacks: > > - There are several places that state that pam_radius_auth does support > password changing and how to configure it. Is this available in your > version? pam_sm_chauthtok() is implemented despite some parts of the "documentation" in the source tar file contradicting this. > - There is one place that mentions that pam_radius_auth contains > (Linux-only) session module support for RADIUS accounting. Is this > available (and can it be ported to Solaris)? The source I have (version 1.3.17) does have pam_sm_open_session() and pam_sm_close_session() are implemented but I don't see any thing Linux specific in there and the compiled module has those entry points. Given the above I'm updating the spec for this case as follows (a full new spec will be sent out): * rename module to pam_radius - since it does more than auth * Document that the auth, session, password stacks are all supported. * Change the source to return PAM_IGNORE for pam_sm_setcred and pam_sm_acct_mgmt since they do nothing - this will be #ifdef for Solaris and offered back upstream. Thank you very much for your input. -- Darren J Moffat From jhutz@cmu.edu Tue Apr 22 12:38:03 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3MJc2iK000387 for ; Tue, 22 Apr 2008 12:38:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3MJbv1I006932; Wed, 23 Apr 2008 03:38:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZQ00707RVBZV00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Apr 2008 12:37:59 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZQ00EK0RVA5RC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Apr 2008 12:37:58 -0700 (PDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MJbvav014513; Tue, 22 Apr 2008 19:37:57 +0000 (GMT) Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay16i.sun.com with ESMTP id BT-MMP-173241; Tue, 22 Apr 2008 19:37:57 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.sun.com with ESMTP id BT-MMP-6492593; Tue, 22 Apr 2008 19:37:56 +0000 (Z) Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16] [128.2.201.16]) by relay1i.sun.com with ESMTP id BT-MMP-3412255; Tue, 22 Apr 2008 19:37:56 +0000 (Z) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m3MJbnk3020936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2008 15:37:51 -0400 (EDT) Date: Tue, 22 Apr 2008 15:37:49 -0400 From: Jeffrey Hutzelman Subject: Re: RADIUS PAM module (pam_radius_auth) [PSARC/2008/269 FastTrack timeout 04/28/2008] In-reply-to: <480DB5CB.4090709@sun.com> To: =?UTF-8?Q?J=C3=B6rg_Barfurth?= , Darren J Moffat , PSARC-ext@sun.com, security-discuss@opensolaris.org Cc: jhutz@cmu.edu Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Linux/x86) Content-type: text/plain; charset=utf-8; format=flowed Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.087sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200804212106.m3LL6qUG019031@sac.sfbay.sun.com> <20080421213638.GN13552@Sun.COM> <480DB5CB.4090709@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id m3MJc2iK000387 Status: RO Content-Length: 3531 --On Tuesday, April 22, 2008 11:54:19 AM +0200 Jörg Barfurth wrote: >> I don't buy this "best compatibility" note. LinuxPAM fully supports >> PAM_IGNORE. True. > But it appears to have interactions between pam_authenticate processing > and pam_setcred processing not seen in Solaris PAM. The one I recall is > that modules not called during pam_authenticate processing (due to a > preceding 'sufficient' success) are not called during pam_setcred > processing, even if the 'sufficient' module returns PAM_IGNORE now. Correct. Linux-PAM calls exactly the same set of modules in pam_setcred as were called in pam_authenticate, in exactly the same order. The results do not affect the flow of control (with the possible exception of aborting the stack as for failure of a 'required' module; I don't remember). > Result is that pam_setcred fails because not a single PAM_SUCCESS return > has been seen in the shortened stack. Hrm. It seems to me that a module that returned PAM_SUCCESS in the pam_authenticate processing should probably not return PAM_IGNORE in setcred. Of course, Linux-PAM has configuration syntax that allows more or less arbitrary mapping from the module's return status to the action that is actually taken, so if this situation does occur, it is possible to work around. >> It is a bug to return PAM_SUCCESS when the module has done nothing, and >> it can lead to misconfigurations that are difficult for customers to >> debug, and even to misconfigurations that result in security holes. >> > > Due to the scenario described above, I have a module that returns > PAM_IGNORE from pam_sm_setcred on Solaris, but had to be tweaked to > return PAM_SUCCESS on Linux. It looks as if the pam_radius_auth > developer had the same issue. But I also agree that returning anything > but PAM_IGNORE on Solaris, which doesn't have that pam_setcred > processing wart, is a bug. Perhaps, but I don't think I buy it. In fact, as I understand it the _reason_ Linux-PAM has the aforementioned "wart" is to prevent problems due to results returned in pam_setcred processing being used for flow control. Note that the purpose of pam_setcred is to make the user's credentials available to whatever session is being started. It should never be the case that an unexpected successful return value from pam_setcred would "result in security holes", because the return value from pam_setcred should not be being used to make any security decisions. Once pam_setcred is called, the decision has already been made to let the user in. Nico wrote: > That's a problems on LinuxPAM. Let them provide a module that does the > right thing if need be. So, the upstream in question is FreeRADIUS, not Linux-PAM and not any particular Linux group. It is entirely reasonable for the FreeRADIUS people to want to maintain compatibility with as many PAM implementations as possible. It is unfortunate that the various PAM implementors have been unable to get together and agree on a common API (and no, there is not a common API, because an API is more than just a set of function signatures; it includes things like the disagreement over whether PAM applications should have to be privileged). However, that is not the fault of the maintainers of the module in question. For folks like the FreeRADIUS developers, or myself, maintaining cross-platform portability is much more important than adhering to any one OS vendor's vision of how the world ought to be. -- Jeff From Darren.Moffat@Sun.COM Wed May 7 13:10:36 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m47KAapB016216 for ; Wed, 7 May 2008 13:10:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m47KAZdF003891 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 7 May 2008 13:10:36 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K0I00901LDNZQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 07 May 2008 13:10:35 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K0I003C8LDM8H90@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 07 May 2008 13:10:35 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m47KAYGM014800 for ; Wed, 07 May 2008 20:10:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K0I00301LC87B00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 07 May 2008 21:10:34 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K0I00HSZLDM6K20@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 07 May 2008 21:10:34 +0100 (BST) Date: Wed, 07 May 2008 21:10:34 +0100 From: Darren J Moffat Subject: [closed approved] PSARC/2008/269 RADIUS PAM module (pam_radius_auth) Sender: Darren.Moffat@Sun.COM To: PSARC-EXT@Sun.COM Message-id: <48220CBA.7000500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080408) Status: RO Content-Length: 159 This case has timed out with no unresolved issues and is now closed approved. A final spec will be placed in the case directory shortly. -- Darren J Moffat