From Darren.Moffat@sun.com Tue Jan 8 03:11:01 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08BB1MB010117 for ; Tue, 8 Jan 2008 03:11:01 -0800 (PST) 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 m08BB07H000568 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 8 Jan 2008 04:11:00 -0700 (MST) 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 <0JUB00D2XOECCI00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Tue, 08 Jan 2008 03:11:00 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUB00BYBOEB3Z90@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Tue, 08 Jan 2008 03:11:00 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m08BAwm4026780 for ; Tue, 08 Jan 2008 11:10:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUB00L01NL9J800@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 08 Jan 2008 11:10:58 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUB00F2DOD34310@fe-emea-10.sun.com>; Tue, 08 Jan 2008 11:10:15 +0000 (GMT) Date: Tue, 08 Jan 2008 11:10:15 +0000 From: Darren J Moffat Subject: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com Cc: kmf-discuss@opensolaris.org, Huie-Ying Lee Message-id: <47835A17.6070704@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Jd02/VZDN+Peik3NlfGcDw)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 6266 This is a multi-part message in MIME format. --Boundary_(ID_Jd02/VZDN+Peik3NlfGcDw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I'm sponsoring this case for Huie-Ying Lee of the OpenSolaris KMF project. I'm using this old case number as other ARC cases reference this case number as a requirement for EOF removal of some old smartcard functionality. The timer is set for Wednesday 16th January 2008. Release binding is patch. The module pathname and configuration files are Committed. All other visible interfaces (such as config file syntax) are Volatile at this time. Man pages and other supporting material is in the materials subdir of the case. -- Darren J Moffat --Boundary_(ID_Jd02/VZDN+Peik3NlfGcDw) Content-type: text/plain; name=pam_pkcs11.psarc_summary Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pam_pkcs11.psarc_summary ========================================== The pam_pkcs11 module overview ========================================== The pam_pkcs11 module is a PAM authentication module for PKCS#11 token libraries. This module allows a user to login a system that supports PAM, using a certificate and its dedicated private key stored in a PKCS#11 token. This pam_pkcs11 module supports any PKCS#11 token library, however, it is typically used by a Smart-card PKCS#11 token. The original source of this module is provided by opensc-project.org. The latest version is 0.6.0 which supports only the authentication service. It does not support pam_setcred, pam_acct_mgmt, or other services. For more information, see http://www.opensc-project.org/pam_pkcs11 ========================================================= The pam_pkcs11 authentication/verification procedure ========================================================= The authentication and verification procedure is as following: Step 1: Find all certificate/private_key pair in the PKCS#11 token Step 2: Find the certificate/private_key pair that matches the user For each pair of the certificate and its associated private key Validate the certificate by using the CA certificate and CRL files. If the certificate is valid, then check if it matches the user by using the mappers based on the pam_pkcs11 configuration. If a good pair is found, we are done Step 3: Verification procedure To verify the private key on the token is truly associated with the certificate, this module performs the following verification procedure. - Generates 128 random byte data. - Use the private key to sign the data and get a signature. (This will be done in the PKCS11 token). - Extract the public key from the certificate and verify the signature. ========================================== Deliverables: ========================================== Pam_pkcs11 module: /usr/lib/security/pam_pkcs11.so (Note: will support both 32bit and 64 bit versions.) Non-built-in Mapper modules: /usr/lib/pam_pkcs11/ldap_mapper.so /usr/lib/pam_pkcs11/opensc_mapper.so /usr/lib/pam_pkcs11/openssh_mapper.so (Note: will support both 32bit and 64 bit versions.) Configuration directories and files: /etc/security/pam_pkcs11/pam_pkcs11.conf /etc/security/pam_pkcs11/pkcs11_eventmgr.conf /etc/security/pam_pkcs11/cacerts (The directory to store the CA certificates) /etc/security/pam_pkcs11/crls (The directory to store the CRL files) Sample Mapfiles and script: /etc/security/pam_pkcs11/digest_mapping.example /etc/security/pam_pkcs11/subject_mapping.example /etc/security/pam_pkcs11/mail_mapping.example /etc/security/pam_pkcs11/make_hash_link.sh Utility commands: /usr/lib/pam_pkcs11/pkcs11_inspect /usr/lib/pam_pkcs11/pklogin_finder /usr/lib/pam_pkcs11/pkcs11_eventmgr (Note: will support both 32bit and 64bit versions.) man pages: /usr/share/man/man5/pam_pkcs11.5.sunman /usr/share/man/man1/pklogin_finder.1 /usr/share/man/man1/pkcs11_eventmgr.1 /usr/share/man/man1/pkcs11_inspect.1 ================================================== A usage example: ================================================== Setup: - Add the pam_pkcs11.so module to the /etc/pam.conf file as below: login auth sufficient pam_pkcs11.so - Create a self-signed certificate in the Solaris Softtoken keystore, using the "pktool gencert" command. - Export the certificate file from the Solaris Softtoken keystore, using the "pktool export" command. - Copy the CA certificate to the /etc/security/pam_pkcs11/cacerts directory and make a hash link with the make_hash_link.sh script. Note: A certificate that is self-signed is its own CA certificate. Therefore, in this example, the certificate is placed both in the keystore and in the CA certificate directory. - Set up the map files in the /etc/security/pam_pkc11 directory. Note: When a X509 certificate is provided, there are no direct ways to map a certificate to a login. The pam_pkcs11 module provides a configurable way with mappers to specify cert-to-user mapping. Many mappers are provided by Pam_pkcs11, for example, the common name (CN) mapper, the digest mapper, the Email mapper, or the LDAP mapper. A user can configure a mapper list in the pam_pkcs11.conf file. The mappers in the list will be used sequentially until the certificate is successfully matched with the user. Some mappers do not require a mapfile to be specified (eg. the CN mapper), while some other mappers do require a mapfile (eg. the digest mapper) in the /etc/pam_pkcs11 directory. Run: ------------------------------------------------------------------------ hylee@bula$exec login Please insert your smart card or enter your username. login: hylee Smart card inserted. Welcome Sun Metaslot! Smart card password: XXXXXX Last login: Wed Sep 12 15:10:29 from comforter Sun Microsystems Inc. SunOS 5.11 snv_65 October 2007 ------------------------------------------------------------------------ Note that the "Smart card password" is the Solaris softtoken keystore password. --Boundary_(ID_Jd02/VZDN+Peik3NlfGcDw)-- From Jan.Pechanec@sun.com Tue Jan 8 04:02:04 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08C245w010688 for ; Tue, 8 Jan 2008 04:02:04 -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 m08C249b023716 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 8 Jan 2008 04:02:04 -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 <0JUB00H0FQRE6500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 04:02:02 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUB00755QRCTZ50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 04:02:01 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m08C20r2022141 for ; Tue, 08 Jan 2008 12:02:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUB00B01Q95P900@fe-emea-09.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 12:02:00 +0000 (GMT) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUB00HKEQR17720@fe-emea-09.sun.com>; Tue, 08 Jan 2008 12:01:50 +0000 (GMT) Date: Tue, 08 Jan 2008 12:59:37 +0100 (CET) From: Jan Pechanec Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <47835A17.6070704@Sun.COM> Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@fossa.czech.sun.com To: Darren J Moffat Cc: PSARC-EXT@sun.com, kmf-discuss@opensolaris.org, Huie-Ying Lee Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47835A17.6070704@Sun.COM> Status: RO Content-Length: 1235 On Tue, 8 Jan 2008, Darren J Moffat wrote: > I'm sponsoring this case for Huie-Ying Lee of the OpenSolaris KMF project. I'm > using this old case number as other ARC cases reference this case number as a > requirement for EOF removal of some old smartcard functionality. hi Darren, during the recent discussion on kmf-discussion we came to conclusion that certificate to user mapping capability should be exported by KMF since that's quite a common thing requested by applications working with certificates. While there is no draft on possible implementation, using dynamic modules seems to be the right thing so that we could add new mappings on the fly, possibly just with a new section in a configuration file. mapper modules shipped with pam_pkcs11 seem like the way to go and to start with. I think that another consumer of such modules might be Kerberos. shouldn't we then consider certificate to username mapping a generic feature that is going to be needed by various parts of the system? having said that then for example /usr/lib/pam_pkcs11/ for storing shared mapper modules wouldn't fit into that picture of generic mapper modules used by various consumers in Solaris. thanks, Jan. -- Jan Pechanec From Darren.Moffat@sun.com Tue Jan 8 04:10:54 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08CAsuG010704 for ; Tue, 8 Jan 2008 04:10:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m08CArEl013299 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 8 Jan 2008 04:10:54 -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 <0JUB00G0NR652O00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 04:10:53 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUB00FQQR633Q10@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 04:10:52 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m08CApLN023292 for ; Tue, 08 Jan 2008 12:10:51 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUB00L01QX37000@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 12:10:51 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUB00FBIR624310@fe-emea-10.sun.com>; Tue, 08 Jan 2008 12:10:50 +0000 (GMT) Date: Tue, 08 Jan 2008 12:10:50 +0000 From: Darren J Moffat Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: Sender: Darren.Moffat@sun.com To: Jan Pechanec Cc: PSARC-EXT@sun.com, kmf-discuss@opensolaris.org, Huie-Ying Lee Message-id: <4783684A.2040708@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: <47835A17.6070704@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1828 Jan Pechanec wrote: > On Tue, 8 Jan 2008, Darren J Moffat wrote: > >> I'm sponsoring this case for Huie-Ying Lee of the OpenSolaris KMF project. I'm >> using this old case number as other ARC cases reference this case number as a >> requirement for EOF removal of some old smartcard functionality. > > hi Darren, during the recent discussion on kmf-discussion we came to > conclusion that certificate to user mapping capability should be exported by > KMF since that's quite a common thing requested by applications working with > certificates. While there is no draft on possible implementation, using > dynamic modules seems to be the right thing so that we could add new > mappings on the fly, possibly just with a new section in a configuration > file. > > mapper modules shipped with pam_pkcs11 seem like the way to go and > to start with. I think that another consumer of such modules might be > Kerberos. Which is one of the reasons that the mapper modules this case provides are Volatile and not Committed. > shouldn't we then consider certificate to username mapping a generic > feature that is going to be needed by various parts of the system? Yes we should but I don't believe anyone is ready to bring a case for that yet. > having said that then for example /usr/lib/pam_pkcs11/ for storing > shared mapper modules wouldn't fit into that picture of generic mapper > modules used by various consumers in Solaris. Which is why this is a Volatile interface - so that when the future case comes along to do this more generically if it needs to it can move the mapping modules provided by this case. I don't see anything in this case that stops the project team providing a generic cert mapping functionality later, even based on the modules that this case provides. -- Darren J Moffat From Jan.Pechanec@sun.com Tue Jan 8 04:14:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08CEmDO010738 for ; Tue, 8 Jan 2008 04:14:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m08CEjSn008800 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 8 Jan 2008 12:14:48 GMT 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 <0JUB00J09RCNSE00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 05:14:47 -0700 (MST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUB00HMQRCLNVD0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 05:14:46 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m08CEjRk007536 for ; Tue, 08 Jan 2008 12:14:45 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUB00L01QX37000@fe-emea-10.sun.com> (original mail from Jan.Pechanec@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 Jan 2008 12:14:45 +0000 (GMT) Received: from fossa.czech.sun.com ([129.157.71.113]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUB00GMYRCKQK40@fe-emea-10.sun.com>; Tue, 08 Jan 2008 12:14:45 +0000 (GMT) Date: Tue, 08 Jan 2008 13:12:32 +0100 (CET) From: Jan Pechanec Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <4783684A.2040708@Sun.COM> Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@fossa.czech.sun.com To: Darren J Moffat Cc: PSARC-EXT@sun.com, kmf-discuss@opensolaris.org, Huie-Ying Lee Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47835A17.6070704@Sun.COM> <4783684A.2040708@Sun.COM> Status: RO Content-Length: 561 On Tue, 8 Jan 2008, Darren J Moffat wrote: > Which is why this is a Volatile interface - so that when the future case comes > along to do this more generically if it needs to it can move the mapping > modules provided by this case. > > I don't see anything in this case that stops the project team providing a > generic cert mapping functionality later, even based on the modules that this > case provides. ok, good point. I didn't realize that mapper pathnames were volatile, I mistakenly read that as "modules", not "module". Thanks, J. -- Jan Pechanec From Nicolas.Williams@sun.com Tue Jan 8 08:42:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08Ggitt015503 for ; Tue, 8 Jan 2008 08:42:45 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m08Ggg1E005173; Tue, 8 Jan 2008 16:42:42 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 <0JUC00J0B3R5YK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 Jan 2008 08:42:41 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUC00EVR3R5IM80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 Jan 2008 08:42:41 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m08Ggbkq000219; Tue, 08 Jan 2008 10:42:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m08Ggal7000218; Tue, 08 Jan 2008 10:42:36 -0600 (CST) Date: Tue, 08 Jan 2008 10:42:36 -0600 From: Nicolas Williams Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <47835A17.6070704@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, Huie-Ying Lee , kmf-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , PSARC-EXT@sun.com, Huie-Ying Lee , kmf-discuss@opensolaris.org Message-id: <20080108164236.GR22538@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47835A17.6070704@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 5422 On Tue, Jan 08, 2008 at 11:10:15AM +0000, Darren J Moffat wrote: > ========================================== > The pam_pkcs11 module overview > ========================================== > The pam_pkcs11 module is a PAM authentication module for PKCS#11 token > libraries. This module allows a user to login a system that supports PAM, > using a certificate and its dedicated private key stored in a PKCS#11 token. > > This pam_pkcs11 module supports any PKCS#11 token library, however, it > is typically used by a Smart-card PKCS#11 token. > > The original source of this module is provided by opensc-project.org. > The latest version is 0.6.0 which supports only the authentication service. > It does not support pam_setcred, pam_acct_mgmt, or other services. Why no pam_acct_mgmt? The module checks that the cert is not expired/ revoked... > For more information, see http://www.opensc-project.org/pam_pkcs11 > > ========================================================= > The pam_pkcs11 authentication/verification procedure > ========================================================= > The authentication and verification procedure is as following: > > Step 1: Find all certificate/private_key pair in the PKCS#11 token > > Step 2: Find the certificate/private_key pair that matches the user > > For each pair of the certificate and its associated private key If PAM_USER is not set when pam_pkcs11:pam_sm_authenticate() is invoked, will it set PAM_USER, and if so, which cert will be used to derive the username? (see more below) The pam_pkcs11.conf manpage mentions parameters that shouldn't be needed on Solaris: | # Do not prompt the user for the passwords but take them from the | # PAM_ items instead. | use_first_pass = false; | | # Do not prompt the user for the passwords unless PAM_(OLD)AUTHTOK | # is unset. | try_first_pass = false; | | # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been | # previously set (intended for stacking password modules only). | use_authtok = false; Or perhaps the token PIN should be seen as distinct from the AUTHTOK, in which case that might require at least one parameter. Also, if the home directory of the PAM_USER is on secure NFS, what happens when the metaslot is used? Will the module find any smartcards? Or will it fail? > [...] > > ========================================== > Deliverables: > ========================================== > Pam_pkcs11 module: > > /usr/lib/security/pam_pkcs11.so > > (Note: will support both 32bit and 64 bit versions.) > > Non-built-in Mapper modules: > > /usr/lib/pam_pkcs11/ldap_mapper.so > /usr/lib/pam_pkcs11/opensc_mapper.so > /usr/lib/pam_pkcs11/openssh_mapper.so Given that the mapper objects are volatile, how might these paths be handled on upgrade if and when the cert->user mapping facility moves into KMF? Presumably the openssh and opensc mappers can only check that a given cert maps to a given PAM_USER (since they cannot search all users' home directories), and cannot derive a PAM_USER from a cert (whereas the 'generic' and 'subject' mappers could do both). Will the 'ldap' mapper support the use of SASL/GSSAPI/Kerberos to authenticate to the directory? Will the 'ldap' mapper support the use of the native LDAP configuration instead of having to repeat that in pam_pkcs11.conf (when the DIT containing these mappings is also the same as the native LDAP DIT)? Looking at the description of the 'ldap' mapper I see it can only really support verification that a cert corresponds to a PAM_USER, not derivation of a PAM_USER from a cert, and it appears to require storing the entire cert in LDAP (as opposed to a fingerprint, or subject name, or list of subjectAltNames). This being a third-party open source PAM module I think this is reasonable, but could we open RFEs in this area? The 'krb' mapper should specify a realm name, no? Or is it formatting a principal name of the form @ and then comparing it to the krb5 princname subjectAltName? The pam_pkcs11.conf manpage in the materials refers to /usr/lib/opensc-pkcs11.so and so on as well... This should be cleaned up. > (Note: will support both 32bit and 64 bit versions.) > > [...] > > Sample Mapfiles and script: > > /etc/security/pam_pkcs11/digest_mapping.example > /etc/security/pam_pkcs11/subject_mapping.example > /etc/security/pam_pkcs11/mail_mapping.example > /etc/security/pam_pkcs11/make_hash_link.sh The above are not in the materials. > Utility commands: > > /usr/lib/pam_pkcs11/pkcs11_inspect > /usr/lib/pam_pkcs11/pklogin_finder > /usr/lib/pam_pkcs11/pkcs11_eventmgr > > (Note: will support both 32bit and 64bit versions.) Shouldn't we already have pkcs11_inspect-like functionality in pktool(1)? How will pkcs11_eventmgr be used? > [...] > > Run: > ------------------------------------------------------------------------ > hylee@bula$exec login > Please insert your smart card or enter your username. > login: hylee > Smart card inserted. > Welcome Sun Metaslot! > Smart card password: XXXXXX > Last login: Wed Sep 12 15:10:29 from comforter > Sun Microsystems Inc. SunOS 5.11 snv_65 October 2007 > ------------------------------------------------------------------------ > > Note that the "Smart card password" is the Solaris softtoken keystore > password. So each token type can have its own prompt? Nico -- From huie-ying.lee@sun.com Wed Jan 9 21:11:47 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0A5BlDV024867 for ; Wed, 9 Jan 2008 21:11:47 -0800 (PST) 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 m0A5BkOO000490 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 9 Jan 2008 22:11:46 -0700 (MST) 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 <0JUE0080HX3H0U00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 Jan 2008 21:11:41 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE00712X3HZ700@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 Jan 2008 21:11:41 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0A5Bcfo001263; Wed, 09 Jan 2008 21:11:38 -0800 (PST) Received: from [129.146.108.12] (comforter.SFBay.Sun.COM [129.146.108.12]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m0A5BbS13408; Wed, 09 Jan 2008 21:11:37 -0800 (PST) Date: Wed, 09 Jan 2008 21:11:00 -0800 From: Huie-Ying Lee Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <20080108164236.GR22538@Sun.COM> To: Darren J Moffat , PSARC-EXT@sun.com, Huie-Ying Lee , kmf-discuss@opensolaris.org Message-id: <4785A8E4.7020402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47835A17.6070704@Sun.COM> <20080108164236.GR22538@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 9310 Nicolas Williams wrote: Thank you for the valuable review input, please see my response below. > On Tue, Jan 08, 2008 at 11:10:15AM +0000, Darren J Moffat wrote: >> ========================================== >> The pam_pkcs11 module overview >> ========================================== >> The pam_pkcs11 module is a PAM authentication module for PKCS#11 token >> libraries. This module allows a user to login a system that supports PAM, >> using a certificate and its dedicated private key stored in a PKCS#11 token. >> >> This pam_pkcs11 module supports any PKCS#11 token library, however, it >> is typically used by a Smart-card PKCS#11 token. >> >> The original source of this module is provided by opensc-project.org. >> The latest version is 0.6.0 which supports only the authentication service. >> It does not support pam_setcred, pam_acct_mgmt, or other services. > > Why no pam_acct_mgmt? The module checks that the cert is not expired/ > revoked... > The pam_pkcs11 module from opensc-project.org doesn't support pam_acct_mgmt currently, so it is not supported in this case. If this function is critical to have, we can request OPENSC and work with them to add this function in the future release. The module does check if the cert is expired or revoked in the pam_authenticate() function based on the pam_pkcs11 configuration. >> For more information, see http://www.opensc-project.org/pam_pkcs11 >> >> ========================================================= >> The pam_pkcs11 authentication/verification procedure >> ========================================================= >> The authentication and verification procedure is as following: >> >> Step 1: Find all certificate/private_key pair in the PKCS#11 token >> >> Step 2: Find the certificate/private_key pair that matches the user >> >> For each pair of the certificate and its associated private key > > If PAM_USER is not set when pam_pkcs11:pam_sm_authenticate() is invoked, > will it set PAM_USER, and if so, which cert will be used to derive the > username? (see more below) > The pam_pkcs11:pam_sm_authenticate() function will prompt the user for the username. It will set PAM_USER, after it found a matching certificate in the PKCS11 keystore. This function will loop all the certificates in the PKCS11 keystore to find the certificate that matches the user based on the mapping creteria specified in the configuration. The first matched one is the chosen one. > The pam_pkcs11.conf manpage mentions parameters that shouldn't be needed > on Solaris: > > | # Do not prompt the user for the passwords but take them from the > | # PAM_ items instead. > | use_first_pass = false; > | > | # Do not prompt the user for the passwords unless PAM_(OLD)AUTHTOK > | # is unset. > | try_first_pass = false; > | > | # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been > | # previously set (intended for stacking password modules only). > | use_authtok = false; > > Or perhaps the token PIN should be seen as distinct from the AUTHTOK, in > which case that might require at least one parameter. > The password that it tries to get is actually the token PIN. I agree with you that these 3 arguments should not be needed, although they are presented in the OpenSC/pam_pkcs11.conf configuration example file, because this module will always need to prompt for the token PIN. > Also, if the home directory of the PAM_USER is on secure NFS, what > happens when the metaslot is used? Will the module find any smartcards? > Or will it fail? > Not very clear about the first question, so I will answer the 2nd one only for now and the short answer is "yes, this module will find the smartcard." When metaslot is used, a user can specify the persistent keystore by using the cryptoadm command or the METASLOT_OBJECTSTORE_SLOT environment variable. To use the smartcard as the keystore, first of all, a smartcard pkcs11 libary should be installed into the cryptographic framework (libpkcs11). Then the administrator uses the cryptoadm command or env variable to set the smartcard token as the metaslot persistent storage. The pam_pkcs11 module runs on top of libpkcs11, so it will find the smartcard token. This is actually a cryptographic framework feature. A smartcard token is treated as same as any other token under the libpkcs11 framework. Because there is no smartcard pkcs11 library available at the moment, I use softtoken for testing. SunRay folks are porting the OpenSC library (a smartcard PKCS11 library from opensc-project.org ) to Solaris. Once they are ready, we can really test this route. Please note that this case doesn't depend on any smartcard PKCS11 library. >> [...] >> >> ========================================== >> Deliverables: >> ========================================== >> Pam_pkcs11 module: >> >> /usr/lib/security/pam_pkcs11.so >> >> (Note: will support both 32bit and 64 bit versions.) >> >> Non-built-in Mapper modules: >> >> /usr/lib/pam_pkcs11/ldap_mapper.so >> /usr/lib/pam_pkcs11/opensc_mapper.so >> /usr/lib/pam_pkcs11/openssh_mapper.so > > Given that the mapper objects are volatile, how might these paths be > handled on upgrade if and when the cert->user mapping facility moves > into KMF? > The pam_pkcs11 project is a porting project, requested by UBS. Since the source of the pam_pkcs11 module is from a third party which we don't have control at all and the OpenSC library (the smartcard library from OpenSC) will depend on this module, I think we will be better off to leave this pam_pkcs11 module alone (keep using its own modules instead of changing it to use future KMF stuff). > Presumably the openssh and opensc mappers can only check that a given > cert maps to a given PAM_USER (since they cannot search all users' home > directories), and cannot derive a PAM_USER from a cert (whereas the > 'generic' and 'subject' mappers could do both). > > Will the 'ldap' mapper support the use of SASL/GSSAPI/Kerberos to > authenticate to the directory? > No. > Will the 'ldap' mapper support the use of the native LDAP configuration > instead of having to repeat that in pam_pkcs11.conf (when the DIT > containing these mappings is also the same as the native LDAP DIT)? > No. > Looking at the description of the 'ldap' mapper I see it can only really > support verification that a cert corresponds to a PAM_USER, not > derivation of a PAM_USER from a cert, and it appears to require storing > the entire cert in LDAP (as opposed to a fingerprint, or subject name, > or list of subjectAltNames). This being a third-party open source PAM Right. > module I think this is reasonable, but could we open RFEs in this area? > Yes, we can request OPENSC to support this in the future. > The 'krb' mapper should specify a realm name, no? Or is it formatting a > principal name of the form @ and then comparing > it to the krb5 princname subjectAltName? > I havn't tested this part yet. Will get back to you when I have more info. > The pam_pkcs11.conf manpage in the materials refers to > /usr/lib/opensc-pkcs11.so and so on as well... This should be cleaned > up. > OK, will clean it up. >> (Note: will support both 32bit and 64 bit versions.) >> >> [...] >> >> Sample Mapfiles and script: >> >> /etc/security/pam_pkcs11/digest_mapping.example >> /etc/security/pam_pkcs11/subject_mapping.example >> /etc/security/pam_pkcs11/mail_mapping.example >> /etc/security/pam_pkcs11/make_hash_link.sh > > The above are not in the materials. > Right. Will fix this. I have requested Darren to put them to the materials directory, as I don't have write permission. >> Utility commands: >> >> /usr/lib/pam_pkcs11/pkcs11_inspect >> /usr/lib/pam_pkcs11/pklogin_finder >> /usr/lib/pam_pkcs11/pkcs11_eventmgr >> >> (Note: will support both 32bit and 64bit versions.) > > Shouldn't we already have pkcs11_inspect-like functionality in > pktool(1)? > This pkcs11_inspect command is a debugging tool for the pam_pkcs11 module, which is very different from pktool(1). It basically prints out the mapping data for each mapper specified in the pam_pkcs11 configuration file. This command is quite useful when a user is configuring the mapper list. > How will pkcs11_eventmgr be used? > The program is very simple, it periodically calls pkcs11 get_slot_info to find the # of slots. If number > 0, then state = card_present, otherwise, state = card_not_present. if state is changed, then print out the message. It doesn't seem very useful to me though. >> [...] >> >> Run: >> ------------------------------------------------------------------------ >> hylee@bula$exec login >> Please insert your smart card or enter your username. >> login: hylee >> Smart card inserted. >> Welcome Sun Metaslot! >> Smart card password: XXXXXX >> Last login: Wed Sep 12 15:10:29 from comforter >> Sun Microsystems Inc. SunOS 5.11 snv_65 October 2007 >> ------------------------------------------------------------------------ >> >> Note that the "Smart card password" is the Solaris softtoken keystore >> password. > > So each token type can have its own prompt? > The prompt will be the same basically. Currently, the source uses "smart card" to prompt. Thanks, Huie-Ying From gww@eng.sun.com Tue Jan 15 13:56:49 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FLumNV028619 for ; Tue, 15 Jan 2008 13:56:49 -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 m0FLuj5L009449 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 16 Jan 2008 05:56:48 +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 <0JUP00B19GYJ4100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 15 Jan 2008 13:56:43 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP007J9GYIKFE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 15 Jan 2008 13:56:42 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0FLuepp011226; Tue, 15 Jan 2008 13:56:40 -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 m0FLta6G028191; Tue, 15 Jan 2008 13:55:36 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0FLta5H028190; Tue, 15 Jan 2008 13:55:36 -0800 (PST) Date: Tue, 15 Jan 2008 13:55:36 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) To: Darren.Moffat@sun.com, PSARC-EXT@sun.com Cc: Huie-Ying.Lee@sun.com, kmf-discuss@opensolaris.org Message-id: <200801152155.m0FLta5H028190@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3350 > Man pages and other supporting material is in the materials subdir of > the case. The documentation has come a long way since I last saw this. Thanks. I've still not completed an understanding of the opensc-project.org/pam_pkcs11/pam_pkcs11.html doc, so I expect I may not grasp the whole thing yet. However, a few comments and questions: I wanted to point out that this work is a continuation of the work our Summer Intern, Brendan O'Connor, started working with Huie Ying. I promised him I'd add him to the interest and have in the IAM file. Nits: * I presume when pam_pkcs11.5.sunman get's delivered into the /usr/share/*/man tree it will be just .5. If not I'd like to understand the precedence for the sunman suffix. * The man pages are missing ATTRIBUTES sections. * The DESCRIPTION of pkcs11_inspect and pkcs11_find still refer to pam_pkcs11(8). The SEE ALSOs refer to pam_pkcs11(5) as I'd expect, modulo the sunman thing above. Questions: 1) pam_pkcs11(5) refers to opensc-project.org/pam_pkcs11/pam_pkcs11.html for administrator documents. How is this project going to keep in sync with the community? IMO, it would be appropriate to have sufficient documentation within the Solaris docs areas so the community docs are secondary to the Sun docs delivered for a particular release. It would seem appropriate to have that documentation as part of this case. 2) Huie Ying answered that the commuity version doesn't support pam_acct_mgmt(). This seems like a common oversight and a violation of the separation of authentication from account validation that is part of the PAM architecture. I would think that certificate validation (and CRL processing) would be part of account validation. Why shouldn't that be and why shouldn't Sun contribute that to the community? 3) What changes has Sun made (beyond sample configuration file changes)? Are these being contributed back to the community? 4) Given that this is intended to replace the EOLed pam_smartcard, I don't see sufficient Sun documentation (at least from what's in this case) to guide me through how to use pam_pkcs11 to replace pam_smartcard. I would have expected at least that much detail as pam_smartcard was equivalent to a "Committed" interface in the past and its use more or less well documented in Sun documentation. P.S. I'm looking forward to the removal of the closed pam_smartcard and the project private interfaces in libpam that are there to support pam_smartcard ;-) 5) To me, the documentation is unclear as to how to properly configure pam.conf to use pam_pkcs11. Saying "add the pam_pkcs11.so module to the /etc/pam.conf file as below: login auth sufficient pam_pkcs11.so" seems inadequate. Where should it be put in the default delivered login stack? login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 How does it interact with other possible changes for Kerberos in addition to Unix authentication? Should it be stacked below pam_authtok_get? Gary.. From huie-ying.lee@sun.com Tue Jan 15 14:15:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FMFDN4029205 for ; Tue, 15 Jan 2008 14:15:14 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0FMF3UR025705 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 15 Jan 2008 22:15:12 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 <0JUP00C05HTARU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 15 Jan 2008 14:15:10 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP00C8FHTAIA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 15 Jan 2008 14:15:10 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0FMF88k024409; Tue, 15 Jan 2008 14:15:08 -0800 (PST) Received: from [129.146.108.12] (comforter.SFBay.Sun.COM [129.146.108.12]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m0FMF7E05687; Tue, 15 Jan 2008 14:15:07 -0800 (PST) Date: Tue, 15 Jan 2008 14:14:23 -0800 From: Huie-Ying Lee Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <4785A8E4.7020402@sun.com> To: Nicolas Williams Cc: Darren J Moffat , PSARC-EXT@sun.com, kmf-discuss@opensolaris.org Message-id: <478D303F.1070901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47835A17.6070704@Sun.COM> <20080108164236.GR22538@Sun.COM> <4785A8E4.7020402@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1766 Nicolas, This email is to address the remaining KRB mapper question and the pam_pkcs11.conf configuration issue. Please see below for my response. Huie-Ying Lee wrote: > Nicolas Williams wrote: > >> The 'krb' mapper should specify a realm name, no? Or is it formatting a >> principal name of the form @ and then comparing >> it to the krb5 princname subjectAltName? >> > > I havn't tested this part yet. Will get back to you when I have more info. > The answer to the first question is "no". The "krb" mapper does not need to specify a realm name. The answer to the 2nd question is "yes". To use the KRB mapper, a certificate should contain a subjectAltName with the @ format for oid = {1 3 6 1 5 2 2}. >> The pam_pkcs11.conf manpage in the materials refers to >> /usr/lib/opensc-pkcs11.so and so on as well... This should be cleaned >> up. >> > > OK, will clean it up. > I think you meant the pam_pkcs11.conf configuration file, not the pam_pkcs11.sunman man page. Right ? I have updated the pam_pkc11.conf configuration file and requested Darren to put it into the materials directory yesterday. > >>> (Note: will support both 32bit and 64 bit versions.) >>> >>> [...] >>> >>> Sample Mapfiles and script: >>> >>> /etc/security/pam_pkcs11/digest_mapping.example >>> /etc/security/pam_pkcs11/subject_mapping.example >>> /etc/security/pam_pkcs11/mail_mapping.example >>> /etc/security/pam_pkcs11/make_hash_link.sh >> >> The above are not in the materials. >> > > Right. Will fix this. > > I have requested Darren to put them to the materials directory, as > I don't have write permission. > The above 4 missing pieces are now in the materials directory already. Thanks to Darren. Huie-Ying From huie-ying.lee@sun.com Wed Jan 23 09:33:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0NHXlLn021753 for ; Wed, 23 Jan 2008 09:33:47 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0NHXh8A020906 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 23 Jan 2008 17:33:46 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 <0JV300E0FY479200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 23 Jan 2008 09:33:43 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV300D8WY47U920@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 23 Jan 2008 09:33:43 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0NHXfR1000992; Wed, 23 Jan 2008 09:33:41 -0800 (PST) Received: from [129.146.108.12] (comforter.SFBay.Sun.COM [129.146.108.12]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m0NHXeE08153; Wed, 23 Jan 2008 09:33:40 -0800 (PST) Date: Wed, 23 Jan 2008 09:32:52 -0800 From: Huie-Ying Lee Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <200801152155.m0FLta5H028190@marduk.eng.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-EXT@sun.com, kmf-discuss@opensolaris.org, Glenn Barry Message-id: <47977A44.9010001@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801152155.m0FLta5H028190@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 5367 Gary Winiger wrote: Thank you for the valuable review input, please see our response below. >> Man pages and other supporting material is in the materials subdir of >> the case. > > The documentation has come a long way since I last saw this. > Thanks. I've still not completed an understanding of > the opensc-project.org/pam_pkcs11/pam_pkcs11.html doc, so I > expect I may not grasp the whole thing yet. However, a few > comments and questions: > > I wanted to point out that this work is a continuation of the > work our Summer Intern, Brendan O'Connor, started working with > Huie Ying. I promised him I'd add him to the interest and > have in the IAM file. > > Nits: > * I presume when pam_pkcs11.5.sunman get's delivered into the > /usr/share/*/man tree it will be just .5. If not I'd like > to understand the precedence for the sunman suffix. Yes. > * The man pages are missing ATTRIBUTES sections. Will fix. > * The DESCRIPTION of pkcs11_inspect and pkcs11_find still > refer to pam_pkcs11(8). The SEE ALSOs refer to pam_pkcs11(5) > as I'd expect, modulo the sunman thing above. > Will fix. > Questions: > 1) pam_pkcs11(5) refers to opensc-project.org/pam_pkcs11/pam_pkcs11.html > for administrator documents. How is this project going to keep > in sync with the community? IMO, it would be appropriate to have > sufficient documentation within the Solaris docs areas so the > community docs are secondary to the Sun docs delivered for a > particular release. It would seem appropriate to have that > documentation as part of this case. > Yes, we can take all OPENS/pam_pkcs11 online documents and place them in the /usr/share/doc/pam_pkcs11 directory and ship with the product. > 2) Huie Ying answered that the commuity version doesn't support > pam_acct_mgmt(). This seems like a common oversight and a > violation of the separation of authentication from account > validation that is part of the PAM architecture. I would think > that certificate validation (and CRL processing) would be > part of account validation. Why shouldn't that be and why > shouldn't Sun contribute that to the community? > This is a valid point. Since UBS requested this port and they are happy with the current pam_pkcs11 implementation, this case has merit to integrate as is. We will work with the upstream community to add the functionality as a separate pam_acct_mgmt() entry point. > 3) What changes has Sun made (beyond sample configuration file > changes)? Are these being contributed back to the community? > I have made some changes to make it built and ran on Solaris. We will contribute these changes back to the unstream community. > 4) Given that this is intended to replace the EOLed pam_smartcard, > I don't see sufficient Sun documentation (at least from what's > in this case) to guide me through how to use pam_pkcs11 to > replace pam_smartcard. I would have expected at least that > much detail as pam_smartcard was equivalent to a "Committed" > interface in the past and its use more or less well documented > in Sun documentation. > P.S. I'm looking forward to the removal of the closed pam_smartcard > and the project private interfaces in libpam that are there to > support pam_smartcard ;-) > I have discussed with Darren about this. And here is our response: "This case alone does not give us a functional replacement for pam_smartcard. Another future case that provides a smartcard plugin to the crypto framework is needed together with this case since this case has no smartcard functionality it is all done via the PKCS#11 layer." > 5) To me, the documentation is unclear as to how to properly > configure pam.conf to use pam_pkcs11. Saying "add the > pam_pkcs11.so module to the /etc/pam.conf file as below: > login auth sufficient pam_pkcs11.so" > seems inadequate. Where should it be put in the default > delivered login stack? > > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_cred.so.1 > login auth required pam_unix_auth.so.1 > login auth required pam_dial_auth.so.1 > > How does it interact with other possible changes for > Kerberos in addition to Unix authentication? > Should it be stacked below pam_authtok_get? > How to properly configure pam.conf to use pam_pkcs11 really depends on what behavior that an admin wants. The pam_pkcs11 entry can be placed above or below pam_authtok_get/pam_unix_auth depending on the site needs. As for the interaction with Kerberos, I discussed this with Glenn Barry (a kerberos engineer) and we conclude that 1. If the home directory is kerberized, then the pam_krb5.so module (current version) should place before the pam_pkcs11.so module. 2. If pam_krb5.so is enhanced to support PKINIT and a new pam_krb5.so entry exists in the pam.conf file, then a "pam_pkcs11.so" module stacked below probably is redundent, because the new pam_krb5.so module should have check the certificate status and verify with private key already. I will add a couple of examples into the pam_pkcs11.5 man page. Thanks, Huie-Ying From gww@eng.sun.com Sun Jan 27 16:40:22 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S0eMGV028802 for ; Sun, 27 Jan 2008 16:40:22 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S0eJfM010384 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 28 Jan 2008 00:40:20 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 <0JVB00F1BWJ6UC00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Sun, 27 Jan 2008 16:40:18 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVB001MWWJ2S1A0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Sun, 27 Jan 2008 16:40:14 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S0eC1i002735; Sun, 27 Jan 2008 16:40:12 -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 m0S0crJY027708; Sun, 27 Jan 2008 16:38:53 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0S0crPq027707; Sun, 27 Jan 2008 16:38:53 -0800 (PST) Date: Sun, 27 Jan 2008 16:38:53 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) To: gww@eng.sun.com, huie-ying.lee@sun.com Cc: Darren.Moffat@sun.com, Glenn.Barry@sun.com, PSARC-EXT@sun.com, kmf-discuss@opensolaris.org Message-id: <200801280038.m0S0crPq027707@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6616 > > Questions: > > 1) pam_pkcs11(5) refers to opensc-project.org/pam_pkcs11/pam_pkcs11.html > > for administrator documents. How is this project going to keep > > in sync with the community? IMO, it would be appropriate to have > > sufficient documentation within the Solaris docs areas so the > > community docs are secondary to the Sun docs delivered for a > > particular release. It would seem appropriate to have that > > documentation as part of this case. > > > > Yes, we can take all OPENS/pam_pkcs11 online documents and place them > in the /usr/share/doc/pam_pkcs11 directory and ship with the product. Having made an attempt to read this, I remain unconvinced that the documentation is adequate for anyone but an expert in the area. Indeed co-packaging the docs is good and should be done. > > 2) Huie Ying answered that the commuity version doesn't support > > pam_acct_mgmt(). This seems like a common oversight and a > > violation of the separation of authentication from account > > validation that is part of the PAM architecture. I would think > > that certificate validation (and CRL processing) would be > > part of account validation. Why shouldn't that be and why > > shouldn't Sun contribute that to the community? > > > > This is a valid point. Since UBS requested this port and they are happy with > the current pam_pkcs11 implementation, this case has merit to integrate as is. > We will work with the upstream community to add the functionality as a separate > pam_acct_mgmt() entry point. I disagree that this should be postponed. Saying a single customer is happy with the implementation (do they have an IDR?) doesn't make it architecturally correct. If the code is currently doing certificate validation (and CRL or OCSP processing), it seems a straight forward factoring of the code. Waiting for phase 2 likely means changes to pam.conf as well as updating the code. > > 4) Given that this is intended to replace the EOLed pam_smartcard, > > I don't see sufficient Sun documentation (at least from what's > > in this case) to guide me through how to use pam_pkcs11 to > > replace pam_smartcard. I would have expected at least that > > much detail as pam_smartcard was equivalent to a "Committed" > > interface in the past and its use more or less well documented > > in Sun documentation. > > P.S. I'm looking forward to the removal of the closed pam_smartcard > > and the project private interfaces in libpam that are there to > > support pam_smartcard ;-) > > > > I have discussed with Darren about this. And here is our response: > > "This case alone does not give us a functional replacement for pam_smartcard. > Another future case that provides a smartcard plugin to the crypto framework > is needed together with this case since this case has no smartcard > functionality it is all done via the PKCS#11 layer." Hummm, I guess I've read too much into the materials: "I'm using this old case number as other ARC cases reference this case number as a requirement for EOF removal of some old smartcard functionality." "hylee@bula$exec login Please insert your smart card or enter your username. login: hylee Smart card inserted. Welcome Sun Metaslot! Smart card password: XXXXXX" Should the prompts (presumably) from pam_pkcs11 not imply use of a "smart card"? > > > 5) To me, the documentation is unclear as to how to properly > > configure pam.conf to use pam_pkcs11. Saying "add the > > pam_pkcs11.so module to the /etc/pam.conf file as below: > > login auth sufficient pam_pkcs11.so" > > seems inadequate. Where should it be put in the default > > delivered login stack? > > > > login auth requisite pam_authtok_get.so.1 > > login auth required pam_dhkeys.so.1 > > login auth required pam_unix_cred.so.1 > > login auth required pam_unix_auth.so.1 > > login auth required pam_dial_auth.so.1 > > > > How does it interact with other possible changes for > > Kerberos in addition to Unix authentication? > > Should it be stacked below pam_authtok_get? > > How to properly configure pam.conf to use pam_pkcs11 really depends on > what behavior that an admin wants. The pam_pkcs11 entry can be placed > above or below pam_authtok_get/pam_unix_auth depending on the site needs. Of course. And it is this project's responsibility to give sufficient guidance. IMO, that is architectural -- how does this fit with the other account authorities Solaris ships. IMO, as single statement: "add the pam_pkcs11.so module to the /etc/pam.conf file as below: login auth sufficient pam_pkcs11.so" doesn't expose the architecture of pam_pkcs11 fits with Unix or Kerberos (or LDAP bind) account authorities. Is this provided elsewhere in the case materials that I may have missed? > As for the interaction with Kerberos, I discussed this with Glenn Barry (a > kerberos engineer) and we conclude that > > 1. If the home directory is kerberized, then the pam_krb5.so module > (current version) should place before the pam_pkcs11.so module. > > 2. If pam_krb5.so is enhanced to support PKINIT and a new pam_krb5.so > entry exists in the pam.conf file, then a "pam_pkcs11.so" module > stacked below probably is redundent, because the new pam_krb5.so > module should have check the certificate status and verify with > private key already. I guess I'm missing some understanding here. I thought pkinit as part of pam_setcred() wasn't an if, but was in the immediate plan. In any case I'm confused. If the home directory is not kerberized, where does pam_pkcs11 go in the stack? From 2, it sounds like pam_krb5 obsoletes pam_pkcs11. If that's the case, what's the compelling architectural reason to not combine forces and deliver a pam_krb5 that does it all rather than a pam_pkcs11? It seem that pam_pkcs11 will need to be removed from pam.conf when pam_krb5 replaces it? Or is it that in addition to Unix, Kerberos (and LDAP bind), a new account authority based on pkcs11 access to certificates is being proposed? I guess I can understand this if pam_pkcs11 is a replacement for pam_smartcard (which the case now says it isn't -- though I personally want to be able to support it as a replacement). > I will add a couple of examples into the pam_pkcs11.5 man page. IMO, they are architectural relevant and I don't see them in the materials. Gary.. From Nicolas.Williams@sun.com Sun Jan 27 20:40:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S4eKO3001059 for ; Sun, 27 Jan 2008 20:40:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S4eDRt015990; Mon, 28 Jan 2008 04:40:16 GMT 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 <0JVC00H0F7N36F00@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 21:40:15 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVC00JJE7N2JMA0@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 21:40:14 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0S4eD9A014181; Sun, 27 Jan 2008 22:40:13 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0S4eDRN014180; Sun, 27 Jan 2008 22:40:13 -0600 (CST) Date: Sun, 27 Jan 2008 22:40:13 -0600 From: Nicolas Williams Subject: Re: PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <200801280038.m0S0crPq027707@marduk.eng.sun.com> To: Gary Winiger Cc: Huie-Ying.Lee@sun.com, Glenn.Barry@sun.com, PSARC-EXT@sun.com, kmf-discuss@opensolaris.org Mail-followup-to: Gary Winiger , Huie-Ying.Lee@sun.com, Glenn.Barry@sun.com, PSARC-EXT@sun.com, kmf-discuss@opensolaris.org Message-id: <20080128044012.GV12865@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200801280038.m0S0crPq027707@marduk.eng.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 5140 On Sun, Jan 27, 2008 at 04:38:53PM -0800, Gary Winiger wrote: > > This is a valid point. Since UBS requested this port and they are happy with > > the current pam_pkcs11 implementation, this case has merit to integrate as is. > > We will work with the upstream community to add the functionality as a separate > > pam_acct_mgmt() entry point. > > I disagree that this should be postponed. Saying a single customer > is happy with the implementation (do they have an IDR?) doesn't > make it architecturally correct. If the code is currently doing > certificate validation (and CRL or OCSP processing), it seems > a straight forward factoring of the code. Waiting for phase 2 > likely means changes to pam.conf as well as updating the code. There's no need to factor the code. All that needs to happen is that pam_sm_authenticate() needs to call pam_set_data(3PAM) to tell the same module's pam_sm_acct_mgmt() that authentication succeeded, and the latter needs to call pam_get_data() to check whether authentication succeeded. The specific details of when pam_sm_acct_mgmt() should return PAM_SUCESS, PAM_IGNORE, or some error, need to be hashed out, but the rest seems trivial. > > > 4) Given that this is intended to replace the EOLed pam_smartcard, > > > I don't see sufficient Sun documentation (at least from what's > > > in this case) to guide me through how to use pam_pkcs11 to > > > replace pam_smartcard. I would have expected at least that > > > much detail as pam_smartcard was equivalent to a "Committed" > > > interface in the past and its use more or less well documented > > > in Sun documentation. > > > P.S. I'm looking forward to the removal of the closed pam_smartcard > > > and the project private interfaces in libpam that are there to > > > support pam_smartcard ;-) > > > > > > > I have discussed with Darren about this. And here is our response: > > > > "This case alone does not give us a functional replacement for pam_smartcard. > > Another future case that provides a smartcard plugin to the crypto framework > > is needed together with this case since this case has no smartcard > > functionality it is all done via the PKCS#11 layer." > > Hummm, I guess I've read too much into the materials: > > "I'm using this old case number as other ARC cases reference > this case number as a requirement for EOF removal of some old > smartcard functionality." > > "hylee@bula$exec login > Please insert your smart card or enter your username. > login: hylee > Smart card inserted. > Welcome Sun Metaslot! > Smart card password: XXXXXX" > > Should the prompts (presumably) from pam_pkcs11 not imply > use of a "smart card"? I'm not on the i-team, but I suspect that the example is using the softtoken as though it were a smartcard, and pam_pkcs11 doesn't know that it isn't really. Of course, if the softtoken lives on an NFS share accessed w/o sec=krb5i or p, then there are some security considerations... Even if secure NFS or local home directories are used there's the issue of how much control the user should be given over how to authenticate them (but then, ssh already allows users to do that with pubkey userauth). A knob for controlling whether the softtoken can be used by pam_pkcs11 would be useful. Control over where the softtoken lives would be good also (IIUC the only way to do that is through the SOFTTOKEN_DIR environment variable, but that's not good enough for a PAM module). [...] > I guess I'm missing some understanding here. I thought pkinit > as part of pam_setcred() wasn't an if, but was in the immediate > plan. In any case I'm confused. If the home directory is not > kerberized, where does pam_pkcs11 go in the stack? From 2, > it sounds like pam_krb5 obsoletes pam_pkcs11. If that's the case, I think you'd either use pam_pkcs11 or pam_krb5 w/ PKINIT, but not both. > what's the compelling architectural reason to not combine forces > and deliver a pam_krb5 that does it all rather than a pam_pkcs11? That not everyone uses Kerberos. (At least for me that would be the reason.) (BTW, someday we're likely to have a PKI-based GSS-API mechanism, allowing for secure NFS using that instead of Kerberos or DH. That mechanism is actually being specified in the IETF, and it's based on Kerberos and PKINIT components internally, but it is/will be a PKI mechanism -- the successor to the old SPKM.) > It seem that pam_pkcs11 will need to be removed from pam.conf > when pam_krb5 replaces it? Or is it that in addition to Unix, > Kerberos (and LDAP bind), a new account authority based on pkcs11 > access to certificates is being proposed? I guess I can > understand this if pam_pkcs11 is a replacement for pam_smartcard > (which the case now says it isn't -- though I personally want to > be able to support it as a replacement). Well, if pam_pkcs11 is part of a two-pronged strategy to replace pam_smartcard, what's the harm in delivering it first? But, yeah, there's the issue of how to secure the softtoken if it be the only available token for pam_pkcs11. Nico -- From Nicolas.Williams@sun.com Mon Jan 28 05:20:25 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0SDKPtJ010277 for ; Mon, 28 Jan 2008 05:20:25 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0SDKMuQ012621; Mon, 28 Jan 2008 05:20:25 -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 <0JVC00809VQ0YP00@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Jan 2008 05:20:24 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVC00GNEVPZFKD0@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Jan 2008 05:20:23 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0SDKKY7014436; Mon, 28 Jan 2008 07:20:20 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0SDKKWx014435; Mon, 28 Jan 2008 07:20:20 -0600 (CST) Date: Mon, 28 Jan 2008 07:20:20 -0600 From: Nicolas Williams Subject: Re: [kmf-discuss] PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <20080128044012.GV12865@Sun.COM> To: Gary Winiger , Huie-Ying.Lee@sun.com, Glenn.Barry@sun.com, psarc-ext@sun.com, kmf-discuss@opensolaris.org Mail-followup-to: Gary Winiger , Huie-Ying.Lee@Sun.COM, Glenn.Barry@Sun.COM, psarc-ext@sun.com, kmf-discuss@opensolaris.org Message-id: <20080128132019.GW12865@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200801280038.m0S0crPq027707@marduk.eng.sun.com> <20080128044012.GV12865@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 577 On Sun, Jan 27, 2008 at 10:40:13PM -0600, Nicolas Williams wrote: > Of course, if the softtoken lives on an NFS share accessed w/o sec=krb5i > or p, then there are some security considerations... Even if secure NFS > or local home directories are used there's the issue of how much control > the user should be given over how to authenticate them (but then, ssh > already allows users to do that with pubkey userauth). Excuse the brainfart. As long as there are trust anchors, suitable cert->username mappings and PINs are used then not using secure NFS is not a big deal. From huie-ying.lee@sun.com Mon Jan 28 16:36:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0T0a4rA029033 for ; Mon, 28 Jan 2008 16:36:05 -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 m0T0ZvCA017329 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 29 Jan 2008 08:36:03 +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 <0JVD00F09R022H00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 28 Jan 2008 16:36:02 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVD00C6KR00JM20@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 28 Jan 2008 16:36:01 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0T0Zx6s036643; Mon, 28 Jan 2008 16:35:59 -0800 (PST) Received: from [129.146.108.12] (comforter.SFBay.Sun.COM [129.146.108.12]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m0T0ZwE24426; Mon, 28 Jan 2008 16:35:59 -0800 (PST) Date: Mon, 28 Jan 2008 16:35:06 -0800 From: Huie-Ying Lee Subject: Re: [kmf-discuss] PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11) In-reply-to: <20080128044012.GV12865@Sun.COM> To: Gary Winiger , huie-ying.lee@sun.com, Glenn.Barry@sun.com, psarc-ext@sun.com, kmf-discuss@opensolaris.org Message-id: <479E74BA.1020301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801280038.m0S0crPq027707@marduk.eng.sun.com> <20080128044012.GV12865@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 4216 Nicolas Williams wrote: Thank you for the suggestions and etc. For most of issues brought up by Gary yesterday, I will address them later after I have a chance to discuss with Darren first. However, I would like to share my thoughts now about a couple of items. >>>> 4) Given that this is intended to replace the EOLed pam_smartcard, >>>> I don't see sufficient Sun documentation (at least from what's >>>> in this case) to guide me through how to use pam_pkcs11 to >>>> replace pam_smartcard. I would have expected at least that >>>> much detail as pam_smartcard was equivalent to a "Committed" >>>> interface in the past and its use more or less well documented >>>> in Sun documentation. >>>> P.S. I'm looking forward to the removal of the closed pam_smartcard >>>> and the project private interfaces in libpam that are there to >>>> support pam_smartcard ;-) >>>> >>> I have discussed with Darren about this. And here is our response: >>> >>> "This case alone does not give us a functional replacement for pam_smartcard. >>> Another future case that provides a smartcard plugin to the crypto framework >>> is needed together with this case since this case has no smartcard >>> functionality it is all done via the PKCS#11 layer." >> Hummm, I guess I've read too much into the materials: >> >> "I'm using this old case number as other ARC cases reference >> this case number as a requirement for EOF removal of some old >> smartcard functionality." >> >> "hylee@bula$exec login >> Please insert your smart card or enter your username. >> login: hylee >> Smart card inserted. >> Welcome Sun Metaslot! >> Smart card password: XXXXXX" >> >> Should the prompts (presumably) from pam_pkcs11 not imply >> use of a "smart card"? > > I'm not on the i-team, but I suspect that the example is using the > softtoken as though it were a smartcard, and pam_pkcs11 doesn't know > that it isn't really. > Yes, that's exactly the situation. Although the pam_pkcs11 module supports any PKCS#11 tokens, it is typically used by a Smart-card PKCS#11 token. This might be the reason that the pam_pkcs11 module includes "Smart card" in their prompts, I guess. To resolve the confusion when a user uses softtoken or others as the keystore, we can remove the "Smart Card" words from the prompts in the pam_pkcs11 source. > Of course, if the softtoken lives on an NFS share accessed w/o sec=krb5i > or p, then there are some security considerations... Even if secure NFS > or local home directories are used there's the issue of how much control > the user should be given over how to authenticate them (but then, ssh > already allows users to do that with pubkey userauth). > > A knob for controlling whether the softtoken can be used by pam_pkcs11 > would be useful. Control over where the softtoken lives would be good > also (IIUC the only way to do that is through the SOFTTOKEN_DIR > environment variable, but that's not good enough for a PAM module). > Glad that you brought this up. This is really a serious problem and I also found out the exact issue last Friday. I have a solution for it. I'm coding it and will test it with softtoken. Once the solution is successfully tested and reviewed, I will contribute it back to the OPENSC community. My solution is to replace the "slot_num" entry in the pam_pkcs11.conf configuration file with a "slot_info" entry. For example, if the pam_pkcs11 is configured to use the Solaris softtoken, then the slot_info entry will look like slot_info = "Sun Crypto Softtoken" At the runtime, the pam_pkcs11 module will find the slot with the same slot information first, then will call C_GetTokenInfo() to see if the token is presented or not. If the token is presented, then the operation will continue on that token. Otherwise, the operation will return an error immediately. Note that we can not use "token_info" for this case, because each person will have his/her own smartcard token and a token will be presented only when a smartcard is inserted into the card reader. For the softtoken situation, the token will be in the default location, home directory for a regular user. Huie-Ying From Darren.Moffat@sun.com Thu Mar 6 06:56:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26EuFSF018721 for ; Thu, 6 Mar 2008 06:56:16 -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 m26EuE8M005670 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 6 Mar 2008 22:56:14 +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 <0JXB0062GDHPZ100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 06 Mar 2008 06:56:13 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB005ESDHNBE10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 06 Mar 2008 06:56:12 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26EuBXR025818 for ; Thu, 06 Mar 2008 14:56:11 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00101CZK5700@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 06 Mar 2008 14:56:11 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00EA6DHBYO10@fe-emea-09.sun.com>; Thu, 06 Mar 2008 14:56:00 +0000 (GMT) Date: Thu, 06 Mar 2008 14:55:59 +0000 From: Darren J Moffat Subject: restart of PSARC/2006/283 Certificate & PKCS#11 PAM module Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com, Huie-Ying.Lee@sun.com Message-id: <47D005FF.7020509@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4QZCoarWzCKgld/vWw6/EA)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 7731 This is a multi-part message in MIME format. --Boundary_(ID_4QZCoarWzCKgld/vWw6/EA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I'm (again) restarting the review timer on PSARC/2006/283. The project team has provided updated materials which they believe addresses all of the open issues. The original materials have been moved to materials.old. Time out is set for Thursday 13th March 2008. Hopefully we can close on this case this time. -- Darren J Moffat --Boundary_(ID_4QZCoarWzCKgld/vWw6/EA) Content-type: text/plain; name=spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec.txt File: pam_pkcs11.psarc_summary ========================================== The pam_pkcs11 module overview ========================================== The pam_pkcs11 module is a PAM authentication module for PKCS#11 token libraries. This module allows a user to login a system that supports PAM, using a certificate and its dedicated private key stored in a PKCS#11 token. The original source of this module is provided by opensc-project.org. The latest version is 0.6.0 which supports only the pam_authenticate() function for the authentication service. For more information, see http://www.opensc-project.org/pam_pkcs11 This pam_pkcs11 module supports any PKCS#11 token library. On Solaris, the PKCS#11 library to be used for this module is /usr/lib/libpkcs11.so.1, the Solaris Cryptographic Framework. A user can configure the pam_pkcs11 module to use a specific slot/token. Note that the original pam_pkcs11 module from OpenSC uses slot number for the slot/token selection which is not always safe because there is no guaranteed ordering of slots returned from the PKCS#11 C_GetSlotList() function. To resolve this, on Solaris, the slot/token selection is changed to use the slot description instead. ========================================================= The pam_pkcs11 authentication/verification procedure ========================================================= The authentication and verification procedure is as following: Step 1: Find all the certificates in the PKCS#11 token Step 2: Find the certificate in the certificate list that matches the user For each certificate in the certificate list Verify the certificate to see if it is really issued by the CA certificate or if it has been revoked, based on the certificate verification policy specified in the configuration. If the certificate is valid, then check if it matches the user by using the certificate-to-user mappers specified in the configuration. If a good certificate is found, we are done Step 3: Signature verification If the "signature" policy is specified in the certificate verification policy in the configuration, then this module will find the private key on the token that is associated with the certificate and verify the public key inside the certificate and the private key are truly a pair with following algorithm: - Generates 128 random byte data. - Use the private key to sign the data and get a signature. (This will be done in the PKCS11 token). - Extract the public key from the certificate and verify the signature. ========================================== Deliverables: ========================================== Pam_pkcs11 module: /usr/lib/security/pam_pkcs11.so (Note: will support both 32bit and 64 bit versions.) Non-built-in Mapper modules: /usr/lib/pam_pkcs11/ldap_mapper.so /usr/lib/pam_pkcs11/opensc_mapper.so /usr/lib/pam_pkcs11/openssh_mapper.so (Note: will support both 32bit and 64 bit versions.) Configuration directories and files: /etc/security/pam_pkcs11/pam_pkcs11.conf /etc/security/pam_pkcs11/pkcs11_eventmgr.conf /etc/security/pam_pkcs11/cacerts (The directory to store the CA certificates) /etc/security/pam_pkcs11/crls (The directory to store the CRL files) Sample Mapfiles and script: /etc/security/pam_pkcs11/digest_mapping.example /etc/security/pam_pkcs11/subject_mapping.example /etc/security/pam_pkcs11/mail_mapping.example /etc/security/pam_pkcs11/make_hash_link.sh Utility commands: /usr/lib/pam_pkcs11/pkcs11_inspect /usr/lib/pam_pkcs11/pklogin_finder /usr/lib/pam_pkcs11/pkcs11_eventmgr (Note: will support both 32bit and 64bit versions.) man pages: /usr/share/man/man5/pam_pkcs11.5 /usr/share/man/man1/pklogin_finder.1 /usr/share/man/man1/pkcs11_eventmgr.1 /usr/share/man/man1/pkcs11_inspect.1 ================================================== A usage example ================================================== The following example demonstrates how to use the pam_pkcs11 module with the Solaris cryptographic framework and the Solaris PKCS#11 softtoken to authenticate a user to log into a system. Set up a certificate with private key in the Solaris PKCS#11 softtoken: - Initialize the Solaris softtoken keystore with the "pktool setpin" command. - Create a self-signed certificate in the Solaris Softtoken keystore, using the "pktool gencert" command. - Export the certificate file from the Solaris Softtoken keystore, using the "pktool export" command. Configure the pam_pkcs11 module: - The /etc/security/pam_pkcs11/pam_pkcs11.conf file is the configuration file for the pam_pkcs11 module. A user should modify this file to configure the pam_pkcs11 module. In this example, we will use default values for all the entries. - Copy the CA certificate to the /etc/security/pam_pkcs11/cacerts directory and make a hash link with the make_hash_link.sh script. Note: A certificate that is self-signed is its own CA certificate. Therefore, in this example, the certificate is placed both in the keystore and in the CA certificate directory. - Set up the map files in the /etc/security/pam_pkc11 directory. Note: When a X509 certificate is provided, there are no direct ways to map a certificate to a login. The pam_pkcs11 module provides a configurable way with mappers to specify cert-to-user mapping. Many mappers are provided by Pam_pkcs11, for example, the common name (CN) mapper, the digest mapper, the Email mapper, or the LDAP mapper. A user can configure a mapper list in the pam_pkcs11.conf file. The mappers in the list will be used sequentially until the certificate is successfully matched with the user. Some mappers do not require a mapfile to be specified (eg. the CN mapper), while some other mappers do require a mapfile (eg. the digest mapper) in the /etc/pam_pkcs11 directory. Configure the /etc/pam.conf file: The pam_pkcs11.so service module can be used in the PAM chain. In this example, we will use only pam_pkcs11 for authentication. login auth requisite pam_pkcs11.so.1 login auth required pam_unix_cred.so.1 Test: To test result, run "exec login" as below: -------------------------------------------------------------------- hylee@bula$exec login Please insert your smart card or enter your username. login: hylee found the PKCS#11 slot with a token. Welcome Sun Software PKCS#11 softtoken! token password: XXXXXXXX Last login: Tue Feb 26 14:13:41 from comforter Sun Microsystems Inc. SunOS 5.11 snv_80 Dec. 15, 2007 SunOS Internal Development: root 2007-12-15 [onnv_80] bfu'ed from /ws/onnv-gate/archives/sparc/snv_80 on 2007-12-19 Sun Microsystems Inc. SunOS 5.11 snv_76 October 2007 -------------------------------------------------------------------- --Boundary_(ID_4QZCoarWzCKgld/vWw6/EA)-- From Darren.Moffat@sun.com Thu Mar 6 07:27:46 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26FRkBO018946 for ; Thu, 6 Mar 2008 07:27:46 -0800 (PST) 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 m26FRhET042903 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 6 Mar 2008 08:27:46 -0700 (MST) 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 <0JXB00G37EY9LZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 06 Mar 2008 07:27:45 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00CZ8EWSYB80@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 06 Mar 2008 07:26:53 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26FQqoH000501 for ; Thu, 06 Mar 2008 15:26:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00G01EL03E00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 06 Mar 2008 15:26:52 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00CEMEWPPQ10@fe-emea-10.sun.com>; Thu, 06 Mar 2008 15:26:49 +0000 (GMT) Date: Thu, 06 Mar 2008 15:26:49 +0000 From: Darren J Moffat Subject: restart of PSARC/2006/283 Certificate & PKCS#11 PAM module Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com, Huie-Ying.Lee@sun.com Message-id: <47D00D39.6010107@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_D9QyvNR/YfYkAoXYLSlshQ)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 7731 This is a multi-part message in MIME format. --Boundary_(ID_D9QyvNR/YfYkAoXYLSlshQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I'm (again) restarting the review timer on PSARC/2006/283. The project team has provided updated materials which they believe addresses all of the open issues. The original materials have been moved to materials.old. Time out is set for Thursday 13th March 2008. Hopefully we can close on this case this time. -- Darren J Moffat --Boundary_(ID_D9QyvNR/YfYkAoXYLSlshQ) Content-type: text/plain; name=spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec.txt File: pam_pkcs11.psarc_summary ========================================== The pam_pkcs11 module overview ========================================== The pam_pkcs11 module is a PAM authentication module for PKCS#11 token libraries. This module allows a user to login a system that supports PAM, using a certificate and its dedicated private key stored in a PKCS#11 token. The original source of this module is provided by opensc-project.org. The latest version is 0.6.0 which supports only the pam_authenticate() function for the authentication service. For more information, see http://www.opensc-project.org/pam_pkcs11 This pam_pkcs11 module supports any PKCS#11 token library. On Solaris, the PKCS#11 library to be used for this module is /usr/lib/libpkcs11.so.1, the Solaris Cryptographic Framework. A user can configure the pam_pkcs11 module to use a specific slot/token. Note that the original pam_pkcs11 module from OpenSC uses slot number for the slot/token selection which is not always safe because there is no guaranteed ordering of slots returned from the PKCS#11 C_GetSlotList() function. To resolve this, on Solaris, the slot/token selection is changed to use the slot description instead. ========================================================= The pam_pkcs11 authentication/verification procedure ========================================================= The authentication and verification procedure is as following: Step 1: Find all the certificates in the PKCS#11 token Step 2: Find the certificate in the certificate list that matches the user For each certificate in the certificate list Verify the certificate to see if it is really issued by the CA certificate or if it has been revoked, based on the certificate verification policy specified in the configuration. If the certificate is valid, then check if it matches the user by using the certificate-to-user mappers specified in the configuration. If a good certificate is found, we are done Step 3: Signature verification If the "signature" policy is specified in the certificate verification policy in the configuration, then this module will find the private key on the token that is associated with the certificate and verify the public key inside the certificate and the private key are truly a pair with following algorithm: - Generates 128 random byte data. - Use the private key to sign the data and get a signature. (This will be done in the PKCS11 token). - Extract the public key from the certificate and verify the signature. ========================================== Deliverables: ========================================== Pam_pkcs11 module: /usr/lib/security/pam_pkcs11.so (Note: will support both 32bit and 64 bit versions.) Non-built-in Mapper modules: /usr/lib/pam_pkcs11/ldap_mapper.so /usr/lib/pam_pkcs11/opensc_mapper.so /usr/lib/pam_pkcs11/openssh_mapper.so (Note: will support both 32bit and 64 bit versions.) Configuration directories and files: /etc/security/pam_pkcs11/pam_pkcs11.conf /etc/security/pam_pkcs11/pkcs11_eventmgr.conf /etc/security/pam_pkcs11/cacerts (The directory to store the CA certificates) /etc/security/pam_pkcs11/crls (The directory to store the CRL files) Sample Mapfiles and script: /etc/security/pam_pkcs11/digest_mapping.example /etc/security/pam_pkcs11/subject_mapping.example /etc/security/pam_pkcs11/mail_mapping.example /etc/security/pam_pkcs11/make_hash_link.sh Utility commands: /usr/lib/pam_pkcs11/pkcs11_inspect /usr/lib/pam_pkcs11/pklogin_finder /usr/lib/pam_pkcs11/pkcs11_eventmgr (Note: will support both 32bit and 64bit versions.) man pages: /usr/share/man/man5/pam_pkcs11.5 /usr/share/man/man1/pklogin_finder.1 /usr/share/man/man1/pkcs11_eventmgr.1 /usr/share/man/man1/pkcs11_inspect.1 ================================================== A usage example ================================================== The following example demonstrates how to use the pam_pkcs11 module with the Solaris cryptographic framework and the Solaris PKCS#11 softtoken to authenticate a user to log into a system. Set up a certificate with private key in the Solaris PKCS#11 softtoken: - Initialize the Solaris softtoken keystore with the "pktool setpin" command. - Create a self-signed certificate in the Solaris Softtoken keystore, using the "pktool gencert" command. - Export the certificate file from the Solaris Softtoken keystore, using the "pktool export" command. Configure the pam_pkcs11 module: - The /etc/security/pam_pkcs11/pam_pkcs11.conf file is the configuration file for the pam_pkcs11 module. A user should modify this file to configure the pam_pkcs11 module. In this example, we will use default values for all the entries. - Copy the CA certificate to the /etc/security/pam_pkcs11/cacerts directory and make a hash link with the make_hash_link.sh script. Note: A certificate that is self-signed is its own CA certificate. Therefore, in this example, the certificate is placed both in the keystore and in the CA certificate directory. - Set up the map files in the /etc/security/pam_pkc11 directory. Note: When a X509 certificate is provided, there are no direct ways to map a certificate to a login. The pam_pkcs11 module provides a configurable way with mappers to specify cert-to-user mapping. Many mappers are provided by Pam_pkcs11, for example, the common name (CN) mapper, the digest mapper, the Email mapper, or the LDAP mapper. A user can configure a mapper list in the pam_pkcs11.conf file. The mappers in the list will be used sequentially until the certificate is successfully matched with the user. Some mappers do not require a mapfile to be specified (eg. the CN mapper), while some other mappers do require a mapfile (eg. the digest mapper) in the /etc/pam_pkcs11 directory. Configure the /etc/pam.conf file: The pam_pkcs11.so service module can be used in the PAM chain. In this example, we will use only pam_pkcs11 for authentication. login auth requisite pam_pkcs11.so.1 login auth required pam_unix_cred.so.1 Test: To test result, run "exec login" as below: -------------------------------------------------------------------- hylee@bula$exec login Please insert your smart card or enter your username. login: hylee found the PKCS#11 slot with a token. Welcome Sun Software PKCS#11 softtoken! token password: XXXXXXXX Last login: Tue Feb 26 14:13:41 from comforter Sun Microsystems Inc. SunOS 5.11 snv_80 Dec. 15, 2007 SunOS Internal Development: root 2007-12-15 [onnv_80] bfu'ed from /ws/onnv-gate/archives/sparc/snv_80 on 2007-12-19 Sun Microsystems Inc. SunOS 5.11 snv_76 October 2007 -------------------------------------------------------------------- --Boundary_(ID_D9QyvNR/YfYkAoXYLSlshQ)-- From gww@eng.sun.com Thu Mar 13 15:08:47 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DM8kGk017250 for ; Thu, 13 Mar 2008 15:08:47 -0700 (PDT) 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 m2DM8hwg004552 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 14 Mar 2008 06:08:45 +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 <0JXO00409W6IJZ00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 13 Mar 2008 16:08:42 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO000A0W6IZS30@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 13 Mar 2008 16:08:42 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DM8eWr046411; Thu, 13 Mar 2008 15:08:40 -0700 (PDT) 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 m2DN8iv7024074; Thu, 13 Mar 2008 15:08:44 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2DN8iNJ024073; Thu, 13 Mar 2008 15:08:44 -0800 (PST) Date: Thu, 13 Mar 2008 15:08:44 -0800 (PST) From: Gary Winiger Subject: Re: restart of PSARC/2006/283 Certificate & PKCS#11 PAM module To: Darren.Moffat@sun.com, Huie-Ying.Lee@sun.com, PSARC-EXT@sun.com Message-id: <200803132308.m2DN8iNJ024073@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 318 > Time out is set for Thursday 13th March 2008. Hopefully we can close on > this case this time. Yesterday, I asked to let this run through today. Unfortunately I've been bogged down in a quagmire. I'd like til Fri 14 Mar COB. I've updated the IAM since Darren seemed fine with the extension. Thankx, Gary.. From gww@eng.sun.com Fri Mar 14 17:02:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2F01xKY001186 for ; Fri, 14 Mar 2008 17:01:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2F01j71027899 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Sat, 15 Mar 2008 00:01:58 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 <0JXQ0050LW376I00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 14 Mar 2008 17:01:55 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXQ0057KW372100@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 14 Mar 2008 17:01:55 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2F01sZW034978; Fri, 14 Mar 2008 17:01:54 -0700 (PDT) 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 m2F120Lt026349; Fri, 14 Mar 2008 17:02:00 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2F120oh026348; Fri, 14 Mar 2008 17:02:00 -0800 (PST) Date: Fri, 14 Mar 2008 17:02:00 -0800 (PST) From: Gary Winiger Subject: Re: restart of PSARC/2006/283 Certificate & PKCS#11 PAM module To: Darren.Moffat@sun.com, Huie-Ying.Lee@sun.com, PSARC-EXT@sun.com, gww@eng.sun.com Message-id: <200803150102.m2F120oh026348@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3637 I've been struggling how to make my comments largely architectural and lead to convergence. It seems to me that I've been missing the boat on being clear. My primary concern lies with the completeness of the administrative documentation for Solaris and the stability of the interfaces. I've said this publically and privately more than once during this case. As I understand this project, it is intended to be a layer of the Solaris Core replacement for pam_smartcard(5). Though, not there yet because of missing infrastructure. Yet, all this case's components commitment levels appear to be Volatile and the details of the administrative documentation that the spec points to is on the community web site: www.opensc-project.org/pam_pkcs11 The materials pam_pcks11(5) man page seems to imply that will be cloned in /usr/share/doc/pam_pkcs11/* with really no change and delivered out of a separate package. While this is not part of the materials, it does address keeping documentation and code in sync that was a concern when the website was to be the definitive document. Does the majority of the committee have problems with a seemingly Volatile interface being a core component of system authentication? Not having the proposed .../doc/pam_pkcs11/* as part of the materials, I wonder if the user manual I've found on the website is really in the best for Solaris administration as it appears to me to be pretty exclusively aimed at Linux in describing configuration for pam_pkcs11. It also appears to strongly imply smartcard. (Which the case log claims this case is not to be about.) Other lesser concerns include: * The spec's frequent use of "A user" for performing configuration. * The introduction of new /etc files that seem security relevant with no auditable administrative interface. (See the Solaris Audit policy: http://opensolaris.org/os/community/arc/policies/audit-policy/) * The introduction of administrative CLIs that appear to be intended to be entered interactively from a shell into /usr/lib/pam_pkcs11/. * The introduction of an administrative CLI (shell script) that appears to be intended to be entered interactively from a shell in /etc/security/pam_pkcs11/ with a .sh suffix. * The lack of Rights Profiles if the CLIs require any special "rights" to properly execute. At least pkcs11_eventmgr(1) seems to be a service that would fit under SMF, though there seems to be no mention of SMF. See below for more on pkcs11_eventmgr. * The seemingly accurate example in the spec of a login dialogue that says: "Please insert your smart card or enter your username." (Nit, I presume this is a PAM_PROMPT_ECHO_ON message type. Does it meet the PAM Policy relative to localization? See http://opensolaris.org/os/community/arc/policies/PAM/) * The pam_pkcs11(5) man page primarily refers to www.opensc-project.org/pam_pkcs11/pam_pkcs11.html which presently replies: Error: Not Found I would have expected a SEE ALSO of some section is docs.sun.com. http://docs.sun.com/app/docs/doc/806-7010/intro.smartadmin-34?l=en&a=view&q=smartcard equivalent. * Nit: pam_pkcs11(5) shouldn't list command and man path names under the FILES: section. * Nit: pkcs11_eventmgr(1) claims "SmartCard PKCS#11 Event Manager" If this is true, and pam_pkcs11(5) doesn't support smartcards with this project, is the man page wrong, or should this CLI/man page not be delivered until the pam_smartcard(5) replacement project is integrated? If the majority of the members are not concerned, I'll not stand in the way of the current proposal. Gary.. From Mark.Carlson@Sun.COM Wed Mar 26 07:30:03 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QEU2cp025082 for ; Wed, 26 Mar 2008 07:30:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2QETv49005701 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 26 Mar 2008 22:30:01 +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 <0JYC00I05DLYBV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 26 Mar 2008 07:29:58 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYC0030KDLXMME0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 26 Mar 2008 07:29:58 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2QETvRf008941 for ; Wed, 26 Mar 2008 14:29:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYC00I01C9LKD00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 26 Mar 2008 08:29:57 -0600 (MDT) Received: from Macintosh-39.local ([206.170.30.2]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYC001FWDLKJ3G0@mail-amer.sun.com>; Wed, 26 Mar 2008 08:29:45 -0600 (MDT) Date: Wed, 26 Mar 2008 08:29:44 -0600 From: "Mark A. Carlson" Subject: Re: restart of PSARC/2006/283 Certificate & PKCS#11 PAM module In-reply-to: <200803150102.m2F120oh026348@marduk.eng.sun.com> Sender: Mark.Carlson@Sun.COM To: Gary Winiger Cc: Darren.Moffat@Sun.COM, Huie-Ying.Lee@Sun.COM, PSARC-ext@Sun.COM Message-id: <47EA5DD8.2020005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803150102.m2F120oh026348@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 3878 I have not seen a response to Gary's note. What is the status of this case? -- mark Gary Winiger wrote: > I've been struggling how to make my comments largely architectural > and lead to convergence. It seems to me that I've been missing the > boat on being clear. > > My primary concern lies with the completeness of the administrative > documentation for Solaris and the stability of the interfaces. I've > said this publically and privately more than once during this case. > As I understand this project, it is intended to be a layer of the Solaris > Core replacement for pam_smartcard(5). Though, not there yet because of > missing infrastructure. Yet, all this case's components commitment levels > appear to be Volatile and the details of the administrative documentation > that the spec points to is on the community web site: > www.opensc-project.org/pam_pkcs11 > The materials pam_pcks11(5) man page seems to imply that will be > cloned in /usr/share/doc/pam_pkcs11/* with really no change and > delivered out of a separate package. While this is not part of the > materials, it does address keeping documentation and code in sync that > was a concern when the website was to be the definitive document. > Does the majority of the committee have problems with a seemingly Volatile > interface being a core component of system authentication? > Not having the proposed .../doc/pam_pkcs11/* as part of the materials, > I wonder if the user manual I've found on the website is really in the best > for Solaris administration as it appears to me to be pretty exclusively aimed > at Linux in describing configuration for pam_pkcs11. It also appears to > strongly imply smartcard. (Which the case log claims this case is not to > be about.) > > Other lesser concerns include: > * The spec's frequent use of "A user" for performing configuration. > * The introduction of new /etc files that seem security relevant > with no auditable administrative interface. (See the Solaris > Audit policy: > http://opensolaris.org/os/community/arc/policies/audit-policy/) > * The introduction of administrative CLIs that appear to be intended > to be entered interactively from a shell into /usr/lib/pam_pkcs11/. > * The introduction of an administrative CLI (shell script) that > appears to be intended to be entered interactively from a shell > in /etc/security/pam_pkcs11/ with a .sh suffix. > * The lack of Rights Profiles if the CLIs require any special "rights" > to properly execute. At least pkcs11_eventmgr(1) seems to > be a service that would fit under SMF, though there seems to be > no mention of SMF. See below for more on pkcs11_eventmgr. > * The seemingly accurate example in the spec of a login dialogue > that says: > "Please insert your smart card or enter your username." > (Nit, I presume this is a PAM_PROMPT_ECHO_ON message type. Does > it meet the PAM Policy relative to localization? See > http://opensolaris.org/os/community/arc/policies/PAM/) > * The pam_pkcs11(5) man page primarily refers to > www.opensc-project.org/pam_pkcs11/pam_pkcs11.html > which presently replies: > Error: Not Found > I would have expected a SEE ALSO of some section is docs.sun.com. > http://docs.sun.com/app/docs/doc/806-7010/intro.smartadmin-34?l=en&a=view&q=smartcard > equivalent. > * Nit: pam_pkcs11(5) shouldn't list command and man path names > under the FILES: section. > * Nit: pkcs11_eventmgr(1) claims "SmartCard PKCS#11 Event Manager" > If this is true, and pam_pkcs11(5) doesn't support smartcards > with this project, is the man page wrong, or should this > CLI/man page not be delivered until the pam_smartcard(5) > replacement project is integrated? > > If the majority of the members are not concerned, I'll not stand in the > way of the current proposal. > > Gary.. > From wyllys.ingersoll@sun.com Wed Mar 26 08:45:35 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QFjZNf027972 for ; Wed, 26 Mar 2008 08:45:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2QFjWIS001696; Wed, 26 Mar 2008 08:45:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYC0043HH3WSF00@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Mar 2008 08:45:32 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYC001AXH3SWRA0@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Mar 2008 08:45:28 -0700 (PDT) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2QFjQp2411474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 08:45:27 -0700 (PDT) Date: Wed, 26 Mar 2008 11:45:24 -0400 From: Wyllys Ingersoll Subject: Re: [kmf-discuss] restart of PSARC/2006/283 Certificate & PKCS#11 PAM module In-reply-to: <47EA5DD8.2020005@sun.com> To: "Mark A. Carlson" Cc: Gary Winiger , Huie-Ying.Lee@sun.com, PSARC-ext@sun.com Message-id: <47EA6F94.9050304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803150102.m2F120oh026348@marduk.eng.sun.com> <47EA5DD8.2020005@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080115) Status: RO Content-Length: 6229 Gary - Your issues seem to be around the documentation and the commitment levels. As has been mentioned numerous times, this is open-source code that is being brought into Solaris at the request of a large customer and the team needs to keep it as familiar as possible. Also, as Darren mentioned, the Volatile level is necessary so we can address the name mapping issues later (currently under design). > Gary Winiger wrote: > >> I've been struggling how to make my comments largely architectural >> and lead to convergence. It seems to me that I've been missing the >> boat on being clear. >> >> My primary concern lies with the completeness of the administrative >> documentation for Solaris and the stability of the interfaces. I've >> said this publically and privately more than once during this case. >> As I understand this project, it is intended to be a layer of the Solaris >> Core replacement for pam_smartcard(5). Though, not there yet because of >> missing infrastructure. Yet, all this case's components commitment levels >> appear to be Volatile and the details of the administrative documentation >> that the spec points to is on the community web site: >> www.opensc-project.org/pam_pkcs11 >> The materials pam_pcks11(5) man page seems to imply that will be >> cloned in /usr/share/doc/pam_pkcs11/* with really no change and >> delivered out of a separate package. While this is not part of the >> materials, it does address keeping documentation and code in sync that >> was a concern when the website was to be the definitive document. >> Does the majority of the committee have problems with a seemingly Volatile >> interface being a core component of system authentication? >> I don't have a problem with it, but I'm only an "intern". >> Not having the proposed .../doc/pam_pkcs11/* as part of the materials, >> I wonder if the user manual I've found on the website is really in the best >> for Solaris administration as it appears to me to be pretty exclusively aimed >> at Linux in describing configuration for pam_pkcs11. It also appears to >> strongly imply smartcard. (Which the case log claims this case is not to >> be about.) >> Whoever wrote the Linux docs incorrectly assumed that "smartcard" == "pkcs11 token". A smartcard is but one example of a pk11 token, it could also include the keystore on an SCA6000 or even a TPM (for example). Yes, the current docs on the website suck, but creating a whole new set of Solaris specific docs for an already existing open source project should not be a requirement for this project team. Perhaps the project team could drop an email to the open source maintainers with suggested changes to the docs at some point AFTER this project goes into Solaris along with the rest of the changes they have already agreed to try and give back. >> Other lesser concerns include: >> * The spec's frequent use of "A user" for performing configuration. >> * The introduction of new /etc files that seem security relevant >> with no auditable administrative interface. (See the Solaris >> Audit policy: >> http://opensolaris.org/os/community/arc/policies/audit-policy/) >> Is it common that we impose our auditing policies on all open source based projects for administering configuration files? We have lots of configuration files that have security implications that do not have auditable admin interfaces - ssh_config, sshd_config, krb5.conf, kdc.conf, just to name a few. >> * The introduction of administrative CLIs that appear to be intended >> to be entered interactively from a shell into /usr/lib/pam_pkcs11/. >> Isn't this just following the precedent from the Linux version? If so, then it should be OK since we are now trying to make Solaris more "Linux-Friendly". >> * The introduction of an administrative CLI (shell script) that >> appears to be intended to be entered interactively from a shell >> in /etc/security/pam_pkcs11/ with a .sh suffix. >> * The lack of Rights Profiles if the CLIs require any special "rights" >> to properly execute. At least pkcs11_eventmgr(1) seems to >> be a service that would fit under SMF, though there seems to be >> no mention of SMF. See below for more on pkcs11_eventmgr. >> Putting it under SMF could be a follow-up RFE if the customer or someone else feels strongly that it would be beneficial, but I dont think it should be a barrier to approval for this project since they are trying hard to follow the current open source model and that is what the customer is expecting. If the customer has a team of admins that are used to the current model, it will only serve to annoy them if we move things to SMF and say "but, its Better this way!" >> * The seemingly accurate example in the spec of a login dialogue >> that says: >> "Please insert your smart card or enter your username." >> (Nit, I presume this is a PAM_PROMPT_ECHO_ON message type. Does >> it meet the PAM Policy relative to localization? See >> http://opensolaris.org/os/community/arc/policies/PAM/) >> * The pam_pkcs11(5) man page primarily refers to >> www.opensc-project.org/pam_pkcs11/pam_pkcs11.html >> which presently replies: >> Error: Not Found >> I would have expected a SEE ALSO of some section is docs.sun.com. >> http://docs.sun.com/app/docs/doc/806-7010/intro.smartadmin-34?l=en&a=view&q=smartcard >> equivalent. >> * Nit: pam_pkcs11(5) shouldn't list command and man path names >> under the FILES: section. >> * Nit: pkcs11_eventmgr(1) claims "SmartCard PKCS#11 Event Manager" >> If this is true, and pam_pkcs11(5) doesn't support smartcards >> with this project, is the man page wrong, or should this >> CLI/man page not be delivered until the pam_smartcard(5) >> replacement project is integrated? >> It sounds like an overly-specific man page. Just remove the "SmartCard" part and it would probably be more accurate as "PKCS#11 Event Manager". This is definitely a nit. >> If the majority of the members are not concerned, I'll not stand in the >> way of the current proposal. >> IMO, this case has languished for too long and needs to move forward ASAP. -Wyllys From bart.smaalders@Sun.COM Wed Mar 26 10:48:36 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QHmZvr005531 for ; Wed, 26 Mar 2008 10:48:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2QHmXeG004706; Wed, 26 Mar 2008 11:48:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYC00B0LMSYU300@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Mar 2008 10:48:34 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYC003CNMSXOY80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Mar 2008 10:48:33 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2QHmXj4751495; Wed, 26 Mar 2008 17:48:33 +0000 (GMT) Date: Wed, 26 Mar 2008 10:48:32 -0700 From: Bart Smaalders Subject: Re: [kmf-discuss] restart of PSARC/2006/283 Certificate & PKCS#11 PAM module In-reply-to: <47EA6F94.9050304@sun.com> To: Gary Winiger Cc: Wyllys Ingersoll , "Mark A. Carlson" , Huie-Ying.Lee@Sun.COM, PSARC-ext@Sun.COM Message-id: <47EA8C70.905@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803150102.m2F120oh026348@marduk.eng.sun.com> <47EA5DD8.2020005@sun.com> <47EA6F94.9050304@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 1157 Wyllys Ingersoll wrote: >>> Other lesser concerns include: >>> * The spec's frequent use of "A user" for performing configuration. >>> * The introduction of new /etc files that seem security relevant >>> with no auditable administrative interface. (See the Solaris >>> Audit policy: >>> http://opensolaris.org/os/community/arc/policies/audit-policy/) >>> > > Is it common that we impose our auditing policies on all open source > based projects for administering configuration files? We have lots of > configuration files that have security implications that do not have > auditable admin interfaces - ssh_config, sshd_config, krb5.conf, > kdc.conf, just to name a few. Gary - How does a project satisfy this requirement? Suppose my project "foo" introduces a new file in /etc that is deemed to be security related. Beside the facilities already provided by Solaris auditing, what additional work should I do to track edits by vi, vim, etc? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From huie-ying.lee@sun.com Wed Mar 26 16:53:51 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QNroGN020366 for ; Wed, 26 Mar 2008 16:53:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2QNrk6R013834 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 26 Mar 2008 23:53: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 <0JYD00L013PNBX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 26 Mar 2008 16:53:47 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYD00H1X3PM2Q50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 26 Mar 2008 16:53:46 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2QNrkkW027286; Wed, 26 Mar 2008 16:53:46 -0700 (PDT) Received: from [129.146.108.12] (comforter.SFBay.Sun.COM [129.146.108.12]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m2QNrj709248; Wed, 26 Mar 2008 16:53:45 -0700 (PDT) Date: Wed, 26 Mar 2008 16:52:01 -0700 From: Huie-Ying Lee Subject: Re: [kmf-discuss] restart of PSARC/2006/283 Certificate & PKCS#11 PAM module In-reply-to: <47EA6F94.9050304@sun.com> To: Wyllys Ingersoll Cc: "Mark A. Carlson" , Gary Winiger , PSARC-ext@sun.com Message-id: <47EAE1A1.60405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803150102.m2F120oh026348@marduk.eng.sun.com> <47EA5DD8.2020005@sun.com> <47EA6F94.9050304@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 7058 Wyllys Ingersoll wrote: > > Gary - > Your issues seem to be around the documentation and the commitment > levels. As has been mentioned numerous times, this is open-source code > that is being brought into Solaris at the request of a large customer > and the > team needs to keep it as familiar as possible. > > Also, as Darren mentioned, the Volatile level is necessary so we can > address the > name mapping issues later (currently under design). > > >> Gary Winiger wrote: >> >>> I've been struggling how to make my comments largely architectural >>> and lead to convergence. It seems to me that I've been missing the >>> boat on being clear. >>> >>> My primary concern lies with the completeness of the administrative >>> documentation for Solaris and the stability of the interfaces. I've >>> said this publically and privately more than once during this case. >>> As I understand this project, it is intended to be a layer of the >>> Solaris >>> Core replacement for pam_smartcard(5). Though, not there yet because of >>> missing infrastructure. Yet, all this case's components commitment >>> levels >>> appear to be Volatile and the details of the administrative >>> documentation >>> that the spec points to is on the community web site: >>> www.opensc-project.org/pam_pkcs11 >>> The materials pam_pcks11(5) man page seems to imply that will be >>> cloned in /usr/share/doc/pam_pkcs11/* with really no change and >>> delivered out of a separate package. While this is not part of the >>> materials, it does address keeping documentation and code in sync that >>> was a concern when the website was to be the definitive document. >>> Does the majority of the committee have problems with a seemingly >>> Volatile >>> interface being a core component of system authentication? >>> > > I don't have a problem with it, but I'm only an "intern". > > >>> Not having the proposed .../doc/pam_pkcs11/* as part of the materials, >>> I wonder if the user manual I've found on the website is really in >>> the best >>> for Solaris administration as it appears to me to be pretty >>> exclusively aimed >>> at Linux in describing configuration for pam_pkcs11. It also appears to >>> strongly imply smartcard. (Which the case log claims this case is >>> not to >>> be about.) >>> > > Whoever wrote the Linux docs incorrectly assumed that "smartcard" == > "pkcs11 token". > A smartcard is but one example of a pk11 token, it could also include > the keystore on > an SCA6000 or even a TPM (for example). Yes, the current docs on the > website suck, > but creating a whole new set of Solaris specific docs for an already > existing open source project > should not be a requirement for this project team. Perhaps the project > team could drop > an email to the open source maintainers with suggested changes to the > docs at some point AFTER > this project goes into Solaris along with the rest of the changes they > have already agreed to > try and give back. > > Right. I have actually started contacting the current open source maintainers and I will make sure to air our concerns about quality of document issues to them. >>> Other lesser concerns include: >>> * The spec's frequent use of "A user" for performing configuration. >>> * The introduction of new /etc files that seem security relevant >>> with no auditable administrative interface. (See the Solaris >>> Audit policy: >>> http://opensolaris.org/os/community/arc/policies/audit-policy/) >>> > > Is it common that we impose our auditing policies on all open source > based projects for > administering configuration files? We have lots of configuration files > that have security > implications that do not have auditable admin interfaces - ssh_config, > sshd_config, krb5.conf, > kdc.conf, just to name a few. > >>> * The introduction of administrative CLIs that appear to be intended >>> to be entered interactively from a shell into >>> /usr/lib/pam_pkcs11/. >>> > > Isn't this just following the precedent from the Linux version? If so, > then it should be OK since we are now > trying to make Solaris more "Linux-Friendly". > > >>> * The introduction of an administrative CLI (shell script) that >>> appears to be intended to be entered interactively from a shell >>> in /etc/security/pam_pkcs11/ with a .sh suffix. >>> * The lack of Rights Profiles if the CLIs require any special >>> "rights" >>> to properly execute. At least pkcs11_eventmgr(1) seems to >>> be a service that would fit under SMF, though there seems to be >>> no mention of SMF. See below for more on pkcs11_eventmgr. >>> > > Putting it under SMF could be a follow-up RFE if the customer or someone > else feels strongly that it would be > beneficial, but I dont think it should be a barrier to approval for this > project since they are trying hard to follow > the current open source model and that is what the customer is > expecting. If the customer has a team > of admins that are used to the current model, it will only serve to > annoy them if we move things to > SMF and say "but, its Better this way!" > > >>> * The seemingly accurate example in the spec of a login dialogue >>> that says: >>> "Please insert your smart card or enter your username." >>> (Nit, I presume this is a PAM_PROMPT_ECHO_ON message type. Does >>> it meet the PAM Policy relative to localization? See >>> http://opensolaris.org/os/community/arc/policies/PAM/) >>> * The pam_pkcs11(5) man page primarily refers to >>> www.opensc-project.org/pam_pkcs11/pam_pkcs11.html >>> which presently replies: >>> Error: Not Found >>> I would have expected a SEE ALSO of some section is docs.sun.com. >>> http://docs.sun.com/app/docs/doc/806-7010/intro.smartadmin-34?l=en&a=view&q=smartcard >>> >>> equivalent. >>> * Nit: pam_pkcs11(5) shouldn't list command and man path names >>> under the FILES: section. I will remove the command and man path names undeer the FILES: section from the pam_pkcs11(5) man page. >>> * Nit: pkcs11_eventmgr(1) claims "SmartCard PKCS#11 Event Manager" >>> If this is true, and pam_pkcs11(5) doesn't support smartcards >>> with this project, is the man page wrong, or should this >>> CLI/man page not be delivered until the pam_smartcard(5) >>> replacement project is integrated? >>> > > It sounds like an overly-specific man page. Just remove the "SmartCard" > part and it would > probably be more accurate as "PKCS#11 Event Manager". This is definitely > a nit. > After careful investigation, I found the pkcs11_eventmgr command is actually not useful at all. I would like to remove it from the deliverables. > >>> If the majority of the members are not concerned, I'll not stand in the >>> way of the current proposal. >>> > > IMO, this case has languished for too long and needs to move forward ASAP. > > -Wyllys > Thanks, Huie-Ying From gdamore@sun.com Thu Apr 3 11:26:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33IQD2n027529 for ; Thu, 3 Apr 2008 11:26:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m33IQ1gQ011385 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 3 Apr 2008 19:26:12 +0100 (BST) 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 <0JYR00H2THVNA900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 12:26:11 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR0072XHVLFKC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 12:26:09 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33IQ4tn004423 for ; Thu, 03 Apr 2008 11:26:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYR00401D0RSX00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 11:26:04 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYR00665HV9WAG0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 11:25:58 -0700 (PDT) Date: Thu, 03 Apr 2008 11:22:19 -0700 From: "Garrett D'Amore" Subject: PSARC 2006/283 Certificate & PKCS#11 PAM, module Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <47F5205B.9020405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2869 As promised at yesterday's meeting, I've reviewed the materials. I have to admit, I independently came to many of the same conclusions as Gary, even before I got to the point of Gary's mail when reading the mail log. I believe that this case *again* underscores the FOSS-induced schizophrenia we seem to be suffering from in ARC. I've noted that separately in detail on arc-discuss, and fervently hope someone senior to take corrective action will do so. But that's not a matter to solve for this case, I think. Furthermore, I find the justification of a "single large customer wants X, and is happy with our implementation" to be a poor substitute for proper architecture. This isn't the same as saying we should not ship the product. We need a way to deliver the bits to the "large customer", without sacrificing on our architecture. I think the project team *should* try to find out if there is a way to deliver bits to the requiring customer as either a "beta test", or "unbundled product", until such time as we are able to resolve the architectural issues and deliver a "first class" implementation. Failing that, if this is to go into Solaris/Nevada/Indiana/whatever-we-are-calling-it-now, we need to way to identify that this solution is still under development, and probably not ready for prime-time use by most customers. Marking everything in the case Volatile, may be a way to do that. (Actually, it seems we need a new taxonomy, perhaps "Experimental" or somesuch...) Cautions in the documentation that the product (or the Solaris integration of the product) is still evolving (along with perhaps known limitations, such as lack of auditable administration) could go a long way to help here. I do *not* believe that it will be feasible to replace the existing smart card framework *until* the considerations that Gary has raised are addressed. In particular, the product *must* have proper Sun-quality documentation, must support the various Big Rules (including auditable administration), and *should* address those fit-and-finish issues (e.g. the make_hash_links.sh script to configure this feels like an awful hack). If the product can be unbundled for said large customer, or can be marked Volatile (with appropriate cautions in the docs), then I have no qualms about approving the project. (I *greatly* prefer an unbundled or Value-Add package, with a reduced level of stability commitment.) It will then be incumbent on the team integrating the smart card pkcs11 module to address these issues required to provide "proper" architecture. The other alternative is to derail the case so that we can issue TCRs or TCAs to this case. I don't feel strongly enough to derail on my own here, although I would be supportive of such an action if another member decided that was appropriate. -- Garrett From Mark.Carlson@sun.com Thu Apr 3 12:56:49 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33JumY6001344 for ; Thu, 3 Apr 2008 12:56:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m33JuiVq014417 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 4 Apr 2008 03:56:47 +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 <0JYR00C01M2MQ600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 12:56:46 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR0063KM2MCAC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 12:56:46 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m33Jujgl008504 for ; Thu, 03 Apr 2008 19:56:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYR00801LD2VO00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 13:56:45 -0600 (MDT) Received: from boulder-dhcp-224.Central.Sun.COM ([172.20.24.224]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYR009HCM2JP920@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 13:56:44 -0600 (MDT) Date: Thu, 03 Apr 2008 13:56:42 -0600 From: "Mark A. Carlson" Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5205B.9020405@sun.com> Sender: Mark.Carlson@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <47F5367A.6060002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 336 Garrett, I see this kind of phrasing a lot lately. Let's go ahead and derail then. Count me as "supportive of such action" as chair. -- mark Garrett D'Amore wrote: > ... I don't feel strongly enough to derail on my own > here, although I would be supportive of such an action if another member > decided that was appropriate. > From wyllys.ingersoll@sun.com Thu Apr 3 13:09:18 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33K9IuA001509 for ; Thu, 3 Apr 2008 13:09:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m33K9HxN009410; Thu, 3 Apr 2008 13:09:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYR0060JMNH7I00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Apr 2008 13:09:17 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR00DOYMNG60D0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Apr 2008 13:09:16 -0700 (PDT) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m33K9E6d482939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 03 Apr 2008 13:09:15 -0700 (PDT) Date: Thu, 03 Apr 2008 16:09:14 -0400 From: Wyllys Ingersoll Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5367A.6060002@sun.com> To: "Mark A. Carlson" Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47F5396A.7070201@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080115) Status: RO Content-Length: 1348 I disagree. For many weeks now the submitter has answered the questions and made all of the corrective actions requested by the ARC on this case and now there is talk of derailing it? I don't think any architectural issues were found with the project. The documentation is weak, but the submitter has agreed to work with the open source group that owns it to address the doc issues. The "auditable administration" question was answered already - there is no auditable interface for any PAM configuration files or any other files that are managed via "vi" (or whatever editor) for that matter. Discussions over how best to merge FOSS and ARC needs is something that should be discussed outside of this case. The project team has been playing fetch-a-rock for too long. The final specs have been submitted, I think Darren is planning on putting them in the case dir very soon. This case should be approved so the team can move ahead. -Wyllys Mark A. Carlson wrote: > Garrett, > > I see this kind of phrasing a lot lately. Let's go ahead and derail then. > Count me as "supportive of such action" as chair. > > -- mark > > Garrett D'Amore wrote: >> ... I don't feel strongly enough to derail on my own here, although I >> would be supportive of such an action if another member decided that >> was appropriate. >> From Nicolas.Williams@sun.com Thu Apr 3 13:38:47 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33Kckal001750 for ; Thu, 3 Apr 2008 13:38:47 -0700 (PDT) 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 m33KcFIg000636; Fri, 4 Apr 2008 04:38:42 +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 <0JYR00301O0H9700@brm-avmta-1.central.sun.com>; Thu, 03 Apr 2008 14:38:41 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR00LWXO0GNG30@brm-avmta-1.central.sun.com>; Thu, 03 Apr 2008 14:38:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m33Kca6Q003422; Thu, 03 Apr 2008 15:38:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m33KcarS003421; Thu, 03 Apr 2008 15:38:36 -0500 (CDT) Date: Thu, 03 Apr 2008 15:38:36 -0500 From: Nicolas Williams Subject: Re: [kmf-discuss] restart of PSARC/2006/283 Certificate & PKCS#11 PAM module In-reply-to: <47EA8C70.905@Sun.COM> To: Bart Smaalders Cc: Gary Winiger , Wyllys Ingersoll , "Mark A. Carlson" , Huie-Ying.Lee@sun.com, PSARC-ext@sun.com Mail-followup-to: Bart Smaalders , Gary Winiger , Wyllys Ingersoll , "Mark A. Carlson" , Huie-Ying.Lee@sun.com, PSARC-ext@sun.com Message-id: <20080403203836.GE16998@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200803150102.m2F120oh026348@marduk.eng.sun.com> <47EA5DD8.2020005@sun.com> <47EA6F94.9050304@sun.com> <47EA8C70.905@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1148 On Wed, Mar 26, 2008 at 10:48:32AM -0700, Bart Smaalders wrote: > Wyllys Ingersoll wrote: > >>>Other lesser concerns include: > >>> * The spec's frequent use of "A user" for performing configuration. > >>> * The introduction of new /etc files that seem security relevant > >>> with no auditable administrative interface. (See the Solaris > >>> Audit policy: > >>> http://opensolaris.org/os/community/arc/policies/audit-policy/) > >>> > > > >Is it common that we impose our auditing policies on all open source > >based projects for administering configuration files? We have lots of > >configuration files that have security implications that do not have > >auditable admin interfaces - ssh_config, sshd_config, krb5.conf, > >kdc.conf, just to name a few. > > Gary - > > How does a project satisfy this requirement? Suppose my project > "foo" introduces a new file in /etc that is deemed to be security > related. Beside the facilities already provided by Solaris auditing, > what additional work should I do to track edits by vi, vim, etc? I think the answer is: include a CLI for administering the configuration. From gdamore@sun.com Thu Apr 3 14:00:32 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33L0WsV002272 for ; Thu, 3 Apr 2008 14:00:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m33L0Vgb011038 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 3 Apr 2008 15:00:32 -0600 (MDT) 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 <0JYR00417P0VRM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 15:00:31 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR00LQFP0UNN40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 15:00:31 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33L0UOK023843 for ; Thu, 03 Apr 2008 14:00:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYR00I01OJ9RV00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 14:00:30 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYR00C0KP0S0A80@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 14:00:29 -0700 (PDT) Date: Thu, 03 Apr 2008 13:56:48 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5396A.7070201@sun.com> Sender: Garrett.Damore@sun.com To: Wyllys Ingersoll Cc: "Mark A. Carlson" , psarc-ext@sun.com Message-id: <47F54490.1010808@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3575 Wyllys Ingersoll wrote: > > I disagree. For many weeks now the submitter has answered the > questions and made all of the corrective actions requested by the ARC > on this case and now there is talk of derailing it? I don't think > any architectural issues were found with the project. The > documentation is weak, but the submitter has agreed to work with the > open source group that owns it to address the doc issues. That's not the same as "fixing" the documentation prior to delivery. What if the upstream group doesn't want the doc fixes? What if it takes too long? The revised documentation is not "supplied" here, so we can only review based on the documentation that was in the case materials. > The "auditable administration" question was answered already - there > is no auditable interface for any PAM configuration files or any other > files that are managed via "vi" (or whatever editor) for that matter. I didn't see the answer in the mail log. Managing files via "vi" is certainly possible, but it isn't clear to me that "vi" is the solution for system administration. "vi" can't be audited, so its reasonable that a CLI be provided which *can* be audited, and also "controlled" via RBAC. All in all, the setup and administration of this subsystem seems very half-baked to me. While this is fine for the wild and woolly world of Linux, I'm not sure it's appropriate for Enterprise Grade Solaris. (The fact that maybe the powers-that-be may (or may not) have decided to abandon Enterprise Grade Solaris in favor of Web-2.0-RedShift-Indiana is beside the point. We -- meaning PSARC -- haven't been given any guidance yet that we should change the criteria by which we review projects Or if we have, I'm unaware of it.) > > Discussions over how best to merge FOSS and ARC needs is something > that should be discussed outside of this case. Yes, although this case, and ones like it, seem to be justifying a reduced level of review/requirements based almost solely on the fact that the code is FOSS. I am not aware of any precedent or guidance for handling FOSS with reduced requirements at ARC. Perhaps there is an unstated (and unsubmitted?) case dependency here -- this case dependent on some kind of precedent decision or other case indicating that it's okay to skip or waive normal architectural rules for FOSS. Anyway, there is a reason that I raised that issue *separately* on arc-discuss. > The project team has been playing fetch-a-rock for too long. The > final specs have been submitted, I think Darren is planning on putting > them in the case dir very soon. This case should be approved so the > team can move ahead. As I indicated earlier, if the pressure is one particular customer, why not send binary relief to that one customer, while the project team works to fully address concerns to make this bit of software up to the same quality (and I'm not just talking about code quality/robustness here -- but also supporting documentation, adherence to Big Rules, and fit-and-finish issues of the kind we normally require for Sun-developed software. -- Garrett > > -Wyllys > > > > > Mark A. Carlson wrote: >> Garrett, >> >> I see this kind of phrasing a lot lately. Let's go ahead and derail >> then. >> Count me as "supportive of such action" as chair. >> >> -- mark >> >> Garrett D'Amore wrote: >>> ... I don't feel strongly enough to derail on my own here, although >>> I would be supportive of such an action if another member decided >>> that was appropriate. >>> > From Nicolas.Williams@sun.com Thu Apr 3 14:18:45 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33LIjuV003664 for ; Thu, 3 Apr 2008 14:18:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m33LIi2S016578; Thu, 3 Apr 2008 15:18:44 -0600 (MDT) 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 <0JYR0060DPV60H00@brm-avmta-1.central.sun.com>; Thu, 03 Apr 2008 15:18:42 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR00LY1PV5NQ50@brm-avmta-1.central.sun.com>; Thu, 03 Apr 2008 15:18:41 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m33LIfRk003504; Thu, 03 Apr 2008 16:18:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m33LIf8D003503; Thu, 03 Apr 2008 16:18:41 -0500 (CDT) Date: Thu, 03 Apr 2008 16:18:41 -0500 From: Nicolas Williams Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F54490.1010808@sun.com> To: "Garrett D'Amore" Cc: Wyllys Ingersoll , "Mark A. Carlson" , psarc-ext@sun.com Mail-followup-to: Garrett D'Amore , Wyllys Ingersoll , "Mark A. Carlson" , psarc-ext@sun.com Message-id: <20080403211840.GH16998@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F54490.1010808@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1560 On Thu, Apr 03, 2008 at 01:56:48PM -0700, Garrett D'Amore wrote: > >The project team has been playing fetch-a-rock for too long. The > >final specs have been submitted, I think Darren is planning on putting > >them in the case dir very soon. This case should be approved so the > >team can move ahead. > > As I indicated earlier, if the pressure is one particular customer, why > not send binary relief to that one customer, while the project team > works to fully address concerns to make this bit of software up to the > same quality (and I'm not just talking about code quality/robustness > here -- but also supporting documentation, adherence to Big Rules, and > fit-and-finish issues of the kind we normally require for Sun-developed > software. Because then they can't get support through normal channels (e.g., by filing a bug via opensolaris.org). I don't see the problem with having different levels of support for native features, well-integrated and not-so-well-integrated third party features. The fact that this case came to the ARC says noone is avoiding the SDF, so talk of lower review requirements seems unwarranted. OTOH, I think the i-team is asking for lower architectural requirements, as many a FOSS integration case seem to lately. I think a warning in the manpage about volatility of the interfaces and lack of complete integration should suffice. But when the project team comes back to complete the pam_smartcard replacement then all these issues should be addressed (i.e., I agree with Gary's comments). Nico -- From gdamore@sun.com Thu Apr 3 15:22:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33MMOa8004788 for ; Thu, 3 Apr 2008 15:22:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m33MMNT8010382 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 Apr 2008 06:22:23 +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 <0JYR00H01STARE00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 15:22:22 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR00E8ESTAOR50@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 15:22:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33MMMIN024299 for ; Thu, 03 Apr 2008 15:22:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYR00701SP1Q200@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 15:22:22 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYR00B0IST62M00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 15:22:18 -0700 (PDT) Date: Thu, 03 Apr 2008 15:18:37 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <20080403211840.GH16998@Sun.COM> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore" , Wyllys Ingersoll , "Mark A. Carlson" , PSARC-ext@sun.com Message-id: <47F557BD.3080403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F54490.1010808@sun.com> <20080403211840.GH16998@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3150 Nicolas Williams wrote: > On Thu, Apr 03, 2008 at 01:56:48PM -0700, Garrett D'Amore wrote: > >>> The project team has been playing fetch-a-rock for too long. The >>> final specs have been submitted, I think Darren is planning on putting >>> them in the case dir very soon. This case should be approved so the >>> team can move ahead. >>> >> As I indicated earlier, if the pressure is one particular customer, why >> not send binary relief to that one customer, while the project team >> works to fully address concerns to make this bit of software up to the >> same quality (and I'm not just talking about code quality/robustness >> here -- but also supporting documentation, adherence to Big Rules, and >> fit-and-finish issues of the kind we normally require for Sun-developed >> software. >> > > Because then they can't get support through normal channels (e.g., by > filing a bug via opensolaris.org). > There are a lot of unbundled products that have never been reviewed, or are reviewed with different constraints (Sun Ray anyone? Or historically, the various extra drivers such as Alternate Pathing, FDDI, HSI/P, etc.) I don't think support == ARC review == integration into ON (or even Solaris). It *may* be true that the group doing support may have to be the project team, rather than RPE. But while the team is actively working on the project, this seems not unreasonable. > I don't see the problem with having different levels of support for > native features, well-integrated and not-so-well-integrated third party > features. The fact that this case came to the ARC says noone is > avoiding the SDF, so talk of lower review requirements seems > unwarranted. OTOH, I think the i-team is asking for lower architectural > requirements, as many a FOSS integration case seem to lately. > Agreed. > I think a warning in the manpage about volatility of the interfaces and > lack of complete integration should suffice. But when the project team > comes back to complete the pam_smartcard replacement then all these > issues should be addressed (i.e., I agree with Gary's comments). > I think that is what I originally suggested, though I did say that derailing in order to offer the advice needed might be another reasonable option. Mark took that option, and I support his decision. I didn't feel strongly enough to derail on my own. Now the good news about this case getting derailed, is that unlike other recent cases which were also derailed, this one seems unlikely to abandon the project just because the case was derailed. Which means that ARC will finally have a chance to write an opinion and maybe set some precedent. Furthermore, it may bring the harsh light of day directly to bear on the problem that the ARC has been having sorting out these different review requirements. If an important case is held up because we lack adequate direction to properly review it, then maybe the folks that need to help us find that direction will recognize that their leadership here is required. Wandering aimlessly doesn't seem to be working too well.... -- Garrett From bart.smaalders@sun.com Thu Apr 3 20:36:38 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m343abPa012913 for ; Thu, 3 Apr 2008 20:36:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m343aTao005911; Fri, 4 Apr 2008 11:36:34 +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 <0JYS007017CWXZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Apr 2008 20:36:32 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS00EYV7CVYZD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Apr 2008 20:36:32 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m343aVXU029634; Fri, 04 Apr 2008 03:36:31 +0000 (GMT) Date: Thu, 03 Apr 2008 20:36:31 -0700 From: Bart Smaalders Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5205B.9020405@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <47F5A23F.1040802@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 636 Garrett D'Amore wrote: > must support the various Big Rules (including auditable administration), I asked Gary this question, but he declined to answer: What project satisfies this big Rule today? If my project introduced a config file in /etc/, how could I meet this big rule? If we cannot articulate this, this isn't a rule - it's a vague wish that other people will do our work for us, and as such is _toxic_ behavior, esp. by sitting ARC members. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Alan.Coopersmith@sun.com Thu Apr 3 21:00:50 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3440ox2013370 for ; Thu, 3 Apr 2008 21:00:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3440jSP020304; Thu, 3 Apr 2008 21:00:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYS009078HDUH00@nwk-avmta-2.sfbay.sun.com>; Thu, 03 Apr 2008 21:00:49 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS006K58HCVW10@nwk-avmta-2.sfbay.sun.com>; Thu, 03 Apr 2008 21:00:48 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3440mom012951; Thu, 03 Apr 2008 21:00:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYS009018B31G00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Thu, 03 Apr 2008 21:00:48 -0700 (PDT) Received: from [10.6.102.118] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYS00FW68HC9360@fe-sfbay-09.sun.com>; Thu, 03 Apr 2008 21:00:48 -0700 (PDT) Date: Thu, 03 Apr 2008 21:04:24 -0700 From: Alan Coopersmith Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5A23F.1040802@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Bart Smaalders Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47F5A8C8.1040307@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 894 Bart Smaalders wrote: > Garrett D'Amore wrote: > >> must support the various Big Rules (including auditable administration), > > I asked Gary this question, but he declined to answer: > > What project satisfies this big Rule today? SMF. > If my project introduced a config file in /etc/, how could I meet this > big rule? You could provide a fooconfig command, or plugin to some administration toolset (if we had one with a future, unlike smc), but many projects don't, which is why new config files in /etc were banned by the SMF policy. Of course, like most big rules & SAC policies, we only apply to new projects, and the trivial way to be exempted is to leave the old code untouched and not come back to ARC with any enhancements, effectively encouraging stagnation. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Thu Apr 3 21:47:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m344l1Ki013821 for ; Thu, 3 Apr 2008 21:47:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m344kvQQ011708; Fri, 4 Apr 2008 05:46:58 +0100 (BST) 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 <0JYS00H0HAM8UY00@brm-avmta-1.central.sun.com>; Thu, 03 Apr 2008 22:46:56 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS002E1AM7VM80@brm-avmta-1.central.sun.com>; Thu, 03 Apr 2008 22:46:55 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m344ktYA013989; Thu, 03 Apr 2008 21:46:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYS00101AJJNC00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Thu, 03 Apr 2008 21:46:55 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYS00FQRAM493C0@fe-sfbay-09.sun.com>; Thu, 03 Apr 2008 21:46:52 -0700 (PDT) Date: Thu, 03 Apr 2008 21:43:12 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5A23F.1040802@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: PSARC-ext@sun.com Message-id: <47F5B1E0.2010407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1174 Bart Smaalders wrote: > Garrett D'Amore wrote: > > > must support the various Big Rules (including auditable > administration), > > I asked Gary this question, but he declined to answer: > > What project satisfies this big Rule today? Um... passwd(1M), useradd(1M), bsmconv(1M), printmgr(1M), domainname(1M), uname(1M)? I'm not going to sit and say that we have everything perfect, but we should be able to do better for administrators than offer only vi(1) or emacs based administration, and we should be working to close gaps, rather than introduce new ones. In particular, its not possible to audit, nor possible to control with RBAC, the administration of such facilities. > If my project introduced a config file in /etc/, how could I meet this > big rule? Add a CLI utility to administer the file contents. Don't rely on "vi" as the only administrative interface. > > If we cannot articulate this, this isn't a rule - it's a vague wish > that other people > will do our work for us, and as such is _toxic_ behavior, esp. by > sitting ARC > members. I think I just articulated how to achieve it. Do you disagree? -- Garrett > > - Bart > > > From bart.smaalders@Sun.COM Thu Apr 3 21:54:11 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m344sBGe014144 for ; Thu, 3 Apr 2008 21:54:11 -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 m344sA0O049585; Thu, 3 Apr 2008 22:54:11 -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 <0JYS00C01AYAHQ00@nwk-avmta-2.sfbay.sun.com>; Thu, 03 Apr 2008 21:54:10 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS0068SAYAVW30@nwk-avmta-2.sfbay.sun.com>; Thu, 03 Apr 2008 21:54:10 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m344s9Ej000428; Fri, 04 Apr 2008 04:54:10 +0000 (GMT) Date: Thu, 03 Apr 2008 21:54:09 -0700 From: Bart Smaalders Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5A8C8.1040307@sun.com> To: Alan Coopersmith Cc: "Garrett D'Amore" , PSARC-ext@Sun.COM Message-id: <47F5B471.1040401@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> <47F5A8C8.1040307@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 3306 Alan Coopersmith wrote: > Bart Smaalders wrote: >> Garrett D'Amore wrote: >> >>> must support the various Big Rules (including auditable administration), >> I asked Gary this question, but he declined to answer: >> >> What project satisfies this big Rule today? > > SMF. > >> If my project introduced a config file in /etc/, how could I meet this >> big rule? > > You could provide a fooconfig command, or plugin to some administration > toolset (if we had one with a future, unlike smc), but many projects don't, > which is why new config files in /etc were banned by the SMF policy. > > Of course, like most big rules & SAC policies, we only apply to new projects, > and the trivial way to be exempted is to leave the old code untouched and > not come back to ARC with any enhancements, effectively encouraging > stagnation. > huh? So I cannot integrate dovecot (a nice imap server) into Solaris, w/o shoving all the config files into the repository? I don't think this is what the SMF team or anyone else had in mind, and indeed, I find: > Appendix A: Guidance for Highly Complex Configuration Grammar > > Projects that have: > > * Services with existing configuration files > * Open Source services with well-known configuration files > * Services that are recognized as having highly complex grammar > > must consult with the ARC to determine if utilizing the Service Configuration > Facility is appropriate for their specific configuration data. > It's pretty clear that the SMF policy doesn't expect or require Open Source services to be rewritten to store their configuration information in SMF. We _do_ expect a SMF manifest; that's simple and often requires no changes in the installed software at all other than trivial rework of rc.d scripts. I don't think PSARC will require sendmail.conf to appear in the SMF repo anytime soon. Reading the Solaris Auditing Policy, I see no prescriptive suggestions for auditing changes to configuration files in /etc. Indeed, the /etc/security directory is full of sensitive security-related configuration files, which have no explicit auditing mechanism other than the basics provided by system call auditing. If this is good enough for such core Solaris components as auditing (heh), openssl, etc, why isn't it good enough for other open source software? If we want to engineer a better solution, I suggest we investigate options that don't require redesigning every piece of software that goes into Solaris. Instead, let's look for ways to leverage our top to bottom control of the system so that we can provide the necessary auditing history/mechanisms w/o changing every piece of software aimed at Solaris. For example, has anyone considered using/modifying ZFS to provide extra transactional semantics for a filesystem mounted on /etc? Perhaps one that doesn't make changes to a file visible until it's closed, and preserves all previous versions of the files? Given that /etc/ traffic is low, you could also implement /etc as a user-level NFS mount (or using FUSE when that integrates) and implement most of the semantics there. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From bart.smaalders@sun.com Thu Apr 3 22:27:04 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m345R3Yg015355 for ; Thu, 3 Apr 2008 22:27:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m345QwKv013714; Fri, 4 Apr 2008 13:27:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYS00K03CGXKX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Apr 2008 22:26:57 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS00DHACGX0Q20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Apr 2008 22:26:57 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m345QvPo000866; Fri, 04 Apr 2008 05:26:57 +0000 (GMT) Date: Thu, 03 Apr 2008 22:26:57 -0700 From: Bart Smaalders Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5B1E0.2010407@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <47F5BC21.2030608@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> <47F5B1E0.2010407@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 2099 Garrett D'Amore wrote: > Bart Smaalders wrote: >> Garrett D'Amore wrote: >> >> > must support the various Big Rules (including auditable >> administration), >> >> I asked Gary this question, but he declined to answer: >> >> What project satisfies this big Rule today? > > Um... passwd(1M), useradd(1M), bsmconv(1M), printmgr(1M), > domainname(1M), uname(1M)? I'm not going to sit and say that we have > everything perfect, but we should be able to do better for > administrators than offer only vi(1) or emacs based administration, and > we should be working to close gaps, rather than introduce new ones. > > Add a CLI utility to administer the file contents. Don't rely on "vi" > as the only administrative interface. For simple interfaces, we sort of manage, although we've punted on massive amounts of those as well, and I don't see the resources dedicated to addressing the problem. And how do we do this for IPF? Sendmail? Postfix? Apache? >> >> If we cannot articulate this, this isn't a rule - it's a vague wish >> that other people >> will do our work for us, and as such is _toxic_ behavior, esp. by >> sitting ARC >> members. > > I think I just articulated how to achieve it. Do you disagree? > Yes. I cannot imagine that we will replace more than a small fraction of the files in /etc w/ custom command line config tools. It's certainly a significant project for each of the more complex config files, and the payback often minimal. Is auditing something that is useful if we only do a half-assed job? Or should we look for better ways of solving the auditing problem and accept that for some config files we're just not going to write a useful command line utility to manage them... Simply stopping the addition of open source software to Solaris in order to meet auditing requirements for /etc files (which we don't meet anyway w/ the stuff we've shipped for years) seems ludicrous. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gdamore@sun.com Fri Apr 4 00:14:12 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m347ECkN017909 for ; Fri, 4 Apr 2008 00:14:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m347EB9X024762; Fri, 4 Apr 2008 00:14:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYS00607HFMJQ00@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 01:14:10 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS004HXHFJCC20@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 01:14:07 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m347E7ek017276; Fri, 04 Apr 2008 00:14:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYS00901HFE7F00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Fri, 04 Apr 2008 00:14:07 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYS005PMHFIV710@fe-sfbay-09.sun.com>; Fri, 04 Apr 2008 00:14:07 -0700 (PDT) Date: Fri, 04 Apr 2008 00:10:25 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5BC21.2030608@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: PSARC-ext@sun.com Message-id: <47F5D461.8030604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> <47F5B1E0.2010407@sun.com> <47F5BC21.2030608@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1498 Bart Smaalders wrote: > Garrett D'Amore wrote: > > > Simply stopping the addition of open source software to Solaris > in order to meet auditing requirements for /etc files (which we > don't meet anyway w/ the stuff we've shipped for years) seems > ludicrous. I don't think you understand what "derailing" means. It means that the case gets a regular review, because it failed the "obviousness" test required for a fast track. It does *not* mean that you can't ship the software. Please don't assume that derailing is an automatic failure. That said, it may be that just a few too many FOSS projects have come our way indicating that because the architecture is good enough for Linux, it ought to be good enough for us. While for any given project this may or may not be true, if we're going to abdicate all of our engineering elsewhere, then we ought to just close up shop and stop trying to pretend that we are exercising even a little control over the whole system, or have any kind of high level architectural vision beyond "copy Linux". FWIW, I don't disagree that we have a half-baked solution for auditing administration. Far far too many configuration files are used where an administrative tool would provide audit (and RBAC!) support. Yes, there are lots of clever solutions around this problem... Anyway, I don't make the rules. If you want to appeal the policy, that's fine, just don't expect to be able to do so in the context of a fast-track. -- Garrett From Darren.Moffat@sun.com Fri Apr 4 01:48:29 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m348mTxc019081 for ; Fri, 4 Apr 2008 01:48:29 -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 m348mSgD033041 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 Apr 2008 02:48:29 -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 <0JYS00N0JLSS1S00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 01:48:28 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS0064ELSRVVC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 01:48:28 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m348mRh8025503 for ; Fri, 04 Apr 2008 08:48:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYS00401LERBW00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 09:48:27 +0100 (BST) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYS003K7LSPOF20@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 09:48:25 +0100 (BST) Date: Fri, 04 Apr 2008 09:48:25 +0100 From: Darren J Moffat Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F54490.1010808@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Wyllys Ingersoll , psarc-ext@sun.com, "Mark A. Carlson" Message-id: <47F5EB59.3060100@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F54490.1010808@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 749 Garrett D'Amore wrote: >> The "auditable administration" question was answered already - there >> is no auditable interface for any PAM configuration files or any other >> files that are managed via "vi" (or whatever editor) for that matter. > > I didn't see the answer in the mail log. Managing files via "vi" is > certainly possible, but it isn't clear to me that "vi" is the solution > for system administration. "vi" can't be audited, so its reasonable > that a CLI be provided which *can* be audited, and also "controlled" via > RBAC. This case is no different in the configuration required in pam.conf or in the modules own config file than things like pam_list (PSARC/2003/674 which was approved 2007-02-28). -- Darren J Moffat From Darren.Moffat@Sun.COM Fri Apr 4 02:23:50 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m349NoGD020734 for ; Fri, 4 Apr 2008 02:23:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m349No4J023128 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 4 Apr 2008 02:23:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYS00101NFQ9C00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 02:23:50 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYS00690NFOW4E0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 02:23:49 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m349NmjI000988 for ; Fri, 04 Apr 2008 09:23:48 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYS00101K1FYO00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 10:23:48 +0100 (BST) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYS003PSNFGOF20@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 10:23:42 +0100 (BST) Date: Fri, 04 Apr 2008 10:23:40 +0100 From: Darren J Moffat Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5396A.7070201@sun.com> Sender: Darren.Moffat@Sun.COM To: Wyllys Ingersoll Cc: "Mark A. Carlson" , PSARC-ext@Sun.COM, "Garrett D'Amore" Message-id: <47F5F39C.1040703@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2187 Wyllys Ingersoll wrote: > I disagree. For many weeks now the submitter has answered the > questions and made all of the corrective actions requested by the ARC on > this case and now there is talk of derailing it? I don't think any > architectural issues were found with the project. The documentation is > weak, but the submitter has agreed to work with the open source group > that owns it to address the doc issues. I'm with Wyllys on this. The quality of documentation isn't really an ARC concern. The ARC's concern is are they presented with sufficient specification to understand the architecture. Consider that for most projects we never see the actual documentation (other than sometimes draft man pages) at ARC review time. > The "auditable administration" question was answered already - there is > no auditable interface for any PAM configuration files or any other > files that are managed via "vi" (or whatever editor) for that matter. I think the issue is more about the modules own config file, however there are recently approved ARC cases for PAM modules that use $EDITOR as the admin interface. Also there are plenty of other cases recently that have security relevant configuration files that have no admin interface - consider things like SSL/TLS configuration of Apache/PHP etc. > Discussions over how best to merge FOSS and ARC needs is something that > should be discussed outside of this case. > > The project team has been playing fetch-a-rock for too long. The final > specs have been submitted, I think Darren is planning on putting them in > the case dir very soon. This case should be approved so the team can > move ahead. The only difference was the removal of the pkc11_event_manager. Given the case has been derailed as fast-track submitter I'm taking case ownership of this. Since the project team has no intention of changing the specification or playing further rock fetching games I see no value in having a meeting. I'm calling for an EMAIL VOTE now. If there are TCRs please articulate them very specifically in a form that can realistically be implemented as part of your reply. -- Darren J Moffat From gdamore@sun.com Fri Apr 4 08:18:10 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34FI9TZ028129 for ; Fri, 4 Apr 2008 08:18:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m34FI2FH017010 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 4 Apr 2008 16:18:08 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT00E1D3U6ZA00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 08:18:06 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00EA33U61E20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 08:18:06 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34FI6F1000652 for ; Fri, 04 Apr 2008 08:18:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00A013PSTQ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 08:18:06 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT00EZS3U5IH70@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 08:18:06 -0700 (PDT) Date: Fri, 04 Apr 2008 08:14:23 -0700 From: "Garrett D'Amore" Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5F39C.1040703@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Wyllys Ingersoll , "Mark A. Carlson" , PSARC-ext@sun.com Message-id: <47F645CF.3060702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3684 Ok, I'm confused. If the documentation isn't part of the review, and the user experience isn't really part of the review (by corollary), and the project team isn't interested in changing anything, then why exactly are we reviewing this case? I don't know that I feel TCR strong on much about this case, but then again, if we're asserting that the only thing I'm looking at as part of ARC review is "interfaces" between this project and other software, and it is only using documented PAM interfaces, then there really is nothing left to review. I would request TCAs as follows: *) add an auditable interface to administer (perhaps by just enabling) the module *) remove the wording "smartcard" from the prompts -- since it clearly isn't an actual smartcard *) the make_hash_links.sh script feels like a hack -- remove the .sh, and promote it to a regular command if one is needed. *) the documentation should be provided in a manner that is consistent with other Sun-delivered projects -- the details for administration of smartcard authentication should located in the standard Sun manuals (i.e. in the System Administrator's Guide or whatever it is called these days) On an aside, I think it is a total shame that we're completely abdicating everything about Solaris architecture to Linux or other FOSS projects. If that is the way forward, then perhaps ARC ought to just disband. -- Garrett Darren J Moffat wrote: > Wyllys Ingersoll wrote: >> I disagree. For many weeks now the submitter has answered the >> questions and made all of the corrective actions requested by the ARC >> on this case and now there is talk of derailing it? I don't think >> any architectural issues were found with the project. The >> documentation is weak, but the submitter has agreed to work with the >> open source group that owns it to address the doc issues. > > I'm with Wyllys on this. The quality of documentation isn't really an > ARC concern. The ARC's concern is are they presented with sufficient > specification to understand the architecture. Consider that for most > projects we never see the actual documentation (other than sometimes > draft man pages) at ARC review time. > >> The "auditable administration" question was answered already - there >> is no auditable interface for any PAM configuration files or any >> other files that are managed via "vi" (or whatever editor) for that >> matter. > > I think the issue is more about the modules own config file, however > there are recently approved ARC cases for PAM modules that use $EDITOR > as the admin interface. > > Also there are plenty of other cases recently that have security > relevant configuration files that have no admin interface - consider > things like SSL/TLS configuration of Apache/PHP etc. > >> Discussions over how best to merge FOSS and ARC needs is something >> that should be discussed outside of this case. >> The project team has been playing fetch-a-rock for too long. The >> final specs have been submitted, I think Darren is planning on >> putting them in the case dir very soon. This case should be >> approved so the team can move ahead. > > The only difference was the removal of the pkc11_event_manager. > > Given the case has been derailed as fast-track submitter I'm taking > case ownership of this. > > Since the project team has no intention of changing the specification > or playing further rock fetching games I see no value in having a > meeting. > > I'm calling for an EMAIL VOTE now. > > If there are TCRs please articulate them very specifically in a form > that can realistically be implemented as part of your reply. > From bart.smaalders@sun.com Fri Apr 4 10:23:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34HNi1V003083 for ; Fri, 4 Apr 2008 10:23:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m34HNLMj005846; Fri, 4 Apr 2008 18:23:39 +0100 (BST) 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 <0JYT005099NF4200@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 11:23:39 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00DRA9ND4OC0@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 11:23:38 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m34HNbCJ011715; Fri, 04 Apr 2008 17:23:37 +0000 (GMT) Date: Fri, 04 Apr 2008 10:23:37 -0700 From: Bart Smaalders Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F645CF.3060702@sun.com> To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <47F66419.4030601@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 3801 Garrett D'Amore wrote: > Bart Smaalders wrote: >> Garrett D'Amore wrote: >> >> >> Simply stopping the addition of open source software to Solaris >> in order to meet auditing requirements for /etc files (which we >> don't meet anyway w/ the stuff we've shipped for years) seems >> ludicrous. > > I don't think you understand what "derailing" means. It means that > the case gets a regular review, because it failed the "obviousness" > test required for a fast track. > > It does *not* mean that you can't ship the software. Please don't > assume that derailing is an automatic failure. > I can assure you I know exactly how and why cases get derailed; it happens for a wide variety of reasons - some good, some bad. Derailing every open source putback because it introduces a configuration file w/o an corresponding administrative tool is the ARC's equivalent of a work slowdown. Every time it happens, we spend a few thousand dollars of Sun's and the community's money/time to no good purpose other than theatrics. Since management has made it clear (by not assigning people to work on the problem) that writing command line interfaces (eg custom editors) for every config file in /etc is not a priority for them (and community developers aren't exactly stampeding to follow the ARC's leadership here) for the ARC to needlessly delay (or cause to be abandoned) every project that ships such an interface makes no sense at all. > That said, it may be that just a few too many FOSS projects have come > our way indicating that because the architecture is good enough for > Linux, it ought to be good enough for us. Like it or now, we don't write all the software that's in Solaris. We never have, and never will. If we have legitimate needs for auditing config file changes, then let's figure out how to do that in such a way that we don't end up making every project design and implement custom commands to do so. > > While for any given project this may or may not be true, if we're > going to abdicate all of our engineering elsewhere, then we ought to > just close up shop and stop trying to pretend that we are exercising > even a little control over the whole system, or have any kind of high > level architectural vision beyond "copy Linux". > > FWIW, I don't disagree that we have a half-baked solution for > auditing administration. Far far too many configuration files are > used where an administrative tool would provide audit (and RBAC!) > support. > > Yes, there are lots of clever solutions around this problem... > > Anyway, I don't make the rules. If you want to appeal the policy, > that's fine, just don't expect to be able to do so in the context of > a fast-track. You really don't get it. We cannot spend the time to write custom commands to edit every config file for every piece of open source software on the planet. If you want auditing and RBAC, figure out a way to do so that doesn't place so heavy a tax on every project that wants to deliver on Solaris. Rewriting or adding commands to every project is not acceptable - and is pointless so long as we don't even fund command line interfaces for all the config files Sun has introduced over the years. > On an aside, I think it is a total shame that we're completely > abdicating everything about Solaris architecture to Linux or other FOSS > projects. If that is the way forward, then perhaps ARC ought to just > disband. If that's how you feel, you know how to do your part. Seriously, there are very useful roles for the ARC; enforcing ill-considered policies like the Auditing requirement is NOT one of them., - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From sacadmin Fri Apr 4 10:47:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34Hlt8T003630 for ; Fri, 4 Apr 2008 10:47:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m34Hlh3G012585; Sat, 5 Apr 2008 01:47:52 +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 <0JYT00K0DARQ8200@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 10:47:50 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00EGRARQ17C0@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 10:47:50 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34HloPW020136; Fri, 04 Apr 2008 10:47:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00K01ANLGY00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Fri, 04 Apr 2008 10:47:50 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT002TLAR91ZF0@fe-sfbay-10.sun.com>; Fri, 04 Apr 2008 10:47:34 -0700 (PDT) Date: Fri, 04 Apr 2008 10:43:52 -0700 From: "Garrett D'Amore" Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F66419.4030601@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: Darren J Moffat , psarc-members@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <47F668D8.60301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3267 (Changing psarc-ext to psarc-members -- no need to have this debate in open, I think.) Bart Smaalders wrote: > Garrett D'Amore wrote: > > You really don't get it. > > We cannot spend the time to write custom commands to edit every > config file for every piece of open source software on the planet. Ah, but why do we have the need to *integrate* every piece of open source software on the planet? There's a problem of scalability, and differing goals here. If our goal is to integrate every piece of open source software on the planet, then ARC just needs to get the hell out of the way. Although there seems to be a movement in this direction, I've never actually heard this goal explicitly stated. (Although maybe the problem is one of interpretation of the Serendipitous Discovery cases.) To my mind, SDF and integration of FOSS seem diametrically opposed -- at least the way the FOSS cases have been presented of late. > > If you want auditing and RBAC, figure out a way to do so that doesn't > place so heavy a tax on every project that wants to deliver on Solaris. > Rewriting or adding commands to every project is not acceptable - > and is pointless so long as we don't even fund command line interfaces > for all the config files Sun has introduced over the years. Again, I don't make the rules, and frankly I'm not exactly thrilled with SMF either. If you want to propose a project to either change the rules, or provide a simpler way to achieve conformance, please feel free to do so! Doing so myself falls far outside of both my normal area of expertise, and my job responsibilities (both as an employee working on x86 kernel stuff, and as an ARC member.) > >> On an aside, I think it is a total shame that we're completely >> abdicating everything about Solaris architecture to Linux or other >> FOSS projects. If that is the way forward, then perhaps ARC ought to >> just disband. > > If that's how you feel, you know how to do your part. Seriously, there > are > very useful roles for the ARC; enforcing ill-considered policies like the > Auditing requirement is NOT one of them., "Enforcing ill-considered policies"... well, if you don't like the rules, then please propose a project to change them. Asking ARC to waive rules seems the wrong way forward, at least to me. (Its sort of like asking courts not to enforce laws -- if you don't like the laws -- at least in the US -- you bring legislation to change them, rather than asking for judicial activism.) I would like to know what value you think ARC brings in reviewing open source cases like this one ... if we can't express an opinion, or request change, or enforce "policies" (ill-considered or otherwise), then I'm not sure what the role is. Maybe ARC should only review kernel stuff? It seems that nobody at Sun does userland development beyond just Makefile editing and integration of stuff other people wrote. Maybe the Nexenta project is really the code name for Solaris 11, and we've just not been told... (Of course, I've seen some pretty ugly kernel code that tried to justify ugliness based on import from FOSS as well.... I think engineers who actually work on *Solaris* are a dying breed, ZFS notwithstanding.) -- Garrett From sacadmin Fri Apr 4 11:24:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34IORT7004520 for ; Fri, 4 Apr 2008 11:24:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m34IOOCu000192 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Fri, 4 Apr 2008 19:24:25 +0100 (BST) 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 <0JYT00903CGPGO00@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 12:24:25 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT008NPCGOCM70@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 12:24:24 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m34IOOke002219 for ; Fri, 04 Apr 2008 18:24:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00801B0K8900@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 12:24:24 -0600 (MDT) Received: from Macintosh-39.local ([71.237.94.98]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT00HGJCGGX6G0@mail-amer.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 12:24:16 -0600 (MDT) Date: Fri, 04 Apr 2008 12:24:15 -0600 From: "Mark A. Carlson" Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F668D8.60301@sun.com> Sender: Mark.Carlson@sun.com To: Darren J Moffat Cc: psarc-members@sun.com Message-id: <47F6724F.3060708@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 1011 Darren J Moffat wrote: > ... > > Given the case has been derailed as fast-track submitter I'm taking case > ownership of this. > Thanks Darren. > Since the project team has no intention of changing the specification or > playing further rock fetching games I see no value in having a meeting. > > I'm calling for an EMAIL VOTE now. > > If there are TCRs please articulate them very specifically in a form > that can realistically be implemented as part of your reply. > > I'd like to give folks a few days to send these. Can we discuss and possibly vote during Wednesday's ARC biz, or is that too soon? Given the discussion this week, would we expect this case to be tagged with an "Experimental" warning (if we had one) for mainly Red Shift companies to use at their own risk in deployment, or is it something we expect to be built upon for enterprise customers? If we can reach consensus on this one aspect it would help me understand which if any TCRs and TCAs need to be applied. -- mark From sacadmin Fri Apr 4 11:50:41 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34IoeUc004780 for ; Fri, 4 Apr 2008 11:50:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m34Iocnb007639 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Sat, 5 Apr 2008 02:50:39 +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 <0JYT00501DOEWV00@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 11:50:38 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00MCADODBF90@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 11:50:38 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34Iob9D027741 for ; Fri, 04 Apr 2008 18:50:37 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00M01DLJPJ00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 19:50:37 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT00IKLDOCH310@fe-emea-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 04 Apr 2008 19:50:36 +0100 (BST) Date: Fri, 04 Apr 2008 19:50:36 +0100 From: Darren J Moffat Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F6724F.3060708@sun.com> Sender: Darren.Moffat@sun.com To: "Mark A. Carlson" Cc: psarc-members@sun.com Message-id: <47F6787C.6010404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> <47F6724F.3060708@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1217 Mark A. Carlson wrote: > Darren J Moffat wrote: >> ... >> >> Given the case has been derailed as fast-track submitter I'm taking >> case ownership of this. >> > Thanks Darren. >> Since the project team has no intention of changing the specification >> or playing further rock fetching games I see no value in having a >> meeting. >> >> I'm calling for an EMAIL VOTE now. >> >> If there are TCRs please articulate them very specifically in a form >> that can realistically be implemented as part of your reply. >> >> > I'd like to give folks a few days to send these. > > Can we discuss and possibly vote during Wednesday's ARC biz, or is that > too soon? That is fine with me. > Given the discussion this week, would we expect this case to be tagged > with an > "Experimental" warning (if we had one) for mainly Red Shift companies to > use > at their own risk in deployment, or is it something we expect to be > built upon for > enterprise customers? We have no such thing in the taxonomy and this case should not be inventing it. The customers that really really need this - in fact are already using it - are some of Sun's biggest and most important enterprise customers -- Darren J Moffat From sacadmin Fri Apr 4 11:53:47 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34IrkSt004814 for ; Fri, 4 Apr 2008 11:53:46 -0700 (PDT) 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 m34IrZsq008600; Sat, 5 Apr 2008 02:53:38 +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 <0JYT00B03DTDN200@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 12:53:37 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00AG7DTDVM00@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 12:53:37 -0600 (MDT) Received: from [129.146.228.161] (nihil.SFBay.Sun.COM [129.146.228.161]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m34IrbBV621889; Fri, 04 Apr 2008 11:53:37 -0700 (PDT) Date: Fri, 04 Apr 2008 11:53:40 -0700 From: Liane Praza Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F668D8.60301@sun.com> To: "Garrett D'Amore" Cc: Bart Smaalders , Darren J Moffat , psarc-members@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <47F67934.8070200@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 1672 Garrett D'Amore wrote: >> If you want auditing and RBAC, figure out a way to do so that doesn't >> place so heavy a tax on every project that wants to deliver on Solaris. >> Rewriting or adding commands to every project is not acceptable - >> and is pointless so long as we don't even fund command line interfaces >> for all the config files Sun has introduced over the years. > > Again, I don't make the rules, and frankly I'm not exactly thrilled with > SMF either. If you want to propose a project to either change the > rules, or provide a simpler way to achieve conformance, please feel free > to do so! Doing so myself falls far outside of both my normal area of > expertise, and my job responsibilities (both as an employee working on > x86 kernel stuff, and as an ARC member.) Regardless of your opinion of SMF, it isn't the SMF policy which requires the change you're requesting. The SMF policy specifically talks about an exemption for well-known configuration files of FOSS software, and configuration with complex grammar. The only reason that exemption isn't automatic is because I was advised by PSARC members that policies don't make automatic exemptions -- they always leave the exemption to the discretion of the ARC. I believe Bart even quoted chapter and verse of the SMF policy which was supposed to set the proper expectations for the ARC *long* before we ever started talking about Indiana. SMF was only mentioned here because putting configuration there is one way to comply with the Auditing policy. If you're going to cite policy, please cite the right one. The "I don't like SMF, but" responses are uncalled for. liane From Nicolas.Williams@sun.com Fri Apr 4 12:12:32 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34JCVVb006425 for ; Fri, 4 Apr 2008 12:12:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m34JCN0n015341; Sat, 5 Apr 2008 03:12:26 +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 <0JYT00003EOPCI00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 12:12:25 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00LCSEOOZK30@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 12:12:25 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m34JCOTe003924; Fri, 04 Apr 2008 14:12:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m34JCOaF003923; Fri, 04 Apr 2008 14:12:24 -0500 (CDT) Date: Fri, 04 Apr 2008 14:12:24 -0500 From: Nicolas Williams Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F54490.1010808@sun.com> To: "Garrett D'Amore" Cc: Wyllys Ingersoll , "Mark A. Carlson" , psarc-ext@sun.com Mail-followup-to: Garrett D'Amore , Wyllys Ingersoll , "Mark A. Carlson" , psarc-ext@sun.com Message-id: <20080404191224.GE16998@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F54490.1010808@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 492 IMO not all configuration files can have admin CLIs/APIs/GUIs without enormous expense, and maybe some can't really have any that are all that great (think pam.conf(4)[*]). ZFS audit SACLs ought to take care of the auditing issue (though, of course, turning on file auditing will take care of it now). [*] PSARC/2005/275 will make it so we can deal with PAM profiles, but at the end of the day, what tool could really help you edit a PAM profile? pam.conf is almost a language. From gdamore@sun.com Fri Apr 4 12:17:38 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34JHbwK006472 for ; Fri, 4 Apr 2008 12:17:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m34JHZZd013937 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 Apr 2008 13:17:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT0080NEXCML00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 12:17:36 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00MPPEXBBFC0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 12:17:35 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34JHZfl001851 for ; Fri, 04 Apr 2008 12:17:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00801ESIAK00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 12:17:35 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT00KPOEXA2HE0@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 12:17:35 -0700 (PDT) Date: Fri, 04 Apr 2008 12:13:51 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <20080404191224.GE16998@Sun.COM> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore" , Wyllys Ingersoll , "Mark A. Carlson" , psarc-ext@sun.com Message-id: <47F67DEF.60004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F54490.1010808@sun.com> <20080404191224.GE16998@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 624 Nicolas Williams wrote: > IMO not all configuration files can have admin CLIs/APIs/GUIs without > enormous expense, and maybe some can't really have any that are all that > great (think pam.conf(4)[*]). > > ZFS audit SACLs ought to take care of the auditing issue (though, of > course, turning on file auditing will take care of it now). > > [*] PSARC/2005/275 will make it so we can deal with PAM profiles, but > at the end of the day, what tool could really help you edit a PAM > profile? pam.conf is almost a language. > This project introduces additional configuration *beyond* pam.conf. -- Garrett From Darren.Moffat@sun.com Fri Apr 4 12:19:34 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34JJYC5006491 for ; Fri, 4 Apr 2008 12:19:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m34JJWPP014333 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 Apr 2008 13:19:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT00801F0LSL00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 12:19:33 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00MTSF0KBCE0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 12:19:33 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34JJV1t029286 for ; Fri, 04 Apr 2008 19:19:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00C01EVBWP00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 20:19:31 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT00ILKF0JH310@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 20:19:31 +0100 (BST) Date: Fri, 04 Apr 2008 20:19:31 +0100 From: Darren J Moffat Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F67DEF.60004@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Wyllys Ingersoll , "Mark A. Carlson" , psarc-ext@sun.com Message-id: <47F67F43.3080701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F54490.1010808@sun.com> <20080404191224.GE16998@Sun.COM> <47F67DEF.60004@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 901 Garrett D'Amore wrote: > Nicolas Williams wrote: >> IMO not all configuration files can have admin CLIs/APIs/GUIs without >> enormous expense, and maybe some can't really have any that are all that >> great (think pam.conf(4)[*]). >> >> ZFS audit SACLs ought to take care of the auditing issue (though, of >> course, turning on file auditing will take care of it now). >> >> [*] PSARC/2005/275 will make it so we can deal with PAM profiles, but >> at the end of the day, what tool could really help you edit a PAM >> profile? pam.conf is almost a language. >> > > This project introduces additional configuration *beyond* pam.conf. and there is precedence in other cases where PAM modules have config files that are text and not in SMF. Those other cases are not even that old (and post date the introduction of SMF) - I've already given at least one of them. -- Darren J Moffat From sacadmin Fri Apr 4 12:19:34 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34JJYNJ006492 for ; Fri, 4 Apr 2008 12:19:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m34JJWPJ014333; Fri, 4 Apr 2008 13:19:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT0080DF0KS900@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 12:19:32 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00M18F0JBFD0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 12:19:32 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34JJVN9021011; Fri, 04 Apr 2008 12:19:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00401EVAQA00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Fri, 04 Apr 2008 12:19:31 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT002RKF0JIRB0@fe-sfbay-10.sun.com>; Fri, 04 Apr 2008 12:19:31 -0700 (PDT) Date: Fri, 04 Apr 2008 12:15:47 -0700 From: "Garrett D'Amore" Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F67934.8070200@sun.com> Sender: Garrett.Damore@sun.com To: Liane Praza Cc: Bart Smaalders , Darren J Moffat , psarc-members@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <47F67E63.3070508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> <47F67934.8070200@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2075 Liane Praza wrote: > Garrett D'Amore wrote: >>> If you want auditing and RBAC, figure out a way to do so that doesn't >>> place so heavy a tax on every project that wants to deliver on Solaris. >>> Rewriting or adding commands to every project is not acceptable - >>> and is pointless so long as we don't even fund command line interfaces >>> for all the config files Sun has introduced over the years. >> >> Again, I don't make the rules, and frankly I'm not exactly thrilled >> with SMF either. If you want to propose a project to either change >> the rules, or provide a simpler way to achieve conformance, please >> feel free to do so! Doing so myself falls far outside of both my >> normal area of expertise, and my job responsibilities (both as an >> employee working on x86 kernel stuff, and as an ARC member.) > > Regardless of your opinion of SMF, it isn't the SMF policy which > requires the change you're requesting. The SMF policy specifically > talks about an exemption for well-known configuration files of FOSS > software, and configuration with complex grammar. The only reason > that exemption isn't automatic is because I was advised by PSARC > members that policies don't make automatic exemptions -- they always > leave the exemption to the discretion of the ARC. I believe Bart even > quoted chapter and verse of the SMF policy which was supposed to set > the proper expectations for the ARC *long* before we ever started > talking about Indiana. > > SMF was only mentioned here because putting configuration there is one > way to comply with the Auditing policy. > > If you're going to cite policy, please cite the right one. The "I > don't like SMF, but" responses are uncalled for. > > liane Okay, I'll give up now. I made my points -- heck, I wasn't even the one derailed the case. I've suggested some TCAs -- which I'm fairly confident will be ignored by the project team -- so we can take the vote later, and move on. /me is really regretting volunteering to review this case -- ignorance was bliss... -- Garrett From Nicolas.Williams@sun.com Fri Apr 4 12:54:00 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34Js0h1007148 for ; Fri, 4 Apr 2008 12:54:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m34JrwEG008263; Fri, 4 Apr 2008 12:53:58 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT00C0PGLWL300@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 12:53:56 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00AHKGLUU960@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 12:53:54 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m34Jrsr8003967; Fri, 04 Apr 2008 14:53:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m34JrsT0003966; Fri, 04 Apr 2008 14:53:54 -0500 (CDT) Date: Fri, 04 Apr 2008 14:53:54 -0500 From: Nicolas Williams Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F67F43.3080701@Sun.COM> To: Darren J Moffat Cc: "Garrett D'Amore" , psarc-ext@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Mail-followup-to: Darren J Moffat , Garrett D'Amore , psarc-ext@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <20080404195354.GJ16998@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F54490.1010808@sun.com> <20080404191224.GE16998@Sun.COM> <47F67DEF.60004@sun.com> <47F67F43.3080701@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1287 On Fri, Apr 04, 2008 at 08:19:31PM +0100, Darren J Moffat wrote: > > This project introduces additional configuration *beyond* pam.conf. > > and there is precedence in other cases where PAM modules have config > files that are text and not in SMF. Those other cases are not even that > old (and post date the introduction of SMF) - I've already given at > least one of them. Given that the case has been derailed I think this is now OT, and I will resist further comment until TCRs/TCAs are proposed, but this one I can't resist :) One example of such a PAM module's config file is krb5.conf(4). No, kclient(1M) is NOT a complete administrative interface to krb5.conf(4) -- just a partial one, and about as good as it's going to get. pam.conf(4) is complex. I think it's fair to assume and allow the configuration of PAM modules to be similarly complex. Not because "hey, if we allow if for pam.conf we ought to allow it for the modules too" but because when it comes to security technologies like Kerberos V and PKI, RADIUS, ..., there really are a lot of options, and lots of context-specific ones too. I'm not arguing for any sort of general get out of jail free feature for PAM modules, rather that *this* module's i-team should get a get out of jail free card. Nico -- From sacadmin Fri Apr 4 13:01:25 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34K1OfG007679 for ; Fri, 4 Apr 2008 13:01:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m34K1DAI006348; Fri, 4 Apr 2008 21:01:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT0020BGY6GW00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 13:01:18 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00LVKGY5ZI60@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 13:01:17 -0700 (PDT) Received: from Macintosh-110.local (vpn-129-150-20-114.SFBay.Sun.COM [129.150.20.114]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m34K1GNt633382; Fri, 04 Apr 2008 13:01:17 -0700 (PDT) Date: Fri, 04 Apr 2008 13:01:16 -0700 From: Tim Marsland Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F668D8.60301@sun.com> To: "Garrett D'Amore" Cc: Bart Smaalders , Darren J Moffat , psarc-members@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <47F6890C.7050201@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 3386 Garrett D'Amore wrote: > I think engineers who actually > work on *Solaris* are a dying breed, ZFS notwithstanding.) (There are many hundreds of engineers who continue to contribute to Solaris outside the domain of the ZFS team. This kind of throwaway remark is at best unhelpful.) > I would like to know what value you think ARC brings in reviewing open > source cases like this one ... if we can't express an opinion, or > request change, or enforce "policies" (ill-considered or otherwise), > then I'm not sure what the role is. I recognize the frustration here on both sides. And I was hoping to discuss this with the ARC last Wednesday, but a combination of my time being severely curtailed by the customer meeting, 30 random people on the phone, and the occasional ratholing we engaged in didn't permit it. (We should retry.) Hmm. (There's a several paragraph prelude that could go here explaining the rationale, but I'm not going to say it now, I'm just going to state the end goal.) We're out to incorporate FOSS into the opensolaris distribution. Not just a little, but a lot. And yes, we're going to have a distribution rather than a WOS. That is the direction the business wants us to go in. Those top-level decisions are not up for debate. Our (collective) job is to figure out how to succeed (wildly) at doing that. Yes, given realistic assumptions about economics i.e. how much we can afford to alter inbound code to fit our "way", and our desire to gain new customers via improving the effectiveness of opensolaris as a platform for developers. And specifically it is *not* about figuring out how to stop it or delay it. Yet I continue to see us asking variants of "surely we're not doing a distribution with lots of FOSS in it are we?" questions. Let me answer that question unequivocally here: "Yes we are." Now let's all take a deep breath. I certainly want us to surface issues and problems, and have members continue to suggest *constructive* solutions to those problems where possible. And I'm particularly happy when I see members working on solving the problems, as opposed to demanding that other people should somehow come up with all the answers in cases they aren't being given time to write, or filling mailboxes with long diatribes on relatively trivial issues. Yet I see both behaviours - let's please work on the first one, and stop the other two. Agreed, the plans aren't clear, and aren't particularly thought through. There's way too much "ready, fire, aim" in the works. The opensolaris and IPS project teams are still under-staffed and overloaded. The detailed business goals are still fuzzy and harder to translate into ARC behaviours. The business is under-informed about the technical implications of the business goals. And I'm trying to work on the "plans" part, but it's an uphill struggle given how we got to this point. And yes, things will probably get rockier before they get better. But I would recommend in the strongest terms that we, as an ARC, need to remain constructive above all else. And, although this sounds trite, it's meant to be pragmatic - if people's disillusionment with what is going on is so high that they can't be constructive on this topic, then there's lots of regular engineering to be done instead e.g. reconsider sending that email rant, go work on some code for a bit instead. tim From jek3@sun.com Fri Apr 4 14:23:41 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34LNfe0010521 for ; Fri, 4 Apr 2008 14:23:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m34LNUgQ007756; Fri, 4 Apr 2008 22:23:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT00L0LKRCV700@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 14:23:36 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00IXFKRAPO10@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 14:23:34 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m34LNXOv644914; Fri, 04 Apr 2008 14:23:33 -0700 (PDT) Date: Fri, 04 Apr 2008 11:23:29 -1000 From: Joseph Kowalski Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5A8C8.1040307@sun.com> To: Alan Coopersmith Cc: Bart Smaalders , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47F69C51.8020703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> <47F5A8C8.1040307@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 282 Alan Coopersmith wrote: > Of course, like most big rules & SAC policies, we only apply to new projects, > and the trivial way to be exempted is to leave the old code untouched and > not come back to ARC with any enhancements, effectively encouraging > stagnation. > +1 - jek3 From sacadmin Fri Apr 4 14:38:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34LcaWq010655 for ; Fri, 4 Apr 2008 14:38:37 -0700 (PDT) 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 m34LcRA7007236; Sat, 5 Apr 2008 05:38:34 +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 <0JYT00005LG7TJ00@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 15:38:31 -0600 (MDT) Received: from buye.red.iplanet.com ([192.18.65.224]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00A4PLG6VKA0@brm-avmta-1.central.sun.com>; Fri, 04 Apr 2008 15:38:30 -0600 (MDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m34LcUBR017830; Fri, 04 Apr 2008 14:38:30 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m34LcUqW017829; Fri, 04 Apr 2008 14:38:30 -0700 (PDT) Date: Fri, 04 Apr 2008 14:38:30 -0700 From: Jyri Virkki Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F668D8.60301@sun.com> To: "Garrett D'Amore" Cc: psarc-members@sun.com Message-id: <20080404213830.GA15662@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 2297 Garrett D'Amore wrote: > > Maybe ARC should only review kernel stuff? It seems that nobody at Sun > does userland development beyond just Makefile editing and integration > of stuff other people wrote. Perhaps the above obliquely hints at the misunderstanding & disconnect. We [Sun] wear various hats on different projects. They're not all the same and attempting to apply the expectation of one role to a different role can only fail [after generating 500 mails]. Sometimes it's our design, our code, our project, our architecture. We [Sun] drive the project from inception to implementation to packaging and delivery. We [ARC] can softly [TCA] or strongly [TCR] change the direction of such project which we [Sun] fully own. And sometimes, it's not ours. Someone else designed it and wrote it. Our role is to package it in a way that fits into Solaris the best it can so our customer can use it. It's technically less interesting work but equally vital since customers demand apps and we like our customers. Any discussions on rearchitecting such components are out of scope and a waste of time. It's not our code so we don't get to change it(1) unless we want to force a fork. Forking is very rarely an option. Not only can't we afford it, it wouldn't be useful even if we could afford it. (When customers want third party open source component FOO, they want the FOO everyone else is using, the FOO that has 20 books about it on the shelf of the local bookstore, the FOO that has user conferences and support groups and web communities..... even if we could afford to rewrite it to be "better" based on what we think are flaws, then it'd become SunFOO. Nobody wants SunFOO, they want FOO.) I don't agree with the sentiment of "let's go home and not ARC anything". There are many choices that get made during the process of taking the upstream tarball and making it available for Solaris. There is clear value in having a centralized body review such decisions for consistency within OpenSolaris. (1) Well, ARC can't change it by ranting on email threads (see star), however, we as individuals CAN change it by going out to the community and participating and contributing patches etc. It's all open source after all. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From jek3@sun.com Fri Apr 4 14:46:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34LkEWS010755 for ; Fri, 4 Apr 2008 14:46:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m34Lk95k009519; Sat, 5 Apr 2008 05:46:10 +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 <0JYT0060RLSXMR00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 14:46:09 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00L6ALSXZGF0@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 14:46:09 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m34Lk8Tv648317; Fri, 04 Apr 2008 14:46:09 -0700 (PDT) Date: Fri, 04 Apr 2008 11:46:05 -1000 From: Joseph Kowalski Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5BC21.2030608@Sun.COM> To: Bart Smaalders Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47F6A19D.9000609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> <47F5B1E0.2010407@sun.com> <47F5BC21.2030608@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1579 Bart Smaalders wrote: >> Add a CLI utility to administer the file contents. Don't rely on >> "vi" as the only administrative interface. > > For simple interfaces, we sort of manage, although we've punted > on massive amounts of those as well, and I don't see the resources > dedicated to addressing the problem. And that's what this whole discussion boils down to, isn't it? Everyone wants everything integrated and integrated fully. In a world of unlimited resources, everyone would be happy.[1] Unfortunately, we don't live in such a world. To pick on names, Bart *seems* to want a much "stuff" as possible, with minimal effort. Garrett *seems* to want only as much "stuff" as we can do with full integration (and even additional requirements). This isn't architecture. Its a business decision. Unfortunately, executives are notorious about not being clear about the decisions and worse yet, each executive seems to have a different take on the business. Its part of the charter of the ARC to try and make sense of these conflicting desires. My plea is that we try not to take diametric positions. We are chartered to find the "sweet spot". Absolute positions don't serve any of us well. Sure, we would always like to have some "big rule" to fall back onto, but that just isn't practical. The ARC members are supposed to be chosen for "judgment". There is a reason for this. - jek3 [1] It seems that some still wouldn't be happy. See "star". It seems to question the value of "full integrated", but I believe that is a clearly minority opinion. From jgh@wizmail.org Fri Apr 4 14:50:26 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34LoOHk010775 for ; Fri, 4 Apr 2008 14:50:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m34LoAFf010487 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 5 Apr 2008 05:50:23 +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 <0JYT00603LZXTR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 14:50:21 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT006C8LZXO100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 14:50:21 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m34Lmh09002081 for ; Fri, 04 Apr 2008 21:50:21 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay42i.sun.com with ESMTP id BT-MMP-23718 for PSARC-ext@sun.com; Fri, 04 Apr 2008 21:50:15 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.sun.com with ESMTP id BT-MMP-613557 for PSARC-ext@sun.com; Fri, 04 Apr 2008 21:50:15 +0000 (Z) Received: from wizmail.org ([217.146.104.199] [217.146.104.199]) by relay4i.sun.com with ESMTP id BT-MMP-1187033 for PSARC-ext@sun.com; Fri, 04 Apr 2008 21:50:15 +0000 (Z) Received: from ebony.jgh.adsl.wizards.co.uk ([217.146.123.59]) (from_AS 16353) by wizmail.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.67) id 1Jhtna-00052x-49 for PSARC-ext@sun.com (return-path ) ; Fri, 04 Apr 2008 21:50:14 +0000 Date: Fri, 04 Apr 2008 22:50:11 +0100 From: Jeremy Harris Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F66419.4030601@Sun.COM> To: PSARC-ext@sun.com Message-id: <47F6A293.3090408@wizmail.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.105sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080226 Fedora/2.0.0.12-1.fc7 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 Status: RO Content-Length: 614 Bart Smaalders wrote: > If you want auditing and RBAC, figure out a way to do so that doesn't > place so heavy a tax on every project that wants to deliver on Solaris. > Rewriting or adding commands to every project is not acceptable - > and is pointless so long as we don't even fund command line interfaces > for all the config files Sun has introduced over the years. Re auditing: what are the requirements? Would a trap on writes to config files labeled as subject to audit gather enough information, or is finer grain required? Re RBAC: could ACLs be manipulated to enforce such access control? - Jeremy From Nicolas.Williams@sun.com Fri Apr 4 14:53:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34Lrns0010840 for ; Fri, 4 Apr 2008 14:53:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m34LrlLa018034 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 4 Apr 2008 22:53:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT00605M5NYW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 14:53:47 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT006PMM5MO300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 04 Apr 2008 14:53:46 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m34Lrkp2004134; Fri, 04 Apr 2008 16:53:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m34LrkEi004133; Fri, 04 Apr 2008 16:53:46 -0500 (CDT) Date: Fri, 04 Apr 2008 16:53:46 -0500 From: Nicolas Williams Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F6A293.3090408@wizmail.org> To: Jeremy Harris Cc: PSARC-ext@sun.com Mail-followup-to: Jeremy Harris , PSARC-ext@sun.com Message-id: <20080404215346.GB16998@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F6A293.3090408@wizmail.org> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 841 On Fri, Apr 04, 2008 at 10:50:11PM +0100, Jeremy Harris wrote: > Bart Smaalders wrote: > >If you want auditing and RBAC, figure out a way to do so that doesn't > >place so heavy a tax on every project that wants to deliver on Solaris. > >Rewriting or adding commands to every project is not acceptable - > >and is pointless so long as we don't even fund command line interfaces > >for all the config files Sun has introduced over the years. > > Re auditing: what are the requirements? Would a trap on writes to > config files labeled as subject to audit gather enough information, > or is finer grain required? > > Re RBAC: could ACLs be manipulated to enforce such access control? ZFS has audit SACL support, but the system doesn't actually honor audit SACLs (i.e., it doesn't audit applicable file events as a result of audit SACLs). From sacadmin Fri Apr 4 14:56:05 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34Lu5GR011154 for ; Fri, 4 Apr 2008 14:56:05 -0700 (PDT) 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 m34Lu4t1003933; Fri, 4 Apr 2008 14:56:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT0070RM9C2L00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 14:56:00 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT0061SM9BNZ10@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Apr 2008 14:55:59 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34LtxcQ018368; Fri, 04 Apr 2008 14:55:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00801M2WCZ00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Fri, 04 Apr 2008 14:55:59 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT00FF7M9A61G0@fe-sfbay-10.sun.com>; Fri, 04 Apr 2008 14:55:58 -0700 (PDT) Date: Fri, 04 Apr 2008 14:52:15 -0700 From: "Garrett D'Amore" Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F6890C.7050201@sun.com> Sender: Garrett.Damore@sun.com To: Tim Marsland Cc: Bart Smaalders , Darren J Moffat , psarc-members@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <47F6A30F.3080102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> <47F6890C.7050201@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1440 So in a nutshell, what I would like to see, is what role ARC needs (or can!) play in getting all this FOSS integrated? Right now as it stands, I think we (ARC) are just a roadblock for those cases. That's obviously not helpful. We need some kind of specific guidelines to follow, I think, that help us figure out what the balancing act between "core architecture" and "FOSS conglomeration" is. If the strong desire is to the latter, maybe ARC has little, if any, role to play. In any case, what I think I *am* hearing (and please tell me if I misunderstand!), is that ARC has little role remaining in helping to define any kind of overall system architecture -- rather the system we are moving to is one that is defined already by external forces. (Linux, etc.) (Yes, there are individual subsystems where ARC still plays a role -- bits in the kernel, SMF, FMA.... but the overall *system* includes the entirety -- kernel, libraries, utilities, windowing environment, etc. That system level engineering seems, to me at least, to be extinct at Sun.) Maybe its appropriate, given that, that some of us (thinking mostly about myself here) rethink our participation in ARC. If my engineering background and overall big-system architecture expertise isn't going to be exploited here, then quite possibly my time is better spent working on the actual software engineering tasks, as you already noted. -- Garrett From sacadmin Fri Apr 4 17:22:05 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m350M5JC015146 for ; Fri, 4 Apr 2008 17:22:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m350M2fA020077; Fri, 4 Apr 2008 18:22:03 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYT00E0PT0Q1Y00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 17:22:02 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYT00IR2T0QPUC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Apr 2008 17:22:02 -0700 (PDT) Received: from Macintosh-110.local (vpn-129-150-20-114.SFBay.Sun.COM [129.150.20.114]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m350M15s669952; Fri, 04 Apr 2008 17:22:01 -0700 (PDT) Date: Fri, 04 Apr 2008 17:22:00 -0700 From: Tim Marsland Subject: Re: [kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F6A30F.3080102@sun.com> To: "Garrett D'Amore" Cc: Bart Smaalders , Darren J Moffat , psarc-members@sun.com, Wyllys Ingersoll , "Mark A. Carlson" Message-id: <47F6C628.4020905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5367A.6060002@sun.com> <47F5396A.7070201@sun.com> <47F5F39C.1040703@Sun.COM> <47F645CF.3060702@sun.com> <47F66419.4030601@Sun.COM> <47F668D8.60301@sun.com> <47F6890C.7050201@sun.com> <47F6A30F.3080102@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 6085 Garrett D'Amore wrote: > So in a nutshell, what I would like to see, is what role ARC needs (or > can!) play in getting all this FOSS integrated? Right now as it stands, > I think we (ARC) are just a roadblock for those cases. That's obviously > not helpful. > > We need some kind of specific guidelines to follow, I think, that help > us figure out what the balancing act between "core architecture" and > "FOSS conglomeration" is. If the strong desire is to the latter, maybe > ARC has little, if any, role to play. We want to be good at being an "aggregator" of other peoples creations, while at the same time continuing to be an innovator in ways that differentiate our products. It is -not- the case that the ARC has no role to play in the "system architecture"; it simply cannot keep trying to play the old role. Fifteen years ago when many of our core principles were formed, the IP that makes up the system mostly belonged to us, and as a result, those principles mostly talked about how we allow ourselves to evolve that effectively static base in a way that met our binary compatibility business goals. A closed system, and we had a good model of how to evolve it. Now, in the world we're trying to get to, the IP that makes up the userland expression of a far broader FOSS-dominated platform will mostly -not- belong to us. We've already seen our *incremental* reactions to that. Calling things we don't own "Volatile" and "External" in the hope our declaring them "not owned by Sun" would mean they'd go away. They haven't, and now those tags, even when they do make it into the documentation, don't stop anyone from writing against their interfaces. Or take the rule of "no serendipitous discovery" which led to the creation of the otherwise unreferenced /usr/sfw confusion directory -- a place to hide FOSS in case someone wanted it. Sigh. All of these were "well meaning" at the time, but conceptually now overtaken by events and the competition. Our challenge is to make sense out of the new picture where we're trying to get to. There's still a namespace to manage. Even for the most familiar FOSS package, there are still installation options we can choose to adjust if justified. There are attributes we can flag in the packaging, the binaries, or documentation. There are flag-days we can choose to delay and/or co-deliver updates to reduce the confusion caused. These are all about interface management and version management, which is a core ARC activity. And as a set of engineering organizations, we can certainly *choose* to invest more in particular FOSS projects that are complimentary to, or in conflict with facilities of the core platform that we do place technical and/or business value on e.g. the ability to have a trusted platform, or a standards conformant platform, or for FOSS archivers to understand ZFS ACLs. Or that we make the performance of a set of FOSS projects be aligned with our server hardware capabilities. Or including DTrace probes in mySQL. Or we can argue that the cost of inclusion of a particular project is so high vs. some important attribute of the systems architecture that exclusion is required. Or that the conflict at least requires documentation. And so on. And I think the ARC has a role there in flagging problems, opportunities and reviewing solutions. As for your cry of "we need guidelines" .. you're probably not going to get them, sorry. I'm expecting the ARC to think about how it will do this for itself, rather than wait for the stone tablets to be passed down from some other place. But I do accept that the lack of the broader plan (see my previous mail) makes figuring this out a lot more difficult. (Perhaps that's the right topic for our "retry" at last Wednesday's discussion.) > In any case, what I think I *am* hearing (and please tell me if I > misunderstand!), is that ARC has little role remaining in helping to > define any kind of overall system architecture -- rather the system we > are moving to is one that is defined already by external forces. > (Linux, etc.) (Yes, there are individual subsystems where ARC still > plays a role -- bits in the kernel, SMF, FMA.... but the overall > *system* includes the entirety -- kernel, libraries, utilities, > windowing environment, etc. That system level engineering seems, to me > at least, to be extinct at Sun.) You vastly overstate the gloom here. I think systems engineering just operates at lots of different levels. To that end, your definition is too big and too small :) If I look at the world we're leaving behind, we had a lot of control over how userland evolved. Though practically speaking it was getting more and more stale; the only investment we actually *made* was in keeping up with the various standards efforts and thus forcing a more level playing field with AIX and HP-UX. And after all those standards efforts were themselves "external forces" we had little control over -- modulo Don Cragun's long suffering service in defending us from the more broken ideas the committees would occasionally surface. So I just don't accept that we were doing "systems" engineering in this space when our only real activity in userland for at least 12 years was ignoring non-critical bugs and being conformant to a set of standards which were, in some sense, designed to slow the evolution of Unix. We -were- doing systems engineering in other areas - ZFS, mdb, FMA, DTrace, resource management, Zones, fireengine, least priv, and the other stuff in S10 - and unless I'm much mistaken, none of those innovations would've been prevented if we'd integrated a boatload of userland FOSS tools into Solaris 10 back in 2004 as opposed to the apology that was delivered as the content of /usr/sfw. In my glass half full moments, I remind myself that yes, we have to deal with a world of other people generating interesting technology that is straightforward to run on our platform, and we get to deliver that technology at low cost. Try as I might, I can't help but see that as a Good Thing. tim From Milan.Jurik@sun.com Fri Apr 4 22:55:48 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m355tm10005336 for ; Fri, 4 Apr 2008 22:55:48 -0700 (PDT) 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 m355tlv1026195 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 4 Apr 2008 22:55:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYU006058GZJK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 04 Apr 2008 22:55:47 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYU00CA38GYORE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 04 Apr 2008 22:55:47 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m355tkM0021877 for ; Sat, 05 Apr 2008 05:55:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYU007018GKLJ00@fe-emea-09.sun.com> (original mail from Milan.Jurik@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 05 Apr 2008 06:55:46 +0100 (BST) Received: from [129.150.120.123] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYU0097X8GXN5F0@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 05 Apr 2008 06:55:45 +0100 (BST) Date: Sat, 05 Apr 2008 07:57:44 +0200 From: Milan Jurik Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47F5A8C8.1040307@sun.com> Sender: Milan.Jurik@sun.com To: Alan Coopersmith Cc: PSARC-ext@sun.com Message-id: <1207375064.2134.5.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47F5205B.9020405@sun.com> <47F5A23F.1040802@Sun.COM> <47F5A8C8.1040307@sun.com> Status: RO Content-Length: 719 Hi, Alan Coopersmith wrote: > Bart Smaalders wrote: > > Garrett D'Amore wrote: > > > >> must support the various Big Rules (including auditable administration), > > > > I asked Gary this question, but he declined to answer: > > > > What project satisfies this big Rule today? > > SMF. > > > If my project introduced a config file in /etc/, how could I meet this > > big rule? > > You could provide a fooconfig command, or plugin to some administration > toolset (if we had one with a future, unlike smc), but many projects don't, > which is why new config files in /etc were banned by the SMF policy. > And will somebody use such unusual thing? Will it simplify maintainance for admins? Best regards, Milan From gww@eng.sun.com Mon Apr 7 15:36:17 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37MaH2J004637 for ; Mon, 7 Apr 2008 15:36:17 -0700 (PDT) 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 m37MaFmF007679; Mon, 7 Apr 2008 15:36:17 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYZ00A0X84GMG00@brm-avmta-1.central.sun.com>; Mon, 07 Apr 2008 16:36:16 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYZ00IE684DBZE0@brm-avmta-1.central.sun.com>; Mon, 07 Apr 2008 16:36:13 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37MaChq035845; Mon, 07 Apr 2008 15:36:12 -0700 (PDT) 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 m37MZZif029620; Mon, 07 Apr 2008 15:35:35 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m37MZZaA029619; Mon, 07 Apr 2008 15:35:35 -0700 (PDT) Date: Mon, 07 Apr 2008 15:35:35 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module To: mark.carlson@sun.com, wyllys.ingersoll@sun.com Cc: PSARC-ext@sun.com, gdamore@sun.com Message-id: <200804072235.m37MZZaA029619@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 286 > The project team has been playing fetch-a-rock for too long. The final > specs have been submitted, I think Darren is planning on putting them in > the case dir very soon. This case should be approved so the team can > move ahead. Is there a spec update yet for this? Gary.. From huie-ying.lee@sun.com Mon Apr 7 15:49:04 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37Mn4Rr004971 for ; Mon, 7 Apr 2008 15:49:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37Mn3jP015760; Mon, 7 Apr 2008 15:49:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYZ00A0V8PROU00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Apr 2008 15:49:03 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYZ005Q38PPL570@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Apr 2008 15:49:01 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37Mn0si012479; Mon, 07 Apr 2008 15:49:00 -0700 (PDT) Received: from [129.146.108.12] (comforter.SFBay.Sun.COM [129.146.108.12]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m37Mmx707938; Mon, 07 Apr 2008 15:49:00 -0700 (PDT) Date: Mon, 07 Apr 2008 15:47:06 -0700 From: Huie-Ying Lee Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <200804072235.m37MZZaA029619@marduk.eng.sun.com> To: Gary Winiger Cc: mark.carlson@sun.com, wyllys.ingersoll@sun.com, PSARC-ext@sun.com, gdamore@sun.com Message-id: <47FAA46A.60202@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_M89U1XLwr/wvD2lUMK+gow)" X-PMX-Version: 5.4.1.325704 References: <200804072235.m37MZZaA029619@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 23665 This is a multi-part message in MIME format. --Boundary_(ID_M89U1XLwr/wvD2lUMK+gow) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Gary Winiger wrote: >> The project team has been playing fetch-a-rock for too long. The final >> specs have been submitted, I think Darren is planning on putting them in >> the case dir very soon. This case should be approved so the team can >> move ahead. > > Is there a spec update yet for this? > > Gary.. The updated spec and man pages can be found in the attached email. Thanks, Huie-Ying --Boundary_(ID_M89U1XLwr/wvD2lUMK+gow) Content-type: message/rfc822; name="Attached Message" Content-disposition: inline; filename="Attached Message" Return-path: Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2SGSuH8745506 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Mar 2008 09:28:56 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2SGStUA042675; Fri, 28 Mar 2008 09:28:55 -0700 (PDT) Received: from [129.146.108.12] (comforter.SFBay.Sun.COM [129.146.108.12]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m2SGSs722465; Fri, 28 Mar 2008 09:28:54 -0700 (PDT) Date: Fri, 28 Mar 2008 09:27:08 -0700 From: Huie-Ying Lee Subject: Re: PSARC/2006/283 final spec In-reply-to: <47ECCFE1.20904@Sun.COM> To: Darren J Moffat Cc: Anup Sekhar , Steve De Tar , Wyllys Ingersoll Message-id: <47ED1C5C.4000205@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_FhtCkmseEXhV0Au4IY/vEg)" References: <47ECCFE1.20904@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) This is a multi-part message in MIME format. --Boundary_(ID_FhtCkmseEXhV0Au4IY/vEg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Darren J Moffat wrote: > Since you are removing the pkcs11_eventmgt I need a final spec doc so I > can mark this case as closed approved. > > Once I have that in the case dir I'll close the case. > The updated final spec is attached here. Please remove the pkcs11_eventmgr.1 file from the case materials. I also updated the pam_pkcs11.5 to remove the command and man path names under the FILES: section. The pkcs11_inspect.1 and pklogin_finder.1 man pages were cleaned up a bit also. The updated man pages are attached here. Thanks, Huie-Ying --Boundary_(ID_FhtCkmseEXhV0Au4IY/vEg) Content-type: text/plain; name=pam_pkcs11.psarc_spec Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pam_pkcs11.psarc_spec File: pam_pkcs11.psarc_summary ========================================== The pam_pkcs11 module overview ========================================== The pam_pkcs11 module is a PAM authentication module for PKCS#11 token libraries. This module allows a user to login a system that supports PAM, using a certificate and its dedicated private key stored in a PKCS#11 token. The original source of this module is provided by opensc-project.org. The latest version is 0.6.0 which supports only the pam_authenticate() function for the authentication service. For more information, see http://www.opensc-project.org/pam_pkcs11 This pam_pkcs11 module supports any PKCS#11 token library. On Solaris, the PKCS#11 library to be used for this module is /usr/lib/libpkcs11.so.1, the Solaris Cryptographic Framework. An administrator can configure the pam_pkcs11 module to use a specific slot/token. Note that the original pam_pkcs11 module from OpenSC uses a slot number for the slot/token selection which is not always safe because there is no guaranteed ordering of slots returned from the PKCS#11 C_GetSlotList() function. To resolve this, on Solaris, the slot/token selection is changed to use the slot description instead. ========================================================= The pam_pkcs11 authentication/verification procedure ========================================================= The authentication and verification procedure is as following: Step 1: Find all the certificates in the PKCS#11 token Step 2: Find the certificate in the certificate list that matches the user For each certificate in the certificate list Verify the certificate to see if it is really issued by the CA certificate or if it has been revoked, based on the certificate verification policy specified in the configuration. If the certificate is valid, then check if it matches the user by using the certificate-to-user mappers specified in the configuration. If a good certificate is found, we are done Step 3: Signature verification If the "signature" policy is specified in the certificate verification policy in the configuration, then this module will find the private key on the token that is associated with the certificate and verify the public key inside the certificate and the private key are truly a pair with following algorithm: - Generates 128 random byte data. - Use the private key to sign the data and get a signature. (This will be done in the PKCS11 token). - Extract the public key from the certificate and verify the signature. ========================================== Deliverables: ========================================== Pam_pkcs11 module: /usr/lib/security/pam_pkcs11.so (Note: will support both 32bit and 64 bit versions.) Non-built-in Mapper modules: /usr/lib/pam_pkcs11/ldap_mapper.so /usr/lib/pam_pkcs11/opensc_mapper.so /usr/lib/pam_pkcs11/openssh_mapper.so (Note: will support both 32bit and 64 bit versions.) Configuration directories and files: /etc/security/pam_pkcs11/pam_pkcs11.conf /etc/security/pam_pkcs11/cacerts (The directory to store the CA certificates) /etc/security/pam_pkcs11/crls (The directory to store the CRL files) Sample Mapfiles and script: /etc/security/pam_pkcs11/digest_mapping.example /etc/security/pam_pkcs11/subject_mapping.example /etc/security/pam_pkcs11/mail_mapping.example /etc/security/pam_pkcs11/make_hash_link.sh Utility commands: /usr/lib/pam_pkcs11/pkcs11_inspect /usr/lib/pam_pkcs11/pklogin_finder (Note: will support both 32bit and 64bit versions.) man pages: /usr/share/man/man5/pam_pkcs11.5 /usr/share/man/man1/pklogin_finder.1 /usr/share/man/man1/pkcs11_inspect.1 ================================================== A usage example ================================================== The following example demonstrates how to use the pam_pkcs11 module with the Solaris cryptographic framework and the Solaris PKCS#11 softtoken to authenticate a user to log into a system. Set up a certificate with private key in the Solaris PKCS#11 softtoken: - Initialize the Solaris softtoken keystore with the "pktool setpin" command. - Create a self-signed certificate in the Solaris Softtoken keystore, using the "pktool gencert" command. - Export the certificate file from the Solaris Softtoken keystore, using the "pktool export" command. Configure the pam_pkcs11 module: - The /etc/security/pam_pkcs11/pam_pkcs11.conf file is the configuration file for the pam_pkcs11 module. An administrator should modify this file to configure the pam_pkcs11 module. In this example, we will use default values for all the entries. - Copy the CA certificate to the /etc/security/pam_pkcs11/cacerts directory and make a hash link with the make_hash_link.sh script. Note: A certificate that is self-signed is its own CA certificate. Therefore, in this example, the certificate is placed both in the keystore and in the CA certificate directory. - Set up the map files in the /etc/security/pam_pkc11 directory. Note: When a X509 certificate is provided, there are no direct ways to map a certificate to a login. The pam_pkcs11 module provides a configurable way with mappers to specify cert-to-user mapping. Many mappers are provided by Pam_pkcs11, for example, the common name (CN) mapper, the digest mapper, the Email mapper, or the LDAP mapper. An administrator can configure a mapper list in the pam_pkcs11.conf file. The mappers in the list will be used sequentially until the certificate is successfully matched with the user. Some mappers do not require a mapfile to be specified (eg. the CN mapper), while some other mappers do require a mapfile (eg. the digest mapper) in the /etc/security/pam_pkcs11 directory. Configure the /etc/pam.conf file: The pam_pkcs11.so service module can be used in the PAM chain. In this example, we will use only pam_pkcs11 for authentication. login auth requisite pam_pkcs11.so login auth required pam_unix_cred.so.1 Test: To test result, run "exec login" as below: -------------------------------------------------------------------- hylee@bula$exec login Please enter your username. login: hylee found the PKCS#11 slot with a token. Welcome Sun Software PKCS#11 softtoken! token password: XXXXXXXX Last login: Tue Feb 26 14:13:41 from comforter Sun Microsystems Inc. SunOS 5.11 snv_80 Dec. 15, 2007 SunOS Internal Development: root 2007-12-15 [onnv_80] bfu'ed from /ws/onnv-gate/archives/sparc/snv_80 on 2007-12-19 Sun Microsystems Inc. SunOS 5.11 snv_76 October 2007 -------------------------------------------------------------------- --Boundary_(ID_FhtCkmseEXhV0Au4IY/vEg) Content-type: text/plain; name=pam_pkcs11.5 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pam_pkcs11.5 Standards, Environments, and Macros pam_pkcs11(5) NAME pam_pkcs11 - PAM Authentication Module for PKCS#11 token libraries SYNOPSIS pam_pkcs11.so [debug] [config_file=] DESCRIPTION The pam_pkcs11 module implements pam_sm_authenticate(), which provides functionality to the PAM authentication stack. This module allows a user to login a system, using a X.509 certificate and its dedicated private key stored in a PKCS#11 token. This module currently supports the RSA algorithm only. To verify the dedicated private key is truly associated with the X.509 certificate, the following verification procedure is performed in this module by default: - Generate 128 random byte data - Sign the random data with the private key and get a signature. (This step will be done in the PKCS#11 token) - Verify the signature using the public key extracted from the certificate. For the verification of the users' certificates, locally stored CA certificates as well as either online or locally accessible CRLs are used. PAM CONFIGURATION The pam_pkcs11.so service module can be used in the PAM chain. The program that needs a PAM service should be configured in the /etc/pam.conf file. For details on how to configure PAM services, see the pam.conf manpage. Below are some usage examples. Example1: Use only pam_pkcs11 for authentication. login auth requisite pam_pkcs11.so.1 login auth required pam_unix_cred.so.1 Example2: Use pam_pkcs11 for authentication with fallback to standard unix authentication login auth sufficient pam_pkcs11.so.1 login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_unix_auth.so.1 PAM_PKCS11 CONFIGURATION To configure the pam_pkcs11 module, you must know: * Which PKCS #11 token you are going to use. * Which mapper(s) you need, and if needed, how to create and edit related mapping files * You'll also need the root Certificate Authority files, and if required, the Certificate Revocation Lists ones * The list of authorized users to login, and their corresponding certificates. To configure the pam_pkcs11 module, you need to modify the pam_pkcs11.conf configuration file which is in the /etc/security/pam_pkcs11 directory by default. For detailed information on how to configure the pam_pkcs11 module, see the PAM-PKCS11 User Manual http://www.opensc-project.org/pam_pkcs11/pam_pkcs11.html Below is an example to illustrate how to configure the pam_pkcs11 module for a user whose certificate and private key are stored in the Solaris pkcs11_softtoken keystore. This example uses the default certificate verification policy. * Set up the PKCS#11 module. On Solaris, the PKCS#11 module should be set to /usr/lib/libpkcs11.so.1, the PKCS#11 Cryptographic Framework library. * Set up the slot_description entry. The slot to be use is specified by the slot description. For example, slot_description = "Sun Crypto Softtoken". The default value for this entry is "none" which means to use the first slot with an available token. An administrator can use the "cryptoadm list -v" command to find all the available slots and their slot descriptions. For more information, see libpkcs11(3LIB) and cryptoadm(1m) man pages. * Install or create user certificates and its dedicated private keys in the specific PKCS#11 token. * Set up the certificate verification policy (cert_policy). If needed, set up CA certificate and CRL files. The certificate verification policy includes "none" - performs no verification "ca" - performs CA check "signature" - performs a signature check to ensure that private and public key matches "crl_xxx" - performs various certificate revocation checking Since this example uses the default policy which is "cert_policy = ca,signature", an administer needs to set up the CA certificates: - Copy the CA certificate to the /etc/security/pam_pkcs11/cacerts directory. Note that a certificate that is self-signed is its own CA certificate. Therefore, in this example, the certificate is placed both in the Softtoken keystore and in the CA certificate directory. - Make hash links for CA certificates $/etc/security/pam_pkcs11/make_hash_link.sh /etc/security/pam_pkcs11/cacerts * Set up the mappers and mapfiles. When a X509 certificate is provided, there are no direct ways to map a certificate to a login. The pam_pkcs11 module provides a configurable way with mappers to specify cert-to-user mapping. Many mappers are provided by the Pam_pkcs11 module, for example, the common name (CN) mapper, the digest mapper, the Email mapper, or the LDAP mapper. A user can configure a mapper list in the pam_pkcs11.conf file. The mappers in the list will be used sequentially until the certificate is successfully matched with the user. The default mapper list is use_mappers = digest, cn, pwent, uid, mail, subject, null; Some mappers do not require a mapfile to be specified (e.g. the common name mapper), while other mappers require mapfiles (e.g. the digest mapper). Some sample mapping files can be found in the /etc/security/pam_pkcs11 directory. OPTIONS: debug Enable debugging support config_file To specify the configuration file (default /etc/security/pam_pkcs11/pam_pkcs11.conf) FILES pam_pkcs11 module: /usr/lib/security/pam_pkcs11.so Mapper modules: /usr/lib/pam_pkcs11/ldap_mapper.so /usr/lib/pam_pkcs11/opensc_mapper.so /usr/lib/pam_pkcs11/openssh_mapper.so Configuration directories and files: /etc/security/pam_pkcs11/pam_pkcs11.conf /etc/security/pam_pkcs11/cacerts (The directory to store the CA certificates) /etc/security/pam_pkcs11/crls (The directory to store the CRL files) Sample Mapfiles and script: /etc/security/pam_pkcs11/digest_mapping.example /etc/security/pam_pkcs11/subject_mapping.example /etc/security/pam_pkcs11/mail_mapping.example /etc/security/pam_pkcs11/make_hash_link.sh Documentation: The OpenSC PAM-PKCS11 User Manual can also be found at the /usr/share/doc/pam_pkcs11 directory. AUTHOR Original PAM-pkcs11 was written by Mario Strasser . Newer versions are from Juan Antonio Mar- tinez . ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________________| | Availability | SUNWpampkcs11u | | | SUNWpampkcs11r | | | SUNWpampkcs11-docs | |_____________________________|_____________________________________| | Interface Stability | Module pathname: committed | | | Configuration file name: committed | | | Others: Volatile | |_____________________________|_____________________________________| SEE ALSO pam.conf(4), libpkcs11(3LIB), pkcs11_inspect(1), pklogin_finder(1). --Boundary_(ID_FhtCkmseEXhV0Au4IY/vEg) Content-type: text/plain; name=pkcs11_inspect.1 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pkcs11_inspect.1 PAM PKCS#11 pkcs11_inspect(1) NAME pkcs11_inspect - print certificate contents SYNOPSIS pkcs11_inspect [debug] [config_file=] DESCRIPTION pkcs11_inspect uses the pam_pkcs11 library infrastructure to get the content of a certificate and display it. pkcs11_inspect uses the same configuration file and argu- ments than pam_pkcs11(5) PAM module. It loads defined mapper modules, and use them to look into the certificate for required entries (ie: ms_mapper looks for ms UPN entries, and so on). When a mapper module finds a proper entry in the certifi- cate, it converts to UTF-8 and print it to stdout. OPTIONS debug Enable debugging output. config_file= Sets the configuration file to use. Default value is /etc/security/pam_pkcs11/pam_pkcs11.conf. As it uses the same configuration file as pam_pkcs11, all pam_pkcs11 options are also available. Note that some of them have no sense in a non-PAM environment, so they will be ignored. Some mapper options (mapfile, ignorecase) have no effect on certificate contents, so they will be ignored too. RETURN VALUE On success pkcs11_inspect prints on stdout all certificate contents that are found for mappers and returns 0. On error it returns 1. FILES /etc/security/pam_pkcs11/pam_pkcs11.conf EXAMPLES To run this program, just type: pkcs11_inspect Alternatively you can specify options: pkcs11_inspect debug config_file=${HOME}/.pam_pkcs11.conf Juan Antonio Martinez Last change: Aug 2005 1 PAM PKCS#11 pkcs11_inspect(1) AUTHORS Juan Antonio Martinez ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________________| | Availability | SUNWpampkcs11u | | | SUNWpampkcs11r | | | SUNWpampkcs11-docs | |_____________________________|_____________________________________| | Interface Stability | Volatile | | | Configuration file name: committed | |_____________________________|_____________________________________| SEE ALSO pam_pkcs11(5), pklogin_finder(1), PAM-PKCS11 User Manual Juan Antonio Martinez Last change: Aug 2005 2 --Boundary_(ID_FhtCkmseEXhV0Au4IY/vEg) Content-type: text/plain; name=pklogin_finder.1 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pklogin_finder.1 PAM-PKCS#11 pklogin_finder(1) NAME pklogin_finder - maps certificates into a user SYNTAX pklogin_finder [debug] [config_file=] DESCRIPTION pklogin_finder uses the pam_pkcs11 library infrastructure to interactively map a PKCS#11 provided certificate to a user. pklogin_finder uses the the same configuration file and arguments than pam_pkcs11(5) PAM module. Load defined mapper modules, and try to find a map between found certificates and a user login. OPTIONS debug Enable debugging output. Default is no debug. config_file= Sets the configuration file to use. Default value is /etc/security/pam_pkcs11/pam_pkcs11.conf. As it uses the same configuration file than pam_pkcs11, all pam_pkcs11 options are also available. Note that some of them has no sense in a non-PAM environment, so they will be ignored. RETURN VALUE On success pklogin_finder prints on stdout the login name and exits returns 0. On user mapping error it returns 1. On no user match it prints nothing and returns 2. FILES /etc/security/pam_pkcs11/pam_pkcs11.conf EXAMPLES To run this program, just type: pklogin_finder Alternatively you can specify options: pklogin_finder debug config_file=${HOME}/.pam_pkcs11.conf AUTHORS Juan Antonio Martinez ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________________| | Availability | SUNWpampkcs11u | | | SUNWpampkcs11r | | | SUNWpampkcs11-docs | |_____________________________|_____________________________________| | Interface Stability | Volatile | | | Configuration file name: committed | |_____________________________|_____________________________________| SEE ALSO pam_pkcs11(5), pkcs11_inspect(1), PAM-PKCS11 User Manual Juan Antonio Martinez Last change: Aug 2005 1 --Boundary_(ID_FhtCkmseEXhV0Au4IY/vEg)-- --Boundary_(ID_M89U1XLwr/wvD2lUMK+gow)-- From gdamore@sun.com Mon Apr 7 16:28:33 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37NSXT9006417 for ; Mon, 7 Apr 2008 16:28:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37NSS3d002161 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Apr 2008 17:28:33 -0600 (MDT) 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 <0JYZ00D1ZAJJPL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 17:28:31 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYZ00BNSAJI3Z20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 17:28:30 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m37NSUWa005652 for ; Mon, 07 Apr 2008 16:28:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYZ00E01AEV8Y00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 16:28:30 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYZ00FKSAJG0LF0@fe-sfbay-09.sun.com>; Mon, 07 Apr 2008 16:28:29 -0700 (PDT) Date: Mon, 07 Apr 2008 16:24:37 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module In-reply-to: <47FAA46A.60202@sun.com> Sender: Garrett.Damore@sun.com To: Huie-Ying Lee Cc: Gary Winiger , Mark.Carlson@sun.com, Wyllys.Ingersoll@sun.com, PSARC-ext@sun.com Message-id: <47FAAD35.7010408@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804072235.m37MZZaA029619@marduk.eng.sun.com> <47FAA46A.60202@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2652 Just out of curiosity, if everything else is Volatile, is there significant benefit to having the names of configuration files be "Committed"? (I mean apart from the pam.conf file, which of course *must* be Committed?) Otherwise, I believe the issue of "conformance to audit" has been discussed, and I'll defer to the judgment of more senior members (though I'd like to see a TCA for some kind of utility to simplify configuration -- or at least some "common standard set of configurations" with support for audit and rbac.) I'd also like to see a TCA for clean up of the make_hash_links.sh interface. Having a shell script off in /etc/security just seems a bit "unfinished" to me -- sort of like the original authors got to "good enough for my use", and then stopped working on it. (Seems like at a minimum, this utility should lose the .sh, move to /usr/sbin, and acquire a man page.) Its likely that I will *not* be at Wednesday's meeting, but if the above items are addressed (by TCA or TCR, and in the case of the concerns about audit to the satisfaction of those other "senior members"), then please consider my input as a vote to approve. -- Garrett Huie-Ying Lee wrote: > Gary Winiger wrote: >>> The project team has been playing fetch-a-rock for too long. The >>> final specs have been submitted, I think Darren is planning on >>> putting them in the case dir very soon. This case should be >>> approved so the team can move ahead. >> >> Is there a spec update yet for this? >> >> Gary.. > > The updated spec and man pages can be found in the attached email. > > Thanks, > Huie-Ying > ------------------------------------------------------------------------ > > Subject: > Re: PSARC/2006/283 final spec > From: > Huie-Ying Lee > Date: > Fri, 28 Mar 2008 09:27:08 -0700 > To: > Darren J Moffat > > To: > Darren J Moffat > CC: > Anup Sekhar , Steve De Tar > , Wyllys Ingersoll > > > Darren J Moffat wrote: >> Since you are removing the pkcs11_eventmgt I need a final spec doc so >> I can mark this case as closed approved. >> >> Once I have that in the case dir I'll close the case. >> > > The updated final spec is attached here. Please remove the > pkcs11_eventmgr.1 file from the case materials. > > I also updated the pam_pkcs11.5 to remove the command and man path > names under the FILES: section. The pkcs11_inspect.1 and > pklogin_finder.1 man pages were cleaned up a bit also. The updated > man pages are attached here. > > > Thanks, > Huie-Ying From gww@eng.sun.com Wed Apr 9 18:49:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3A1ntSq014284 for ; Wed, 9 Apr 2008 18:49:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3A1nnKL011722; Thu, 10 Apr 2008 09:49:52 +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 <0JZ300D036F3NH00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Apr 2008 18:49:51 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ30075W6F3JP80@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Apr 2008 18:49:51 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3A1noqh031592; Wed, 09 Apr 2008 18:49:50 -0700 (PDT) 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 m3A1nGLv004119; Wed, 09 Apr 2008 18:49:16 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m3A1nGbc004118; Wed, 09 Apr 2008 18:49:16 -0700 (PDT) Date: Wed, 09 Apr 2008 18:49:16 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2006/283 Certificate & PKCS#11 PAM, module To: Huie-Ying.Lee@sun.com, gdamore@sun.com Cc: Mark.Carlson@sun.com, PSARC-ext@sun.com, Wyllys.Ingersoll@sun.com, gww@eng.sun.com Message-id: <200804100149.m3A1nGbc004118@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 95 This case was rerailed at today's PSARC meeting. I've put the updated spec in final.materials