From sacadmin Mon Nov 10 13:36:39 2003 Date: Mon, 10 Nov 2003 13:31:49 -0800 (PST) From: Darren J Moffat To: psarc@Sun.COM cc: Joep Vesseur , Satish Murugesan Subject: PSARC/2003/674 pam_list module MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 6874 I'm submitting this case for myself. The timer is set to expire 2003-11-17. A man page for the module is included in the materials subdir. 1. Background ------------- Customers have (ab)used the passwd compat functionality of nsswitch for years. It is typically used it to restrict which users can login to a given host, while still allowing the host to be part of the same name service domain as others. Often this is done on mail and home directory (NFS) servers that users aren't allowed to run interactive jobs on but their uid's need to be known for authentication and/or quotas etc. If you have complex netgroups and use them with passwd compat mode then there can be a noticeable and significant delay on every getpw*() call. This is due to the need to walk the netgroup to find the user, this is made worse because netgroups are not cached by nscd (but that is a story for another day). Further more there are now two customer escalations (P2) open requesting we fix this performance problem when netgroups are used with passwd compat. The source code for an example PAM module it is included in an InfoDoc in SunSolve and I know that it has been given to several customers. I occasionally get emails from people in SunService thanking me since it helped them close a customer call where there was complaint about the performance on netgroups and passwd compat. I've recently done some data mining on the pam.conf files that are held in the US customer explorer database and confirmed that my module or ones that sound very like it are being used by several customers. 2. Proposal ----------- Introduce a new PAM module called pam_list.so. This module only implements pam_sm_acct_mgmt(3pam) and determines wither or not to return success or failure based on the value of PAM_USER/PAM_RHOST and its configuration. The configuration of the module is all done via arguments to the module specified in pam.conf. The reason for this rather than a single config file is to allow the module to be used differently depending on which service stack it is in (or even to be listed multiple times in the same stack with a different config). There is one mandatory argument, one of either: allow= or deny= must be specified otherwise the module returns PAM_SYSTEM_ERR (since it isn't configured properly). The contents of the file are a list of usernames and/or netgroups, where netgroups begin with the '@' symbol. If allow= is specified then a exact match of PAM_USER in the file will cause the module to return PAM_SUCCESS. If the user is not found then PAM_PERM_DENIED is returned. If deny= is specified then a exact match of PAM_USER in the file will cause the module to return PAM_PERM_DENIED and if the user is not found then PAM_SUCCESS is returned. Since there are several different methodologies used by our customers for building netgroups the module needs to be flexible to how the customer has configured the netgroup tuples. The following optional config options can change the behavior of how the innetgr() call is made: user Just match the user. nouser Don't match the user. host Just match the host. nohost Don't match the host. user_host_exact User and host must match in the same netgroup. They are used in the code as follows: if (user_host_exact) { if (innetgr(netgroup, rhost, username, NULL) == 1) { found++; } } else { userok = hostok = 0; if (user) { userok = innetgr(netgroup, NULL, username, NULL) == 1; } else { userok = 1; } if (host) { hostok = innetgr(netgroup, rhost, NULL, NULL); } else { hostok = 1; } if (userok && hostok) { found++; } } This allows the following different netgroup styles: bar (hosta, usera, -) bar (hosta, -, - ) bar (- , usera, - ) bar ( , usera, ) bar (hosta, , ) it also allows control over the users location if need be. rhost in the above is the contents of PAM_RHOST if it is set. If PAM_RHOST is not set then we use the hostname of the local machine as rhost if host checking is turned on. The module wouldn't be configured for any service by default, nor would it be in the pam.conf commented out for any service, as such there are no updates to the i.pamconf class action script included in this project. This is deliberately a file on the local host rather than something held in LDAP against the user or host. There are other means for restricting authentication when pam_ldap is used, these based on the capabilities of the LDAP server and are sometimes specific to a given LDAP server. 3. allow/deny file format ------------------------- The comment char for this file is '#'. Comments are only complete lines, in-line comments are not supported. Each line in the file is either a username or a netgroup. Netgroups begin with the '@' char otherwise it is assumed to be a host. 4. Examples ----------- 4.1 Only non role admin users can login to local devices login account requisite pam_roles.so.1 login account requisite pam_list.so.1 allow=/etc/local/admins login account required pam_unix_account.so.1 4.2 Admin uses don't need to do Kerberos when using ktelnet and remote is a a trusted host, other users do. ktelnet account requisite pam_roles.so.1 ktelnet account sufficient pam_list.so.1 allow=/etc/thostad user_host_exact ktelnet account binding pam_krb5.so.1 ktelnet account required pam_unix_account.so.1 4.3 Ban a certain users from this host regardless of where they come from and how they got here. other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_list.so.1 deny=/etc/banned-users nohost 5. Interface/Release Taxonomy ----------------------------- Exported Interfaces +-----------------------------------------------------------------+ | /usr/lib/security/$ISA/pam_list.so.1 | | | functionality & arguments | Evolving | +---------------------------------------------+-------------------+ | allow/deny file format | Stable | +---------------------------------------------+-------------------+ Release binding is micro/patch. I believe this is suitable for inclusion in a feature patch since it is self contained and does not modify any existing parts of the system on install or as part of its implementation. 6. Supporting Materials ----------------------- materials/pam_list.5 4294674 Restrict logins using netgroups without using passwd_compat mode in NSS -- Darren J Moffat From sacadmin Mon Nov 10 14:12:11 2003 Date: Mon, 10 Nov 2003 14:08:45 -0800 (PST) From: Ralph Campbell Subject: Re: PSARC/2003/674 pam_list module To: psarc@sun.com Cc: Darren.Moffat@sun.com, Joep.Vesseur@sun.com, Satish.Murugesan@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pY/SuN9DCO5NqbUdb+EizQ== Content-Length: 7674 Is this the same or upwardly compatible with the module you send out informally? Is there any notification that would be needed for those customers how to upgrade? > Date: Mon, 10 Nov 2003 13:31:49 -0800 (PST) > From: Darren J Moffat > To: psarc@sun.com > cc: Joep Vesseur , Satish Murugesan > Subject: PSARC/2003/674 pam_list module > MIME-Version: 1.0 > > I'm submitting this case for myself. The timer is set to expire 2003-11-17. > A man page for the module is included in the materials subdir. > > 1. Background > ------------- > Customers have (ab)used the passwd compat functionality of nsswitch for > years. It is typically used it to restrict which users can login to a > given host, while still allowing the host to be part of the same > name service domain as others. Often this is done on mail and home > directory (NFS) servers that users aren't allowed to run interactive > jobs on but their uid's need to be known for authentication and/or > quotas etc. > > If you have complex netgroups and use them with passwd compat mode then > there can be a noticeable and significant delay on every getpw*() call. > This is due to the need to walk the netgroup to find the user, this is > made worse because netgroups are not cached by nscd (but that is a > story for another day). Further more there are now two customer > escalations (P2) open requesting we fix this performance problem when > netgroups are used with passwd compat. > > The source code for an example PAM module it is included in an InfoDoc > in SunSolve and I know that it has been given to several customers. I > occasionally get emails from people in SunService thanking me since it > helped them close a customer call where there was complaint about > the performance on netgroups and passwd compat. > > I've recently done some data mining on the pam.conf files that are held > in the US customer explorer database and confirmed that my module or > ones that sound very like it are being used by several customers. > > > 2. Proposal > ----------- > > Introduce a new PAM module called pam_list.so. This module only > implements pam_sm_acct_mgmt(3pam) and determines wither or not to return > success or failure based on the value of PAM_USER/PAM_RHOST and its > configuration. > > The configuration of the module is all done via arguments to the module > specified in pam.conf. The reason for this rather than a single config file > is to allow the module to be used differently depending on which > service stack it is in (or even to be listed multiple times in the same > stack with a different config). > > There is one mandatory argument, one of either: allow= or deny= > must be specified otherwise the module returns PAM_SYSTEM_ERR (since it > isn't configured properly). > > The contents of the file are a list of usernames and/or netgroups, where > netgroups begin with the '@' symbol. > > If allow= is specified then a exact match of PAM_USER in the file will > cause the module to return PAM_SUCCESS. If the user is not found then > PAM_PERM_DENIED is returned. > > If deny= is specified then a exact match of PAM_USER in the file will > cause the module to return PAM_PERM_DENIED and if the user is not found > then PAM_SUCCESS is returned. > > Since there are several different methodologies used by our customers for > building netgroups the module needs to be flexible to how the customer has > configured the netgroup tuples. The following optional config options > can change the behavior of how the innetgr() call is made: > > user Just match the user. > nouser Don't match the user. > host Just match the host. > nohost Don't match the host. > user_host_exact User and host must match in the same netgroup. > > They are used in the code as follows: > > if (user_host_exact) { > if (innetgr(netgroup, > rhost, username, NULL) == 1) { > found++; > } > } else { > userok = hostok = 0; > if (user) { > userok = innetgr(netgroup, NULL, username, NULL) == 1; > } else { > userok = 1; > } > if (host) { > hostok = innetgr(netgroup, rhost, NULL, NULL); > } else { > hostok = 1; > } > if (userok && hostok) { > found++; > } > } > > This allows the following different netgroup styles: > > bar (hosta, usera, -) > bar (hosta, -, - ) > bar (- , usera, - ) > bar ( , usera, ) > bar (hosta, , ) > > it also allows control over the users location if need be. rhost in the > above is the contents of PAM_RHOST if it is set. If PAM_RHOST is not set > then we use the hostname of the local machine as rhost if host checking is > turned on. > > The module wouldn't be configured for any service by default, nor would > it be in the pam.conf commented out for any service, as such there > are no updates to the i.pamconf class action script included in this > project. > > This is deliberately a file on the local host rather than something > held in LDAP against the user or host. There are other means for > restricting authentication when pam_ldap is used, these based on the > capabilities of the LDAP server and are sometimes specific to a given > LDAP server. > > > 3. allow/deny file format > ------------------------- > > The comment char for this file is '#'. Comments are only complete > lines, in-line comments are not supported. > > Each line in the file is either a username or a netgroup. Netgroups > begin with the '@' char otherwise it is assumed to be a host. > > > 4. Examples > ----------- > > 4.1 Only non role admin users can login to local devices > > login account requisite pam_roles.so.1 > login account requisite pam_list.so.1 allow=/etc/local/admins > login account required pam_unix_account.so.1 > > 4.2 Admin uses don't need to do Kerberos when using ktelnet and remote is a > a trusted host, other users do. > > ktelnet account requisite pam_roles.so.1 > ktelnet account sufficient pam_list.so.1 allow=/etc/thostad user_host_exact > ktelnet account binding pam_krb5.so.1 > ktelnet account required pam_unix_account.so.1 > > 4.3 Ban a certain users from this host regardless of where they come > from and how they got here. > > other account requisite pam_roles.so.1 > other account required pam_unix_account.so.1 > other account required pam_list.so.1 deny=/etc/banned-users nohost > > > 5. Interface/Release Taxonomy > ----------------------------- > > > Exported Interfaces > > +-----------------------------------------------------------------+ > | /usr/lib/security/$ISA/pam_list.so.1 | | > | functionality & arguments | Evolving | > +---------------------------------------------+-------------------+ > | allow/deny file format | Stable | > +---------------------------------------------+-------------------+ > > Release binding is micro/patch. I believe this is suitable for inclusion > in a feature patch since it is self contained and does not modify any > existing parts of the system on install or as part of its implementation. > > 6. Supporting Materials > ----------------------- > > materials/pam_list.5 > > 4294674 Restrict logins using netgroups without using passwd_compat mode in NSS > > -- > Darren J Moffat From sacadmin Mon Nov 10 14:22:36 2003 Date: Mon, 10 Nov 2003 14:17:45 -0800 (PST) From: Darren J Moffat To: Ralph Campbell cc: psarc@Sun.COM, Joep.Vesseur@Sun.COM, Satish.Murugesan@Sun.COM Subject: Re: PSARC/2003/674 pam_list module MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 8403 On Mon, 10 Nov 2003, Ralph Campbell wrote: > Is this the same or upwardly compatible with the module you send out > informally? Is there any notification that would be needed for those > customers how to upgrade? It is exactly the same functionality, the arguments to the module are the same as the example version. We can't automatically upgrade customers since we don't know where they installed the module or what they called it (if they choose to name the file something different - it was shipped in source not object code). > > Date: Mon, 10 Nov 2003 13:31:49 -0800 (PST) > > From: Darren J Moffat > > To: psarc@sun.com > > cc: Joep Vesseur , Satish Murugesan > > > Subject: PSARC/2003/674 pam_list module > > MIME-Version: 1.0 > > > > I'm submitting this case for myself. The timer is set to expire 2003-11-17. > > A man page for the module is included in the materials subdir. > > > > 1. Background > > ------------- > > Customers have (ab)used the passwd compat functionality of nsswitch for > > years. It is typically used it to restrict which users can login to a > > given host, while still allowing the host to be part of the same > > name service domain as others. Often this is done on mail and home > > directory (NFS) servers that users aren't allowed to run interactive > > jobs on but their uid's need to be known for authentication and/or > > quotas etc. > > > > If you have complex netgroups and use them with passwd compat mode then > > there can be a noticeable and significant delay on every getpw*() call. > > This is due to the need to walk the netgroup to find the user, this is > > made worse because netgroups are not cached by nscd (but that is a > > story for another day). Further more there are now two customer > > escalations (P2) open requesting we fix this performance problem when > > netgroups are used with passwd compat. > > > > The source code for an example PAM module it is included in an InfoDoc > > in SunSolve and I know that it has been given to several customers. I > > occasionally get emails from people in SunService thanking me since it > > helped them close a customer call where there was complaint about > > the performance on netgroups and passwd compat. > > > > I've recently done some data mining on the pam.conf files that are held > > in the US customer explorer database and confirmed that my module or > > ones that sound very like it are being used by several customers. > > > > > > 2. Proposal > > ----------- > > > > Introduce a new PAM module called pam_list.so. This module only > > implements pam_sm_acct_mgmt(3pam) and determines wither or not to return > > success or failure based on the value of PAM_USER/PAM_RHOST and its > > configuration. > > > > The configuration of the module is all done via arguments to the module > > specified in pam.conf. The reason for this rather than a single config file > > is to allow the module to be used differently depending on which > > service stack it is in (or even to be listed multiple times in the same > > stack with a different config). > > > > There is one mandatory argument, one of either: allow= or deny= > > must be specified otherwise the module returns PAM_SYSTEM_ERR (since it > > isn't configured properly). > > > > The contents of the file are a list of usernames and/or netgroups, where > > netgroups begin with the '@' symbol. > > > > If allow= is specified then a exact match of PAM_USER in the file will > > cause the module to return PAM_SUCCESS. If the user is not found then > > PAM_PERM_DENIED is returned. > > > > If deny= is specified then a exact match of PAM_USER in the file will > > cause the module to return PAM_PERM_DENIED and if the user is not found > > then PAM_SUCCESS is returned. > > > > Since there are several different methodologies used by our customers for > > building netgroups the module needs to be flexible to how the customer has > > configured the netgroup tuples. The following optional config options > > can change the behavior of how the innetgr() call is made: > > > > user Just match the user. > > nouser Don't match the user. > > host Just match the host. > > nohost Don't match the host. > > user_host_exact User and host must match in the same netgroup. > > > > They are used in the code as follows: > > > > if (user_host_exact) { > > if (innetgr(netgroup, > > rhost, username, NULL) == 1) { > > found++; > > } > > } else { > > userok = hostok = 0; > > if (user) { > > userok = innetgr(netgroup, NULL, username, NULL) == 1; > > } else { > > userok = 1; > > } > > if (host) { > > hostok = innetgr(netgroup, rhost, NULL, NULL); > > } else { > > hostok = 1; > > } > > if (userok && hostok) { > > found++; > > } > > } > > > > This allows the following different netgroup styles: > > > > bar (hosta, usera, -) > > bar (hosta, -, - ) > > bar (- , usera, - ) > > bar ( , usera, ) > > bar (hosta, , ) > > > > it also allows control over the users location if need be. rhost in the > > above is the contents of PAM_RHOST if it is set. If PAM_RHOST is not set > > then we use the hostname of the local machine as rhost if host checking is > > turned on. > > > > The module wouldn't be configured for any service by default, nor would > > it be in the pam.conf commented out for any service, as such there > > are no updates to the i.pamconf class action script included in this > > project. > > > > This is deliberately a file on the local host rather than something > > held in LDAP against the user or host. There are other means for > > restricting authentication when pam_ldap is used, these based on the > > capabilities of the LDAP server and are sometimes specific to a given > > LDAP server. > > > > > > 3. allow/deny file format > > ------------------------- > > > > The comment char for this file is '#'. Comments are only complete > > lines, in-line comments are not supported. > > > > Each line in the file is either a username or a netgroup. Netgroups > > begin with the '@' char otherwise it is assumed to be a host. > > > > > > 4. Examples > > ----------- > > > > 4.1 Only non role admin users can login to local devices > > > > login account requisite pam_roles.so.1 > > login account requisite pam_list.so.1 allow=/etc/local/admins > > login account required pam_unix_account.so.1 > > > > 4.2 Admin uses don't need to do Kerberos when using ktelnet and remote is a > > a trusted host, other users do. > > > > ktelnet account requisite pam_roles.so.1 > > ktelnet account sufficient pam_list.so.1 allow=/etc/thostad > user_host_exact > > ktelnet account binding pam_krb5.so.1 > > ktelnet account required pam_unix_account.so.1 > > > > 4.3 Ban a certain users from this host regardless of where they come > > from and how they got here. > > > > other account requisite pam_roles.so.1 > > other account required pam_unix_account.so.1 > > other account required pam_list.so.1 deny=/etc/banned-users > nohost > > > > > > 5. Interface/Release Taxonomy > > ----------------------------- > > > > > > Exported Interfaces > > > > +-----------------------------------------------------------------+ > > | /usr/lib/security/$ISA/pam_list.so.1 | | > > | functionality & arguments | Evolving | > > +---------------------------------------------+-------------------+ > > | allow/deny file format | Stable | > > +---------------------------------------------+-------------------+ > > > > Release binding is micro/patch. I believe this is suitable for inclusion > > in a feature patch since it is self contained and does not modify any > > existing parts of the system on install or as part of its implementation. > > > > 6. Supporting Materials > > ----------------------- > > > > materials/pam_list.5 > > > > 4294674 Restrict logins using netgroups without using passwd_compat mode in > NSS > > > > -- > > Darren J Moffat > -- Darren J Moffat From sacadmin Tue Nov 11 17:24:09 2003 Date: Tue, 11 Nov 2003 17:21:24 -0800 (PST) From: Darren J Moffat To: psarc@Sun.COM Subject: Re: PSARC/2003/674 pam_list module (fwd) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 679 Forwarding an offline discussion. Glenn is correct this was a typo in the spec (which I've corrected now in the proposal file) the allow/deny file contains netgroups or usernames never hosts. ---------- Forwarded message ---------- Date: Mon, 10 Nov 2003 16:55:16 -0500 From: "Glenn M. Brunette, Jr." To: Darren J Moffat Subject: Re: PSARC/2003/674 pam_list module Darren, Thank you! Thank you! Thank you! Two questions: Darren J Moffat wrote: > Each line in the file is either a username or a netgroup. Netgroups > begin with the '@' char otherwise it is assumed to be a host. Shouldn't this be a "user" not a "host"? From sacadmin Tue Nov 11 20:11:23 2003 Date: Tue, 11 Nov 2003 23:04:54 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren J Moffat CC: psarc@sun.com, Joep Vesseur , Satish Murugesan Subject: Re: PSARC/2003/674 pam_list module Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1225 > > >4. Examples >----------- > >4.1 Only non role admin users can login to local devices > >login account requisite pam_roles.so.1 >login account requisite pam_list.so.1 allow=/etc/local/admins >login account required pam_unix_account.so.1 > >4.2 Admin uses don't need to do Kerberos when using ktelnet and remote is a >a trusted host, other users do. > >ktelnet account requisite pam_roles.so.1 >ktelnet account sufficient pam_list.so.1 allow=/etc/thostad user_host_exact >ktelnet account binding pam_krb5.so.1 >ktelnet account required pam_unix_account.so.1 > > 'ktelnet' is only used by the Kerberized telnet daemon in which case the PAM calls are not made until well after the "native" kerberos authentication has already occurred. If the telnet daemon did NOT authenticate with Kerberos, the pam service name is the standard "telnet". This would make more sense as an example if s/ktelnet/telnet/ -wyllys >4.3 Ban a certain users from this host regardless of where they come >from and how they got here. > >other account requisite pam_roles.so.1 >other account required pam_unix_account.so.1 >other account required pam_list.so.1 deny=/etc/banned-users nohost > > > > From sacadmin Wed Nov 12 10:00:52 2003 Date: Wed, 12 Nov 2003 09:55:58 -0800 (PST) From: Darren J Moffat To: Wyllys Ingersoll cc: psarc@Sun.COM, Joep Vesseur , Satish Murugesan Subject: Re: PSARC/2003/674 pam_list module MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 822 On Tue, 11 Nov 2003, Wyllys Ingersoll wrote: > >ktelnet account requisite pam_roles.so.1 > >ktelnet account sufficient pam_list.so.1 allow=/etc/thostad user_host_exact > >ktelnet account binding pam_krb5.so.1 > >ktelnet account required pam_unix_account.so.1 > > > > 'ktelnet' is only used by the Kerberized telnet daemon in which case the > PAM > calls are not made until well after the "native" kerberos authentication > has already > occurred. If the telnet daemon did NOT authenticate with Kerberos, the > pam service name is the standard "telnet". > This would make more sense as an example if s/ktelnet/telnet/ or s/sufficient/requisite/ s/binding/required/ and it makes sense again. ...but it is only an example. Do you have any issue with the module functionality or just the example ? -- Darren J Moffat From sacadmin Wed Nov 12 10:51:18 2003 Date: Wed, 12 Nov 2003 13:44:48 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren J Moffat CC: psarc@sun.com Subject: Re: PSARC/2003/674 pam_list module Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 968 Darren J Moffat wrote: >On Tue, 11 Nov 2003, Wyllys Ingersoll wrote: > > > >>>ktelnet account requisite pam_roles.so.1 >>>ktelnet account sufficient pam_list.so.1 allow=/etc/thostad user_host_exact >>>ktelnet account binding pam_krb5.so.1 >>>ktelnet account required pam_unix_account.so.1 >>> >>> >>> >>'ktelnet' is only used by the Kerberized telnet daemon in which case the >>PAM >>calls are not made until well after the "native" kerberos authentication >>has already >>occurred. If the telnet daemon did NOT authenticate with Kerberos, the >>pam service name is the standard "telnet". >> >> > > > >>This would make more sense as an example if s/ktelnet/telnet/ >> >> > >or s/sufficient/requisite/ s/binding/required/ and it makes sense again. > >...but it is only an example. > >Do you have any issue with the module functionality or just the example ? > > I quite like the proposal, the example is all that I have issue with. -Wyllys From sacadmin Mon Nov 17 15:51:22 2003 Date: Mon, 17 Nov 2003 15:45:35 -0800 (PST) From: Gary Winiger To: psarc@sun.com, Darren.Moffat@sun.com Subject: Re: PSARC/2003/674 pam_list module Cc: Joep.Vesseur@sun.com, Satish.Murugesan@sun.com Content-Length: 2082 > 1. Background > ------------- > Customers have (ab)used the passwd compat functionality of nsswitch for > years. It is typically used it to restrict which users can login to a > given host, while still allowing the host to be part of the same > name service domain as others. Often this is done on mail and home > directory (NFS) servers that users aren't allowed to run interactive > jobs on but their uid's need to be known for authentication and/or > quotas etc. > > If you have complex netgroups and use them with passwd compat mode then > there can be a noticeable and significant delay on every getpw*() call. > This is due to the need to walk the netgroup to find the user, this is > made worse because netgroups are not cached by nscd (but that is a > story for another day). Further more there are now two customer > escalations (P2) open requesting we fix this performance problem when > netgroups are used with passwd compat. I guess I'm ignorant here. It seems to me that the real issue is the netgroups lookup in the (ab)used passwd compat case. It seems to me that solving the performance problem would rather than adding a new interface would be the solution. I'm concerned that this case request not only to add an new administrative interface (the allow= | deny= ) path, but that it also requires activating that interface separately from configuring it. I'm concerned that this is a new ``stable'' Solaris interface for which vi is the only administrative interface. This proposal also seems to use netgroups. Why doesn't it have similar performance problems? > I've recently done some data mining on the pam.conf files that are held > in the US customer explorer database and confirmed that my module or > ones that sound very like it are being used by several customers. I have no issue with this or any other pam service module a customer may wish to obtain and use. My issues are making it a part of Solaris (for the reasons above). If indeed it is so useful, it seems like an ideal thing to include on the companion CD. Gary.. From sacadmin Mon Nov 17 16:12:01 2003 Date: Mon, 17 Nov 2003 16:08:01 -0800 (PST) From: Darren J Moffat To: Gary Winiger cc: psarc@Sun.COM, , Subject: Re: PSARC/2003/674 pam_list module MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 3527 On Mon, 17 Nov 2003, Gary Winiger wrote: > > If you have complex netgroups and use them with passwd compat mode then > > there can be a noticeable and significant delay on every getpw*() call. > > This is due to the need to walk the netgroup to find the user, this is > > made worse because netgroups are not cached by nscd (but that is a > > story for another day). Further more there are now two customer > > escalations (P2) open requesting we fix this performance problem when > > netgroups are used with passwd compat. > > I guess I'm ignorant here. It seems to me that the real issue > is the netgroups lookup in the (ab)used passwd compat case. > It seems to me that solving the performance problem would rather > than adding a new interface would be the solution. It is part of it but not the whole picture. The real problem is the abuse of passwd compat to change the users login shell to be something that means they can't get a login session (ie /bin/false) to mean that the user shouldn't login to this machine. This addresses both the functional abuse: PAM should be used to determine if a user can or can not login NOT what their shell happens to be AND the knock on performance problem when this is done with netgroups. I initally wrote this for the functional case (for my own amusment), it turns out that it also solves a performance problem because of the way that customers have been abusing passwd compat to achive what pam_acct_mgmt should be doing. > I'm concerned that this case request not only to add an new > administrative interface (the allow= | deny= ) path, but that It is the interface that our customers want and need. > it also requires activating that interface separately from > configuring it. I don't understand this comment in this context. Also isn't this the part of the goals we want to get to ? ie Install, Configuration and Activation are all separate and distinct steps, so this would be a good thing IMO. > I'm concerned that this is a new ``stable'' > Solaris interface for which vi is the only administrative > interface. I can mark it Evolving or Unstable if it makes you feel better but I doubt it ever will change, it is effectively the same interface that ftpusers and cron.{allow.deny} have been using for users, ie a file containing usernames. This is the interface the customers want (I have SunPS and SunService contacts can testify to this if need be). > This proposal also seems to use netgroups. Why doesn't it > have similar performance problems? Because the innetgr() call is only done at pam_acct_mgmt() time not on EVERY getpw*() call. > > I've recently done some data mining on the pam.conf files that are held > > in the US customer explorer database and confirmed that my module or > > ones that sound very like it are being used by several customers. > > I have no issue with this or any other pam service module a > customer may wish to obtain and use. My issues are making > it a part of Solaris (for the reasons above). If indeed it > is so useful, it seems like an ideal thing to include on the > companion CD. IMO Sun should NEVER put stuff we write on the the companion CD that is NOT what it is for. We are effectively in this position today because the code is on SunSolve. We have some very very important customers who really want this as a SUPPORTED PART OF THE OS in this form. [ Satish can provide the buisness justification for this if needed, which is why he was cc'd on this case ] -- Darren J Moffat From sacadmin Wed Nov 19 09:51:53 2003 Date: Wed, 19 Nov 2003 09:46:01 -0800 (PST) From: Gary Winiger To: gww@marduk.eng.sun.com, Darren.Moffat@sun.com Subject: Re: PSARC/2003/674 pam_list module Cc: psarc@sun.com, Joep.Vesseur@sun.com, Satish.Murugesan@sun.com Content-Length: 4069 > On Mon, 17 Nov 2003, Gary Winiger wrote: I'd wanted to chat off line with the project team, but timing seems to proclude that until later. > It is part of it but not the whole picture. The real problem is the > abuse of passwd compat to change the users login shell to be something > that means they can't get a login session (ie /bin/false) to mean that > the user shouldn't login to this machine. Again I seem to be missing something. It doesn't seem to me that this proposal does anything to alleviate that practice. Things such as user_attr(4), policy.conf(4) entries seem more in line with Solaris direction, but still won't alleviate the use of netgroups, compat, and /bin/false. They may provide an alternative. > > I'm concerned that this case request not only to add an new > > administrative interface (the allow= | deny= ) path, but that > > It is the interface that our customers want and need. Customers also want (and maybe need) some real management interfaces. IMO adding more local files that require administration with vi just makes whatever efforts for unifying management interfaces harder, more complex, and disperse. > > it also requires activating that interface separately from > > configuring it. > > I don't understand this comment in this context. Also isn't this the > part of the goals we want to get to ? ie Install, Configuration and > Activation are all separate and distinct steps, so this would be a good > thing IMO. I wasn't clear. ABICT, the proposal is to add some local files as well as have to modify pam.conf not only to include pam_list, but also to configure it. Thus the admin has multiple interfaces that have to be dealt with and kept in sync. This adds complexity to administration rather than reducing it. It seemed one of the desires of this case was to reduce the complexity of achieving the to block certain users (or members of netgroups) from logging into a particular Solaris instance while allowing them to have active passwords for other purposes on that same Solaris instance. I don't see that adding additional vi steps makes things simpler. > > I'm concerned that this is a new ``stable'' > > Solaris interface for which vi is the only administrative > > interface. > > I can mark it Evolving or Unstable if it makes you feel better but I > doubt it ever will change, it is effectively the same interface that > ftpusers and cron.{allow.deny} have been using for users, ie a file > containing usernames. At least for cron, these files could be eliminated altogether. cron supports authorizations. The same could/should be done for ftpusers. (I'm not sure that GreenLine would deal with ftpusers.) > This is the interface the customers want (I have SunPS and SunService > contacts can testify to this if need be). They also want sudo. Why don't we ship sudo as part of ON? (IMO, because it was judged as not fitting the administrative direction of Solaris.) > > This proposal also seems to use netgroups. Why doesn't it > > have similar performance problems? > > Because the innetgr() call is only done at pam_acct_mgmt() time not > on EVERY getpw*() call. I'm ignorant here. pam_list would access innetgr() to function but getpw*() wouldn't? > > > I've recently done some data mining on the pam.conf files that are held > > > in the US customer explorer database and confirmed that my module or > > > ones that sound very like it are being used by several customers. > > > > I have no issue with this or any other pam service module a > > customer may wish to obtain and use. My issues are making > > it a part of Solaris (for the reasons above). If indeed it > > is so useful, it seems like an ideal thing to include on the > > companion CD. > > IMO Sun should NEVER put stuff we write on the the companion CD that is NOT Why not? Or are you saying that everything that is written at Sun must be delivered out of the WOS? I don't think that's true or provides value to the customers, of course, I could be wrong. Gary.. From sacadmin Mon Nov 24 09:08:24 2003 Date: Mon, 24 Nov 2003 09:03:08 -0800 (PST) From: Darren J Moffat To: psarc@Sun.COM cc: Joep Vesseur , Satish.Murugesan@Sun.COM Subject: PSARC/2003/674 waiting need spec MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 303 I'm puting this case into "waiting need spec". After some offline discussions with some other engineers we have come up with a cleaner configuration interface that should address the concerns that Gary has. I'll restart the case with a 1 week timer when the new spec is available. -- Darren J Moffat From Darren.Moffat@sun.com Fri Feb 23 05:10:20 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1NDAKwg013998 for ; Fri, 23 Feb 2007 05:10:20 -0800 (PST) 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 l1NDAJA4022958 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 23 Feb 2007 05:10:20 -0800 (PST) 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 <0JDX00F0B397TC00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 05:10:19 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JDX000CZ396R2D0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 05:10:18 -0800 (PST) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1NDAHrJ018371 for ; Fri, 23 Feb 2007 13:10:17 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDX00A0135T5300@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 13:10:17 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDX00DWE390V700@d1-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 13:10:17 +0000 (GMT) Date: Fri, 23 Feb 2007 13:10:11 +0000 From: Darren J Moffat Subject: PSARC/2003/674 [restart] pam_list module Sender: Darren.Moffat@sun.com To: psarc-ext@sun.com Cc: Satish.Murugesan@sun.com, security-discuss@opensolaris.org Message-id: <45DEE7B3.2030708@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_9iPXuNeH3NfUnxNzWT2wDA)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 10442 This is a multi-part message in MIME format. --Boundary_(ID_9iPXuNeH3NfUnxNzWT2wDA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I'm restarting this case since there are several very large and important customers requesting we include it in the default Solaris install. Time out is set for Friday 2nd March 2007. Note there is purposely no management GUI or CLI for this, the customers requesting this are used to using the similar module on Linux and BSD based systems and want to distribute a flat ASCII file. There is a very minor change to the original spec to allow a configuration that some customers have been using already: namely using /etc/passwd as the source of allow/deny users/netgroups rather than an additional file, if neither allow= or deny= are specified. This is because they already have management tools that can deploy +/- syntax as used in nsswitch compat mode to that file. The current spec is in the case directory as proposal.txt and the updated pam_list(5) man page is in the materials directory. Both are attached here as well. -- Darren J Moffat --Boundary_(ID_9iPXuNeH3NfUnxNzWT2wDA) Content-type: text/plain; name=pam_list.5 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pam_list.5 Standards, Environments, and Macros pam_list(5) NAME pam_list - PAM account management module for UNIX SYNOPSIS pam_list.so.1 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. 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. If neither of the allow or deny options are specified then the module will look for +/- entries in the local /etc/passwd file. If this style is used then nsswitch.conf(4) must not be configured with compat for the passwd database. The following options can be passed to the module: allow= The full pathname to a file of allowed users and/or netgroups. Only one of allow= or deny= may be specified. deny= The full pathaname to a file of denied users and/or netgroups. Only one of deny= or allow= may be specified. user The module should only perform netgroup matches on the username. nouser The username should not be used in the netgroup match. host Only the host should be used in netgroup matches. nohost The hostname should not be used in netgroup matches. user_host_exact The user and hostname must be in the same netgroup. ERRORS The following values are returned: PAM_SERVICE_ERR An invalid set of module options was given in the pam.conf(4) for this module, or the user/netgroup file could not be opened. PAM_BUF_ERR Memory buffer error PAM_IGNORE Ignore module, not participating in result PAM_PERM_DENIED The user is not on the allow list or is on the den list. PAM_SUCCESS The account is valid for use at this time PAM_USER_UNKNOWN No account is present for the user ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| | MT Level | MT-Safe with exceptions | |_____________________________|_____________________________| SEE ALSO pam(3PAM), pam_authenticate(3PAM), syslog(3C), libpam(3LIB), pam.conf(4), nsswitch.conf(4), attributes(5), NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. --Boundary_(ID_9iPXuNeH3NfUnxNzWT2wDA) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=proposal.txt 1. Background ------------- Customers have (ab)used the passwd compat functionality of nsswitch for years. It is typically used it to restrict which users can login to a given host, while still allowing the host to be part of the same name service domain as others. Often this is done on mail and home directory (NFS) servers that users aren't allowed to run interactive jobs on but their uid's need to be known for authentication and/or quotas etc. If you have complex netgroups and use them with passwd compat mode then there can be a noticeable and significant delay on every getpw*() call. This is due to the need to walk the netgroup to find the user, this is made worse because netgroups are not cached by nscd (but that is a story for another day). The source code for an example PAM module it is included in an InfoDoc on SunSolve and in the OpenSolaris security community.I know that it has been given to several customers. I occasionally get emails from people in SunService thanking me since it helped them close a customer call where there was complaint about the performance on netgroups and passwd compat. I've recently done some data mining on the pam.conf files that are held in the US customer explorer database and confirmed that my module or ones that sound very like it are being used by several customers. A similar module exists on most Linux distributions. 2. Proposal ----------- Introduce a new PAM module called pam_list.so. This module only implements pam_sm_acct_mgmt(3pam) and determines wither or not to return success or failure based on the value of PAM_USER/PAM_RHOST and its configuration. The configuration of the module is all done via arguments to the module specified in pam.conf. The reason for this rather than a single config file is to allow the module to be used differently depending on which service stack it is in (or even to be listed multiple times in the same stack with a different config). Either one of: allow= or deny= can be specified. If neither is specified then the module parses the local /etc/passwd file looking for +/- entries and uses those instead of a separate file. The contents of the file are a list of usernames and/or netgroups, where netgroups begin with the '@' symbol. If allow= is specified then a exact match of PAM_USER in the file will cause the module to return PAM_SUCCESS. If the user is not found then PAM_PERM_DENIED is returned. If deny= is specified then a exact match of PAM_USER in the file will cause the module to return PAM_PERM_DENIED and if the user is not found then PAM_SUCCESS is returned. Since there are several different methodologies used by our customers for building netgroups the module needs to be flexible to how the customer has configured the netgroup tuples. The following optional config options can change the behavior of how the innetgr() call is made: user - Just match the user. nouser - Don't match the user. host - Just match the host. nohost - Don't match the host. user_host_exact - User and host must match in the same netgroup. This allows the following different netgroup styles: bar (hosta, usera, -) bar (hosta, -, - ) bar (- , usera, - ) bar ( , usera, ) bar (hosta, , ) it also allows control over the users location if need be. rhost in the above is the contents of PAM_RHOST if it is set. If PAM_RHOST is not set then we use the hostname of the local machine as rhost if host checking is turned on. The module will not be configured for any service by default, nor would it be in the pam.conf commented out for any service, as such there are no updates to the i.pamconf class action script included in this project. This is deliberately a file on the local host rather than something held in LDAP against the user or host. There are other means for restricting authentication when pam_ldap is used, these based on the capabilities of the LDAP server and are sometimes specific to a given LDAP server. There is also purposely no admin command, the customers requesting this functionality want a raw file as that is what they already use on Linux or on Solaris with the existing open source module. 3. allow/deny file format ------------------------- The comment char for this file is '#'. Comments are only complete lines, in-line comments are not supported. Each line in the file is either a username or a netgroup. Netgroups begin with the '@' char otherwise it is assumed to be a username. 4. Examples ----------- 4.1 Only non role admin users can login to local devices login account requisite pam_roles.so.1 login account requisite pam_list.so.1 allow=/etc/local/admins login account required pam_unix_account.so.1 4.2 Admin uses don't need to do Kerberos when using ktelnet and remote is a a trusted host, other users do. ktelnet account requisite pam_roles.so.1 ktelnet account sufficient pam_list.so.1 allow=/etc/thostad user_host_exact ktelnet account binding pam_krb5.so.1 ktelnet account required pam_unix_account.so.1 4.3 Ban a certain users from this host regardless of where they come from and how they got here. other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_list.so.1 deny=/etc/banned-users nohost 5. Interface/Release Taxonomy ----------------------------- Exported Interfaces +-----------------------------------------------------------------+ | /usr/lib/security/$ISA/pam_list.so.1 | | | functionality & arguments | Commited | +---------------------------------------------+-------------------+ | allow/deny file format | Commited | +---------------------------------------------+-------------------+ Release binding is micro/patch. 6. Supporting Materials ----------------------- materials/pam_list.5 4294674 Restrict logins using netgroups without using passwd_compat mode in NSS --Boundary_(ID_9iPXuNeH3NfUnxNzWT2wDA)-- From carlsonj@phorcys.east.sun.com Fri Feb 23 06:31:54 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1NEVraT015139 for ; Fri, 23 Feb 2007 06:31:53 -0800 (PST) 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 l1NEVoEY012228; Fri, 23 Feb 2007 07:31:51 -0700 (MST) 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 <0JDX0060P712H800@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Feb 2007 06:31:50 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JDX00HR0710ZV60@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Feb 2007 06:31:48 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l1NEVlDQ016143; Fri, 23 Feb 2007 09:31:47 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l1NEVl7n016140; Fri, 23 Feb 2007 09:31:47 -0500 (EST) Date: Fri, 23 Feb 2007 09:31:47 -0500 From: James Carlson Subject: Re: [security-discuss] PSARC/2003/674 [restart] pam_list module In-reply-to: <45DEE7B3.2030708@Sun.COM> To: Darren J Moffat Cc: psarc-ext@sun.com, security-discuss@opensolaris.org, Satish.Murugesan@sun.com Message-id: <17886.64211.248152.186999@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45DEE7B3.2030708@Sun.COM> Status: RO Content-Length: 545 Darren J Moffat writes: > I've recently done some data mining on the pam.conf files that are held > in the US customer explorer database and confirmed that my module or > ones that sound very like it are being used by several customers. Do we need a release note to let these customers know about the new functionality? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@Sun.COM Fri Feb 23 06:39:33 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1NEdXnB015181 for ; Fri, 23 Feb 2007 06:39:33 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l1NEdVZN020911 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 23 Feb 2007 14:39:32 GMT 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 <0JDX007057DVJA00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 06:39:31 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JDX00H9E7DUZW50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 06:39:31 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1NEdTZP001120 for ; Fri, 23 Feb 2007 14:39:29 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDX00D017BHL400@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 14:39:29 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDX00F7U7DQO010@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 23 Feb 2007 14:39:29 +0000 (GMT) Date: Fri, 23 Feb 2007 14:39:25 +0000 From: Darren J Moffat Subject: Re: [security-discuss] PSARC/2003/674 [restart] pam_list module In-reply-to: <17886.64211.248152.186999@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: psarc-ext@Sun.COM, security-discuss@opensolaris.org, Satish.Murugesan@Sun.COM Message-id: <45DEFC9D.7080706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45DEE7B3.2030708@Sun.COM> <17886.64211.248152.186999@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 415 James Carlson wrote: > Darren J Moffat writes: >> I've recently done some data mining on the pam.conf files that are held >> in the US customer explorer database and confirmed that my module or >> ones that sound very like it are being used by several customers. > > Do we need a release note to let these customers know about the new > functionality? Seems reasonable, consider it included. -- Darren J Moffat From gww@eng.sun.com Tue Feb 27 13:19:20 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1RLJJUf023512 for ; Tue, 27 Feb 2007 13:19:19 -0800 (PST) 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 l1RLJJ2u025416 for <@sunmail1brm.central.sun.com:psarc-ext@sun.com>; Tue, 27 Feb 2007 13:19:19 -0800 (PST) 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 <0JE5009074K6DA00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 27 Feb 2007 14:19:19 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE5000D54K51U40@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 27 Feb 2007 14:19:17 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l1RLHagb020707; Tue, 27 Feb 2007 13:17:36 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l1RLGrMU010094; Tue, 27 Feb 2007 13:16:53 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l1RLGrdk010093; Tue, 27 Feb 2007 13:16:53 -0800 (PST) Date: Tue, 27 Feb 2007 13:16:53 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2003/674 [restart] pam_list module To: Darren.Moffat@sun.com, psarc-ext@sun.com Cc: Satish.Murugesan@sun.com, security-discuss@opensolaris.org Message-id: <200702272116.l1RLGrdk010093@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3004 > The current spec is in the case directory as proposal.txt and the > updated pam_list(5) man page is in the materials directory. Both are > attached here as well. I wouldn't say I have an objection to this proposal, just a couple questions and nits: > SYNOPSIS > pam_list.so.1 > DESCRIPTION > The following options can be passed to the module: > > allow= > The full pathname to a file of allowed users and/or netgroups. > Only one of allow= or deny= may be specified. > > deny= > The full pathaname to a file of denied users and/or netgroups. > Only one of deny= or allow= may be specified. > > user > The module should only perform netgroup matches on the username. > > nouser > The username should not be used in the netgroup match. > > host > Only the host should be used in netgroup matches. > > nohost > The hostname should not be used in netgroup matches. > > user_host_exact > The user and hostname must be in the same netgroup. I believe an EXAMPLES section with the examples in the proposal would help here. > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > ____________________________________________________________ > | ATTRIBUTE TYPE | ATTRIBUTE VALUE | > |_____________________________|_____________________________| > | Interface Stability | Evolving | ^^^^^^^^ Committed > 1. Background > ------------- > If you have complex netgroups and use them with passwd compat mode then > there can be a noticeable and significant delay on every getpw*() call. > This is due to the need to walk the netgroup to find the user, this is > made worse because netgroups are not cached by nscd (but that is a > story for another day). Is this project still needed? Sparks is planned for the next update release of S10. Shouldn't it handle the performance issues noted here? > 2. Proposal > ----------- > This is deliberately a file on the local host rather than something > held in LDAP against the user or host. There are other means for > restricting authentication when pam_ldap is used, these based on the > capabilities of the LDAP server and are sometimes specific to a given > LDAP server. I'm confused with what point is being made. LDAP is a name service and can serve up name service requests such as getpwent(), getnetrent(), ... pam_ldap(5) is a PAM service module that coerces an LDAP style directory service into an account authority. But you know that, thus my confusion. > There is also purposely no admin command, the customers requesting > this functionality want a raw file as that is what they already use > on Linux or on Solaris with the existing open source module. IMO, this is an excuse for not providing a properly auditable administrative interface and not a reason. > 4. Examples > ----------- See above re man page. Gary.. From satishk@sun.com Tue Feb 27 13:58:06 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1RLw6kO025143 for ; Tue, 27 Feb 2007 13:58:06 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l1RLw58T006426 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 27 Feb 2007 13:58:06 -0800 (PST) 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 <0JE500G056CTHC00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 27 Feb 2007 13:58:05 -0800 (PST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE500ABO6CTTI50@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 27 Feb 2007 13:58:05 -0800 (PST) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1RLw5oP016726 for ; Tue, 27 Feb 2007 13:58:05 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE50030168M6Z00@d1-sfbay-09.sun.com> (original mail from satishk@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 27 Feb 2007 13:58:05 -0800 (PST) Received: from [129.150.19.26] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE5006C06CS7CKD@d1-sfbay-09.sun.com>; Tue, 27 Feb 2007 13:58:05 -0800 (PST) Date: Tue, 27 Feb 2007 13:58:04 -0800 From: Satish Murugesan Subject: Re: PSARC/2003/674 [restart] pam_list module In-reply-to: <200702272116.l1RLGrdk010093@marduk.eng.sun.com> Sender: Satish.Murugesan@sun.com To: Gary Winiger Cc: Darren.Moffat@sun.com, psarc-ext@sun.com, Satish.Murugesan@sun.com, security-discuss@opensolaris.org Message-id: <45E4A96C.9080001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200702272116.l1RLGrdk010093@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) Status: RO Content-Length: 1010 Gary Winiger wrote: > >> If you have complex netgroups and use them with passwd compat mode then >> there can be a noticeable and significant delay on every getpw*() call. >> This is due to the need to walk the netgroup to find the user, this is >> made worse because netgroups are not cached by nscd (but that is a >> story for another day). >> > > Is this project still needed? Sparks is planned for the next > update release of S10. Shouldn't it handle the performance > issues noted here? > No, Sparks will not fully address the performance issues. Netgroups are not cached by nscd even with Sparks. The performance is also worsened when nsswitch compat mode is used. The proposed pam_list module in this ARC case avoids hitting the above 2 botttle necks. I received requests from customers like Citigroup, Google and Barclay Capital to get pam_list officially in Solaris. Its actually a Solaris 10 adoption issue for Citigroup and Google. thanks, Satish From sacadmin Tue Feb 27 15:49:59 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1RNnxQ1000120 for ; Tue, 27 Feb 2007 15:49:59 -0800 (PST) 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 l1RNnu3v034872; Tue, 27 Feb 2007 16:49:58 -0700 (MST) 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 <0JE500M1DBJ9AL00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Feb 2007 15:49:57 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE500K4VBJ8VY10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Feb 2007 15:49:56 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l1RNnstU024584; Tue, 27 Feb 2007 15:49:54 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l1RNnCj1010526; Tue, 27 Feb 2007 15:49:12 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l1RNnBlA010525; Tue, 27 Feb 2007 15:49:11 -0800 (PST) Date: Tue, 27 Feb 2007 15:49:11 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2003/674 [restart] pam_list module To: gww@eng.sun.com, satishk@Sun.COM Cc: Darren.Moffat@Sun.COM, psarc@Sun.COM, Satish.Murugesan@Sun.COM Message-id: <200702272349.l1RNnBlA010525@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1454 [Took psarc-ext and and security discuss off Satish, why is it OK to discuss named customers in the open? If indeed it is determined that's OK, please reforward to the open aliases.] > > Is this project still needed? Sparks is planned for the next > > update release of S10. Shouldn't it handle the performance > > issues noted here? > > > > No, Sparks will not fully address the performance issues. Netgroups > are not cached by nscd even > with Sparks. The performance is also worsened when nsswitch compat > mode is used. Hummm, I thought Sparks was going to cache most all lookups except things like shadow. Oh well. > The proposed pam_list module in this ARC case avoids hitting the > above 2 botttle necks. > > I received requests from customers like Citigroup, Google and Barclay > Capital to get pam_list officially > in Solaris. Its actually a Solaris 10 adoption issue for Citigroup > and Google. And what are they doing now? At least Citi is running Solaris on many of it's machines. I guess the point to be made here is that most of my discussions with Citi (and in the past with folk from Barclay in the UK) were that they wanted administrative audit and centralized name services to distribute most (all) configuration. This case provides neither and asserts that neither are needed/desired by the CUs. That seems at odds with what I've had representatives from Citi tell me. Gary.. From Darren.Moffat@sun.com Wed Feb 28 05:30:50 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1SDUmvZ018275 for ; Wed, 28 Feb 2007 05:30:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l1SDUed7027628 for <@sunmail1brm.central.sun.com:psarc-ext@sun.com>; Wed, 28 Feb 2007 21:30:47 +0800 (SGT) 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 <0JE600E05DJBNU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 28 Feb 2007 06:30:47 -0700 (MST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE60056KDJAGH80@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 28 Feb 2007 06:30:47 -0700 (MST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1SDUjmU010615 for ; Wed, 28 Feb 2007 13:30:45 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE600001D9BXJ00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 28 Feb 2007 13:30:45 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE6002FVDJ5C730@d1-emea-09.sun.com>; Wed, 28 Feb 2007 13:30:42 +0000 (GMT) Date: Wed, 28 Feb 2007 13:30:41 +0000 From: Darren J Moffat Subject: Re: PSARC/2003/674 [restart] pam_list module In-reply-to: <200702272116.l1RLGrdk010093@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, Satish.Murugesan@sun.com, security-discuss@opensolaris.org Message-id: <45E58401.1010507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200702272116.l1RLGrdk010093@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 3168 Gary Winiger wrote: > I believe an EXAMPLES section with the examples in the > proposal would help here. I'll make sure the project team delivers the man page like that. >> ATTRIBUTES >> See attributes(5) for descriptions of the following attri- >> butes: >> >> ____________________________________________________________ >> | ATTRIBUTE TYPE | ATTRIBUTE VALUE | >> |_____________________________|_____________________________| >> | Interface Stability | Evolving | > ^^^^^^^^ > Committed >> 1. Background >> ------------- > >> If you have complex netgroups and use them with passwd compat mode then >> there can be a noticeable and significant delay on every getpw*() call. >> This is due to the need to walk the netgroup to find the user, this is >> made worse because netgroups are not cached by nscd (but that is a >> story for another day). > > Is this project still needed? Sparks is planned for the next > update release of S10. Shouldn't it handle the performance > issues noted here? Yes because this isn't just about the performance problem but also about using the proper interface for access to the system, ie PAM not abusing the nameservice. >> 2. Proposal >> ----------- > >> This is deliberately a file on the local host rather than something >> held in LDAP against the user or host. There are other means for >> restricting authentication when pam_ldap is used, these based on the >> capabilities of the LDAP server and are sometimes specific to a given >> LDAP server. > > I'm confused with what point is being made. LDAP is a name > service and can serve up name service requests such as > getpwent(), getnetrent(), ... pam_ldap(5) is a PAM service > module that coerces an LDAP style directory service into > an account authority. > But you know that, thus my confusion. PAM is what should be used to control access to a given system, this case provides a module to do that with the data stored in a local file. If you are using pam_ldap your directory server may give you a way to achieve a similar result. This is LDAP the Account Authority. For LDAP the nameservice using the compat syntax provided by nsswtich is an abuse since one should be using PAM to control access to the system - that way the correct entries get written in the audit log, ie permission denied rather than account not found or worse authencation was okay but the shell is /bin/false. >> There is also purposely no admin command, the customers requesting >> this functionality want a raw file as that is what they already use >> on Linux or on Solaris with the existing open source module. > > IMO, this is an excuse for not providing a properly auditable > administrative interface and not a reason. I disagree, we are giving the customers what they want and what they need. I agree it doesn't provide an easily audited admin interface but the funding just isn't there to provide that capability and we really can't hold of providing this simple module any longer our customers are already really really annoyed it has taken us so long to do so. -- Darren J Moffat From mgerdts@gmail.com Wed Feb 28 06:37:24 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1SEbMTe020257 for ; Wed, 28 Feb 2007 06:37:23 -0800 (PST) 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 l1SEbBiO019409 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 28 Feb 2007 22:37:21 +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 <0JE600J0NGM7T500@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 28 Feb 2007 06:37:19 -0800 (PST) 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 <0JE600GQTGM77710@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 28 Feb 2007 06:37:19 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l1SDanGp013693 for ; Wed, 28 Feb 2007 14:37:19 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay44i.sun.com with ESMTP for psarc-ext@sun.com; Wed, 28 Feb 2007 14:37:18 +0000 (Z) Received: from relay41i.sun.com ([192.5.209.70] [192.5.209.70]) by mms48es.sun.com with ESMTP for psarc-ext@sun.com; Wed, 28 Feb 2007 14:37:18 +0000 (Z) Received: from an-out-0708.google.com ([209.85.132.251] [209.85.132.251]) by relay4i.sun.com with ESMTP for psarc-ext@sun.com; Wed, 28 Feb 2007 14:37:18 +0000 (Z) Received: by an-out-0708.google.com with SMTP id c2so119959anc for ; Wed, 28 Feb 2007 06:37:18 -0800 (PST) Received: by 10.115.77.1 with SMTP id e1mr823110wal.1172673428485; Wed, 28 Feb 2007 06:37:08 -0800 (PST) Received: by 10.114.12.20 with HTTP; Wed, 28 Feb 2007 06:37:08 -0800 (PST) Date: Wed, 28 Feb 2007 08:37:08 -0600 From: Mike Gerdts Subject: Re: [security-discuss] PSARC/2003/674 [restart] pam_list module In-reply-to: <45DEE7B3.2030708@Sun.COM> To: Darren J Moffat Cc: psarc-ext@sun.com, security-discuss@opensolaris.org, Satish.Murugesan@sun.com Message-id: <65f8f3ad0702280637q1b9fb7eck96c7e2428ca45453@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K/PmIdTlCtd2xrojty8nJih4VziaYlsNh58Mt/Qbz8MArHxrZ7seRoB8wa3q0G+0XEhDkF+dZaQga5HnBB88EXrfy9NjhPSviNahRdR5mTZjnUFBUM0o6Fe4laJRrBFfM40omlcj6/9KbQyXcs1niiQSeEgilOYnEUSiJ6bHbpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s1b+oHJjXq6yjd4bAW/9AWL6ztVT2RT40T0nEs9DPeVTt5K9TGoKkHwZM8zAm8DRvxPnkuFrAiAPJ49UQjFnjlfWOK2FHXJmPWAxv8bHK/tqDrJ8sqTbAN8PBgiWlHQWadfOuPfViszKch+PLHbyJmO0J7DDj6iutDHTExi2lvU= X-PMX-Version: 5.2.0.264296 References: <45DEE7B3.2030708@Sun.COM> Status: RO Content-Length: 1862 On 2/23/07, Darren J Moffat 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)? 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? > user_host_exact > The user and hostname must be in the same netgroup. Could this also mean user@host? For the few cases where I need telnet/ftp/rsh enabled, it is not worth the trouble of a netgroup. user@host would make the administration much easier. 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: pamtest -m acct_mgmt -s service -r remote_host -u user The pamtest program could be useful beyond the scope of this module. This module will be extremely useful. Thanks! Mike -- Mike Gerdts http://mgerdts.blogspot.com/ From Darren.Moffat@sun.com Wed Feb 28 07:55:40 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1SFtdVK021929 for ; Wed, 28 Feb 2007 07:55:40 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l1SFtYTi019022 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Wed, 28 Feb 2007 15:55:39 GMT 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 <0JE600715K8OPM00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 07:55:36 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE6005NOK8MQQ10@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 07:55:35 -0800 (PST) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1SFtYab005698 for ; Wed, 28 Feb 2007 15:55:34 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE600401K7WTM00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 15:55:34 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE600GTWK8JYZ10@d1-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 15:55:32 +0000 (GMT) Date: Wed, 28 Feb 2007 15:55:31 +0000 From: Darren J Moffat Subject: Re: [security-discuss] PSARC/2003/674 [restart] pam_list module In-reply-to: <65f8f3ad0702280637q1b9fb7eck96c7e2428ca45453@mail.gmail.com> Sender: Darren.Moffat@sun.com To: Mike Gerdts Cc: psarc-ext@sun.com, security-discuss@opensolaris.org, Satish.Murugesan@sun.com Message-id: <45E5A5F3.5060705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45DEE7B3.2030708@Sun.COM> <65f8f3ad0702280637q1b9fb7eck96c7e2428ca45453@mail.gmail.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 2047 Mike Gerdts wrote: > On 2/23/07, Darren J Moffat 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@host? For the few cases where I need > telnet/ftp/rsh enabled, it is not worth the trouble of a netgroup. > user@host would make the administration much easier. We will consider user@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 From gww@eng.sun.com Wed Feb 28 09:46:04 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1SHk2ce025607 for ; Wed, 28 Feb 2007 09:46:03 -0800 (PST) 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 l1SHjlBK021312 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@Sun.COM>; Thu, 1 Mar 2007 01:46:01 +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 <0JE600E01PCPUK00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 09:46:01 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE6005KVPCOQK90@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 09:46:00 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l1SHjxfm024106; Wed, 28 Feb 2007 09:45:59 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l1SHjFEZ012264; Wed, 28 Feb 2007 09:45:15 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l1SHjFvx012263; Wed, 28 Feb 2007 09:45:15 -0800 (PST) Date: Wed, 28 Feb 2007 09:45:15 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2003/674 [restart] pam_list module To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: psarc-ext@sun.com, Satish.Murugesan@sun.com, security-discuss@opensolaris.org Message-id: <200702281745.l1SHjFvx012263@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1980 > >> 2. Proposal > >> ----------- > > > >> This is deliberately a file on the local host rather than something > >> held in LDAP against the user or host. There are other means for > >> restricting authentication when pam_ldap is used, these based on the > >> capabilities of the LDAP server and are sometimes specific to a given > >> LDAP server. > > > > I'm confused with what point is being made. LDAP is a name > > service and can serve up name service requests such as > > getpwent(), getnetrent(), ... pam_ldap(5) is a PAM service > > module that coerces an LDAP style directory service into > > an account authority. > > But you know that, thus my confusion. > > PAM is what should be used to control access to a given system, this > case provides a module to do that with the data stored in a local file. I agree with PAM account management being the correct control point. This part of my comment was more about conflagration with pam_ldap that I wasn't sure of your point. More below. > >> There is also purposely no admin command, the customers requesting > >> this functionality want a raw file as that is what they already use > >> on Linux or on Solaris with the existing open source module. > > > > IMO, this is an excuse for not providing a properly auditable > > administrative interface and not a reason. > > I disagree, we are giving the customers what they want and what they > need. I agree it doesn't provide an easily audited admin interface but > the funding just isn't there to provide that capability and we really > can't hold of providing this simple module any longer our customers are > already really really annoyed it has taken us so long to do so. Not saying the CU be damned, but just the opposite. IMO, as I believe I stated this 3.5 years ago when this started, this project is kludge/bandaid for lack of a proper architecture. I'm saddened that such an architecture doesn't seem to be forthcoming. Gary.. From Darren.Moffat@Sun.COM Wed Feb 28 09:59:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1SHxceG026183 for ; Wed, 28 Feb 2007 09:59:39 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l1SHxXWg001498 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Wed, 28 Feb 2007 17:59:37 GMT 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 <0JE600F05PZBTN00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 09:59:35 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE6005XFPZAQP80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 09:59:35 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1SHxXVg021814 for ; Wed, 28 Feb 2007 17:59:33 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE600501PYGJT00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 17:59:33 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE6002W5PZ7C750@d1-emea-09.sun.com>; Wed, 28 Feb 2007 17:59:32 +0000 (GMT) Date: Wed, 28 Feb 2007 17:59:31 +0000 From: Darren J Moffat Subject: Re: PSARC/2003/674 [restart] pam_list module In-reply-to: <200702281745.l1SHjFvx012263@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: psarc-ext@Sun.COM, Satish.Murugesan@Sun.COM, security-discuss@opensolaris.org Message-id: <45E5C303.6050602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200702281745.l1SHjFvx012263@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1689 Gary Winiger wrote: >>>> There is also purposely no admin command, the customers requesting >>>> this functionality want a raw file as that is what they already use >>>> on Linux or on Solaris with the existing open source module. >>> IMO, this is an excuse for not providing a properly auditable >>> administrative interface and not a reason. >> I disagree, we are giving the customers what they want and what they >> need. I agree it doesn't provide an easily audited admin interface but >> the funding just isn't there to provide that capability and we really >> can't hold of providing this simple module any longer our customers are >> already really really annoyed it has taken us so long to do so. > > Not saying the CU be damned, but just the opposite. IMO, as > I believe I stated this 3.5 years ago when this started, this > project is kludge/bandaid for lack of a proper architecture. > I'm saddened that such an architecture doesn't seem to be > forthcoming. and it is exactly because the is no better alternative that I restarted this case. This is a perfectly acceptable solution for many people. I've love to see something better with centralised (but still allowing very fine grained policy) in fact we used to have such a thing when Sun resold the BoKS product as Solstice Security Manager (and on Solaris 2.6 it even used PAM!). Feel free to derail this case for the purpose of writing an opinion to point out that there are still a number of areas where Solaris doesn't have sufficient account access controls and that a centralised management tool for this is needed as well. I'll gladly provide fodder for that opinion. -- Darren J Moffat From jhutz@cmu.edu Wed Feb 28 10:15:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1SIFpXc027331 for ; Wed, 28 Feb 2007 10:15:52 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l1SIFm21007907; Wed, 28 Feb 2007 18:15:49 GMT 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 <0JE600H0BQQ94U00@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Feb 2007 10:15:45 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE60052AQQ8QQA0@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Feb 2007 10:15:45 -0800 (PST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1SIFivl020823; Wed, 28 Feb 2007 18:15:44 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay22.sun.com with ESMTP; Wed, 28 Feb 2007 18:15:43 +0000 (Z) Received: from mms23bas.mms.us.syntegra.com (mms23bas.mms.us.syntegra.com [192.12.251.50]) by mms24es.sun.com with ESMTP id BT-MMP-2071119; Wed, 28 Feb 2007 18:15:43 +0000 (Z) Received: from currant.srv.cs.cmu.edu ([128.2.194.193] [128.2.194.193]) by relay23.sun.com with ESMTP; Wed, 28 Feb 2007 18:15:43 +0000 (Z) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l1SIFdkT015956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Feb 2007 13:15:40 -0500 (EST) Date: Wed, 28 Feb 2007 13:15:39 -0500 From: Jeffrey Hutzelman Subject: Re: [security-discuss] Re: PSARC/2003/674 [restart] pam_list module In-reply-to: <200702281745.l1SHjFvx012263@marduk.eng.sun.com> Originator-info: login-token=Mulberry:01Onzgx6TkVTuGx1hIbfoQNtHuF/LBsFmn8Q4scPw=; token_authority=postmaster@andrew.cmu.edu To: Gary Winiger , Darren.Moffat@sun.com Cc: psarc-ext@sun.com, Satish.Murugesan@sun.com, security-discuss@opensolaris.org, Jeffrey Hutzelman Message-id: <1F0767552E0B0A347A38A628@sirius.fac.cs.cmu.edu> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200702281745.l1SHjFvx012263@marduk.eng.sun.com> Status: RO Content-Length: 1834 On Wednesday, February 28, 2007 09:45:15 AM -0800 Gary Winiger wrote: > Not saying the CU be damned, but just the opposite. IMO, as > I believe I stated this 3.5 years ago when this started, this > project is kludge/bandaid for lack of a proper architecture. > I'm saddened that such an architecture doesn't seem to be > forthcoming. Part of the issue is that not all customers want a "proper architecture" with complex databases that can only be updated by running obscure, platform-dependent programs. Some of us maintain large numbers of machines (1000+ in my case; orders of magnitude more for some of the customers mentioned), and we mostly do it using portable tools that maintain the contents of the filesystem. The master repository says what the system must look like, and the tool makes it so. Every time you introduce a database which can only be updated through some new interface, I have to write a helper program that attempts to use that interface to compare the current contents of the database to what my repository says should be there, and make the required changes. Installing a new inetd.conf and sending a SIGHUP is way easier than trying to update smf. And no, the conversion program Sun provides doesn't help here, because it doesn't recognize when it needs to _delete_ a service that's not in the input file. Just to make it more fun, several of the services that ship with Solaris use different names than those which would be used by the inetd.conf converter, for no apparent reason. So, while I likely won't be using the authorization mechanism currently under discussion, if I did, I'd want it to work exactly as described - let me provide a file which describes what needs to be done. Changes to that file are logged and audited elsewhere. -- Jeff From gww@eng.sun.com Wed Feb 28 20:20:39 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l214KdpV017305 for ; Wed, 28 Feb 2007 20:20:39 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l214KcSU012622 for <@sunmail1brm.central.sun.com:psarc-ext@Sun.COM>; Wed, 28 Feb 2007 20:20:39 -0800 (PST) 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 <0JE700M0BIQEF100@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 21:20:38 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JE7005PFIQC8K70@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 28 Feb 2007 21:20:36 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l214KY4x027675; Wed, 28 Feb 2007 20:20:34 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l214Jnmx013624; Wed, 28 Feb 2007 20:19:49 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l214Jn6r013623; Wed, 28 Feb 2007 20:19:49 -0800 (PST) Date: Wed, 28 Feb 2007 20:19:49 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2003/674 [restart] pam_list module To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: psarc-ext@sun.com, Satish.Murugesan@sun.com, security-discuss@opensolaris.org Message-id: <200703010419.l214Jn6r013623@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1281 > > Not saying the CU be damned, but just the opposite. IMO, as > > I believe I stated this 3.5 years ago when this started, this > > project is kludge/bandaid for lack of a proper architecture. > > I'm saddened that such an architecture doesn't seem to be > > forthcoming. > > and it is exactly because the is no better alternative that I restarted > this case. This is a perfectly acceptable solution for many people. > I've love to see something better with centralised (but still allowing > very fine grained policy) in fact we used to have such a thing when Sun > resold the BoKS product as Solstice Security Manager (and on Solaris 2.6 > it even used PAM!). Yup, I remember it. Unfortunately it's long gone. We can lament it over a couple whiskies later this summer. > Feel free to derail this case for the purpose of writing an opinion to > point out that there are still a number of areas where Solaris doesn't > have sufficient account access controls and that a centralised > management tool for this is needed as well. I'll gladly provide fodder > for that opinion. No need. There are enough folk who are well aware. And we keep making them aware at every opportunity. Gary.. P.S. approved at today's PSARC -- hope you're well on the mend. From sacadmin Wed Mar 14 09:42:09 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2EGg9XT004417 for ; Wed, 14 Mar 2007 09:42:09 -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 l2EGg2mD047260 for <@sunmail3mpk.sfbay.sun.com:psarc@sun.com>; Wed, 14 Mar 2007 10:42:08 -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 <0JEW0090TJQ79O00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 14 Mar 2007 09:42:07 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JEW003D6JQ6IZF0@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 14 Mar 2007 09:42:06 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2EGg6Ur011485 for ; Wed, 14 Mar 2007 08:42:06 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEW00001JMV8000@d1-sfbay-10.sun.com> (original mail from Sherri.Shieh@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Wed, 14 Mar 2007 09:42:06 -0700 (PDT) Received: from [129.145.154.88] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEW00M89JQ4D7WI@d1-sfbay-10.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 14 Mar 2007 09:42:05 -0700 (PDT) Date: Wed, 14 Mar 2007 09:42:04 -0700 From: Sherri Shieh Subject: PSARC Fast Track: pam_list module (2003/674) Sender: Sherri.Shieh@sun.com To: psarc@sun.com, Darren Moffat Cc: Satish.Murugesan@sun.com Message-id: <45F825DC.2050103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 350 This case was approved two weeks ago - I have marked this case closed approved. - Sherri -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: 650-786-5245/x85245 ===========================================================