From huie-ying.lee at sun.com Thu Oct 4 16:33:29 2007 From: huie-ying.lee at sun.com (Huie-Ying Lee) Date: Thu, 04 Oct 2007 16:33:29 -0700 Subject: [kmf-discuss] design review request for KMF pluggability enhancements Message-ID: <47057849.8060906@sun.com> Currently, all three plugins in KMF (key management framework) are hard-coded in libkmf and KMF is unable to accomodate additional plugins automatically. This enhancement will provide capabilities for users to add/remove additional plugins dynamically. My preliminary proposal has been reviewed by the KMF core team. Below is the updated design, and I would appreciate any comments by Oct/12/2007. Thanks, Huie-Ying ======================================================= A New Private configuration file: /etc/crypto/kmf.conf ======================================================= The KMF configuration file is "/etc/crypto/kmf.conf" with permission "644". This file specifies only non-default keystore plugins with the following format: keystore_name:module_path=xxx[;option=option_str] The "keystore_name" field specifies the keystore name. The "module_path" field specifies the pathname to a KMF plugin shared library object. If the pathname is not absolute, shared library objects are assumed to be relative to /usr/lib/security/$ISA/. The ISA token is replaced by an implementation defined directory name which defines the path relative to the calling program's instruction set architecture. The option field specifies an option string which would only be processed by the plugin. ================================================== Changes to the kmfcfg command ================================================== 1) A new "install" subcommand will be added to the kmfcfg command. $kmfcfg install keystore=keystore_name modulepath=path [option=option_str] This command installs a new plugin into the Key Management framework. Internally, a new entry for this plugin will be added into the /etc/crypto/kmf.conf file. 2) A new "uninstall" subcommand will be added to the kmfcfg command. $kmfcfg uninstall keystore=keystore_name This command will uninstall the plugin with the kstype name. Intenally, the entry with the keystore name will be removed from /etc/crypto/kmf.conf file. 3) A new "plugin" parameter will be added to the list subcommand. $kmfcfg list plugin - This command displays all the plugins in the system, including 3 default plugins. For example, if there is an additional plugin in the system, the output will look like $kmfcfg list plugin pkcs11:kmf_pkcs11.so.1 (built-in) file:kmf_openssl.so.1 (built-in) nss:kmf_nss.so.1 (built-in) new_plugin:/opt/lib/new_plugin.so.1;option=debug Note that without the "plugin" keyword, "kmfcfg list" will show the policy stuff as before. 4) A new "modify plugin" subcommand will be added to the modify subcommand. $kmfcfg modify plugin keystore=keystore_name option=option_str This subcommand allows an admininstrator to modify the plugin option. The plugin option is defined by the plugin and will be interpreted by the plugin specifically, therefore this command will accept any option string. ================================================== Changes to libkmf ================================================== 1) Changes to kmf_initialize() In kmf_initialize(), the 3 default plugins will be loaded first. If there is any new plugin in the /etc/crypto/kmf.conf file, the new plugins will be loaded sequentially and a new keystore type (a number actually, starting from 4) will be assigned to each new plugin. Internally, a global extra_plugin_list for all the additional plugins will be created after the first kmf_initialize() is called. Once it is set, this global extra_plugin_list will not be changed through out the lifetime of the process. 2) A new get_plugin_info() API will be added. KMF_RETURN kmf_get_plugin_info(KMF_HANDLE_T handle, char *keystore_name, KMF_KEYSTORE_TYPE *kstype, char **option) kstype_name - input kstype - output option - output This function takes a keystore name as input and returns a new KMF_KEYSTORE_TYPE value. If the option argument is not NULL, then this function will return the plugin option if this is a plugin option. Note that the returned "kstype" value should be used to access the new plugin's SPI. ========================================================= New plugin package requirement and class action scripts ====================================================== For a new plugin library, we would like it to be installed into the Key Management Framework during the pkgadd time and uninstalled during the pkgrm time automatically. To achieve this, two class action scripts will be added in the /usr/sadm/install/scripts directory. i.kmfconf -> the installation class action script r.kmfconf -> the removal class action script Accordingly, the new plugin package should do the following: 1. Add the "kmfconf" class into the CLASSES string of the pkginfo.tmpl file. 2. Create an input file "kmf.conf" in the "etc/crypto" directory and The syntax of the input file is same as the kmf.conf file keystore_name:module_path=xxx[;option=xxx] -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: kmfcfg.1.new URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kmfcfg.1.diff Type: text/x-patch Size: 1557 bytes Desc: not available URL: From Darren.Moffat at Sun.COM Fri Oct 5 03:33:18 2007 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Fri, 05 Oct 2007 11:33:18 +0100 Subject: [kmf-discuss] pktool genkey outfile= vs dir= Message-ID: <470612EE.6000108@Sun.COM> Why does genkey not allow a pathname for outfile= instead I have to specify both outfile= and dir=. This is very non UNIX like and makes scripting much harder than it should be. This has already confused one person using pktool to generate keys for ZFS Crypto. -- Darren J Moffat From darrenm at opensolaris.org Fri Oct 5 03:43:13 2007 From: darrenm at opensolaris.org (Darren J Moffat) Date: Fri, 05 Oct 2007 11:43:13 +0100 Subject: [kmf-discuss] pktool genkey outfile= vs dir= In-Reply-To: <470612EE.6000108@Sun.COM> References: <470612EE.6000108@Sun.COM> Message-ID: <47061541.7050300@opensolaris.org> Darren J Moffat wrote: > Why does genkey not allow a pathname for outfile= instead I have to > specify both outfile= and dir=. This is very non UNIX like and makes > scripting much harder than it should be. > > This has already confused one person using pktool to generate keys for > ZFS Crypto. A follow up on this, not only is it confusing it has led to a very confusing bug: braveheart# mkdir tank braveheart# pwd / braveheart# ls -ld tank drwxr-xr-x 2 root root 512 Oct 5 11:39 tank braveheart# truss -t open pktool genkey keystore=file keytype=aes keylen=256 dir=/etc/zfs/keys outkey=tank .... open("tank", O_RDONLY|O_CREAT|O_EXCL, 0600) Err#17 EEXIST Cannot write the indicated output key file (tank). Error generating key: libkmf error: KMF_ERR_BAD_PARAMETER Note that the cwd has a "directory" named tank but I told pktool to put the keyfile named tank in a different directory to the current one. This bug is a direct result of the strange UI and would not have happened had outfile be able to accept a full path as is normal in UNIX. -- Darren J Moffat From wyllys.ingersoll at sun.com Fri Oct 5 06:07:44 2007 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Fri, 05 Oct 2007 09:07:44 -0400 Subject: [kmf-discuss] pktool genkey outfile= vs dir= In-Reply-To: <47061541.7050300@opensolaris.org> References: <470612EE.6000108@Sun.COM> <47061541.7050300@opensolaris.org> Message-ID: <47063720.5090302@sun.com> Darren J Moffat wrote: > Darren J Moffat wrote: > >> Why does genkey not allow a pathname for outfile= instead I have to >> specify both outfile= and dir=. This is very non UNIX like and makes >> scripting much harder than it should be. >> >> This has already confused one person using pktool to generate keys for >> ZFS Crypto. >> > > A follow up on this, not only is it confusing it has led to a very > confusing bug: > > braveheart# mkdir tank > braveheart# pwd > / > braveheart# ls -ld tank > drwxr-xr-x 2 root root 512 Oct 5 11:39 tank > braveheart# truss -t open pktool genkey keystore=file keytype=aes > keylen=256 dir=/etc/zfs/keys outkey=tank > .... > open("tank", O_RDONLY|O_CREAT|O_EXCL, 0600) Err#17 EEXIST > Cannot write the indicated output key file (tank). > > Error generating key: > libkmf error: KMF_ERR_BAD_PARAMETER > > > Note that the cwd has a "directory" named tank but I told pktool to put > the keyfile named tank in a different directory to the current one. > > This bug is a direct result of the strange UI and would not have > happened had outfile be able to accept a full path as is normal in UNIX. > > Sounds like a bug, please file it. We will fix it soon. -Wyllys From darrenm at opensolaris.org Fri Oct 5 06:30:18 2007 From: darrenm at opensolaris.org (Darren J Moffat) Date: Fri, 05 Oct 2007 14:30:18 +0100 Subject: [kmf-discuss] pktool genkey outfile= vs dir= In-Reply-To: <47063720.5090302@sun.com> References: <470612EE.6000108@Sun.COM> <47061541.7050300@opensolaris.org> <47063720.5090302@sun.com> Message-ID: <47063C6A.9010002@opensolaris.org> Wyllys Ingersoll wrote: > Darren J Moffat wrote: >> Darren J Moffat wrote: >> >>> Why does genkey not allow a pathname for outfile= instead I have to >>> specify both outfile= and dir=. This is very non UNIX like and makes >>> scripting much harder than it should be. >>> >>> This has already confused one person using pktool to generate keys for >>> ZFS Crypto. >>> >> A follow up on this, not only is it confusing it has led to a very >> confusing bug: > Sounds like a bug, please file it. We will fix it soon. 6613494 -- Darren J Moffat From wyllys.ingersoll at sun.com Fri Oct 5 07:22:04 2007 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Fri, 05 Oct 2007 10:22:04 -0400 Subject: [kmf-discuss] code review wanted for pktool fixes Message-ID: <4706488C.5000804@sun.com> I have a webrev for the following fixes, please have a look and send comments. 6612107 pktool list objtype=cert Serial: oddity 6612173 pktool interactive mode should ask more questions 6612636 pktool delete is inconsistent 6613494 pktool fails creation outkey = in dir= if there is a file/dir in current dir of same name http://cr.opensolaris.org/~wyllys/kmf thanks, Wyllys From wyllys.ingersoll at sun.com Wed Oct 17 12:38:44 2007 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Wed, 17 Oct 2007 15:38:44 -0400 Subject: [kmf-discuss] KMF Pluggability Enhancements [PSARC/2007/604 FastTrack timeout 10/24/2007] In-Reply-To: <200710171926.l9HJQ9h4007656@borg.SFBay.Sun.COM> References: <200710171926.l9HJQ9h4007656@borg.SFBay.Sun.COM> Message-ID: <471664C4.9010601@sun.com> The updated man page for kmfcfg(1) is in the case directory (orig, diff, and new) -Wyllys Wyllys Ingersoll wrote: > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > KMF Pluggability Enhancements > 1.2. Name of Document Author/Supplier: > Author: Huie Lee > 1.3 Date of This Document: > 17 October, 2007 > 4. Technical Description > Proposal: KMF Dynamic Plugin Support > Submitter: Huie-Ying Lee > Sponsor: Wyllys Ingersoll > > Interface Taxonomy: libkmf - Committed > kmfcfg CLI - Uncommitted > /etc/crypto/kmf.conf - Private > > Release Binding: micro/patch > > ============================================================================= > Background: > ============================================================================= > Currently, all three plugins in KMF (key management framework) are hard-coded > in libkmf and KMF is unable to accomodate additional plugins automatically. > This enhancement will provide capabilities for users to add/remove additional > plugins dynamically. > > ======================================================= > A New Private configuration file: /etc/crypto/kmf.conf > Interface Taxonomy: Private > ======================================================= > > The KMF configuration file is "/etc/crypto/kmf.conf" with permission > "644". This file specifies only non-default keystore plugins with the > following format: > > keystore:modulepath=xxx[;option=option_str] > > The "keystore" field specifies the keystore name. > > The "modulepath" field specifies the pathname to a KMF plugin shared > library object. If the pathname is not absolute, shared library > objects are assumed to be relative to /usr/lib/security/$ISA/. > The ISA token is replaced by an implementation defined directory name > which defines the path relative to the calling program's instruction > set architecture. > > The option field specifies an option string which would only > be processed by the plugin. > > > ================================================== > Changes to the kmfcfg command > ================================================== > 1) A new "install" subcommand will be added to the kmfcfg command. > > $kmfcfg install keystore=keystore_name modulepath=path [option=option_str] > > This command installs a new plugin into the Key Management framework. > Internally, a new entry for this plugin will be added into the > /etc/crypto/kmf.conf file. > > > 2) A new "uninstall" subcommand will be added to the kmfcfg command. > > $kmfcfg uninstall keystore=keystore_name > > This command will uninstall the plugin with the kstype name. > Intenally, the entry with the keystore name will be removed from > /etc/crypto/kmf.conf file. > > 3) A new "plugin" parameter will be added to the list subcommand. > > $kmfcfg list plugin > > - This command displays all the plugins in the system, including 3 default > plugins. For example, if there is an additional plugin in the system, > the output will look like > > $kmfcfg list plugin > pkcs11:kmf_pkcs11.so.1 (built-in) > file:kmf_openssl.so.1 (built-in) > nss:kmf_nss.so.1 (built-in) > new_plugin:/opt/lib/new_plugin.so.1;option=debug > > Note that without the "plugin" keyword, "kmfcfg list" will show the policy > stuff as before. > > 4) A new "modify plugin" subcommand will be added to the modify subcommand. > > $ kmfcfg modify plugin keystore=keystore_name option=option_str > > This subcommand allows an admininstrator to modify the plugin option. > The plugin option is defined by the plugin and will be interpreted by the > plugin specifically, therefore this command will accept any option string. > > ================================================== > Changes to libkmf (Committed) > ================================================== > 1) A new kmf_get_plugin_info() API will be added. > > KMF_RETURN > kmf_get_plugin_info(KMF_HANDLE_T handle, char *keystore_name, > KMF_KEYSTORE_TYPE *kstype, char **option) > > kstype_name - input > kstype - output > option - output > > This function takes a keystore name as input and returns a new > KMF_KEYSTORE_TYPE value. If the option argument is not NULL, then > this function will return the plugin option if this is an option > string specified for the plugin. > > Note that the returned "kstype" value should be used to access the new > plugin's SPI. > > ========================================================= > New plugin package requirement and class action scripts > ====================================================== > For a new plugin library, we would like it to be installed into the Key > Management Framework during the pkgadd time and uninstalled during the pkgrm > time automatically. To achieve this, two class action scripts will be added > in the /usr/sadm/install/scripts directory. > > i.kmfconf -> the installation class action script > r.kmfconf -> the removal class action script > > Accordingly, the new plugin package should do the following: > > 1. Add the "kmfconf" class into the CLASSES string of the pkginfo.tmpl > file. > > 2. Create an input file "kmf.conf" in the "etc/crypto" directory and > The syntax of the input file is same as the kmf.conf file > > keystore:modulepath=xxx[;option=xxx] > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From wyllys.ingersoll at sun.com Wed Oct 17 12:45:00 2007 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Wed, 17 Oct 2007 15:45:00 -0400 Subject: [kmf-discuss] KMF Pluggability Enhancements [PSARC/2007/604 FastTrack timeout 10/24/2007] In-Reply-To: <200710171926.l9HJQ9h4007656@borg.SFBay.Sun.COM> References: <200710171926.l9HJQ9h4007656@borg.SFBay.Sun.COM> Message-ID: <4716663C.70809@sun.com> The updated man page for kmfcfg(1) is in the case directory (orig, diff, and new) -Wyllys Wyllys Ingersoll wrote: > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > KMF Pluggability Enhancements > 1.2. Name of Document Author/Supplier: > Author: Huie Lee > 1.3 Date of This Document: > 17 October, 2007 > 4. Technical Description > Proposal: KMF Dynamic Plugin Support > Submitter: Huie-Ying Lee > Sponsor: Wyllys Ingersoll > > Interface Taxonomy: libkmf - Committed > kmfcfg CLI - Uncommitted > /etc/crypto/kmf.conf - Private > > Release Binding: micro/patch > > ============================================================================= > Background: > ============================================================================= > Currently, all three plugins in KMF (key management framework) are hard-coded > in libkmf and KMF is unable to accomodate additional plugins automatically. > This enhancement will provide capabilities for users to add/remove additional > plugins dynamically. > > ======================================================= > A New Private configuration file: /etc/crypto/kmf.conf > Interface Taxonomy: Private > ======================================================= > > The KMF configuration file is "/etc/crypto/kmf.conf" with permission > "644". This file specifies only non-default keystore plugins with the > following format: > > keystore:modulepath=xxx[;option=option_str] > > The "keystore" field specifies the keystore name. > > The "modulepath" field specifies the pathname to a KMF plugin shared > library object. If the pathname is not absolute, shared library > objects are assumed to be relative to /usr/lib/security/$ISA/. > The ISA token is replaced by an implementation defined directory name > which defines the path relative to the calling program's instruction > set architecture. > > The option field specifies an option string which would only > be processed by the plugin. > > > ================================================== > Changes to the kmfcfg command > ================================================== > 1) A new "install" subcommand will be added to the kmfcfg command. > > $kmfcfg install keystore=keystore_name modulepath=path [option=option_str] > > This command installs a new plugin into the Key Management framework. > Internally, a new entry for this plugin will be added into the > /etc/crypto/kmf.conf file. > > > 2) A new "uninstall" subcommand will be added to the kmfcfg command. > > $kmfcfg uninstall keystore=keystore_name > > This command will uninstall the plugin with the kstype name. > Intenally, the entry with the keystore name will be removed from > /etc/crypto/kmf.conf file. > > 3) A new "plugin" parameter will be added to the list subcommand. > > $kmfcfg list plugin > > - This command displays all the plugins in the system, including 3 default > plugins. For example, if there is an additional plugin in the system, > the output will look like > > $kmfcfg list plugin > pkcs11:kmf_pkcs11.so.1 (built-in) > file:kmf_openssl.so.1 (built-in) > nss:kmf_nss.so.1 (built-in) > new_plugin:/opt/lib/new_plugin.so.1;option=debug > > Note that without the "plugin" keyword, "kmfcfg list" will show the policy > stuff as before. > > 4) A new "modify plugin" subcommand will be added to the modify subcommand. > > $ kmfcfg modify plugin keystore=keystore_name option=option_str > > This subcommand allows an admininstrator to modify the plugin option. > The plugin option is defined by the plugin and will be interpreted by the > plugin specifically, therefore this command will accept any option string. > > ================================================== > Changes to libkmf (Committed) > ================================================== > 1) A new kmf_get_plugin_info() API will be added. > > KMF_RETURN > kmf_get_plugin_info(KMF_HANDLE_T handle, char *keystore_name, > KMF_KEYSTORE_TYPE *kstype, char **option) > > kstype_name - input > kstype - output > option - output > > This function takes a keystore name as input and returns a new > KMF_KEYSTORE_TYPE value. If the option argument is not NULL, then > this function will return the plugin option if this is an option > string specified for the plugin. > > Note that the returned "kstype" value should be used to access the new > plugin's SPI. > > ========================================================= > New plugin package requirement and class action scripts > ====================================================== > For a new plugin library, we would like it to be installed into the Key > Management Framework during the pkgadd time and uninstalled during the pkgrm > time automatically. To achieve this, two class action scripts will be added > in the /usr/sadm/install/scripts directory. > > i.kmfconf -> the installation class action script > r.kmfconf -> the removal class action script > > Accordingly, the new plugin package should do the following: > > 1. Add the "kmfconf" class into the CLASSES string of the pkginfo.tmpl > file. > > 2. Create an input file "kmf.conf" in the "etc/crypto" directory and > The syntax of the input file is same as the kmf.conf file > > keystore:modulepath=xxx[;option=xxx] > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From wyllys.ingersoll at sun.com Wed Oct 24 12:04:34 2007 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Wed, 24 Oct 2007 15:04:34 -0400 Subject: [kmf-discuss] PSARC 2007/604 KMF Pluggability Enhancements Message-ID: <471F9742.4040208@sun.com> This case was approved at today's meeting. -Wyllys