From sacadmin Thu Mar 22 11:09:49 2007 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MI9nlU010797 for ; Thu, 22 Mar 2007 11:09:49 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2MI9nSt015948; Thu, 22 Mar 2007 11:09:49 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l2MI9n8a015947; Thu, 22 Mar 2007 11:09:49 -0700 (PDT) From: Michael Shapiro Message-Id: <200703221809.l2MI9n8a015947@zion.eng.sun.com> Subject: PSARC 2007/177 SMF Sensitive Property Storage To: psarc@sac.sfbay.sun.com Date: Thu, 22 Mar 2007 11:09:49 -0700 (PDT) Cc: mws@sun.com, keith.wesolowski@sun.com X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 10870 I'm sponsoring the following fast track for Keith Wesolowski. The case seeks binding for a Micro/Patch release (i.e. a Solaris Update). The timer is set for March 30. The case spec is below and a copy is in the inception.materials/ directory. Also found in the materials directory are diffs to all relevant SMF man pages. -Mike --8<-- smf(5) enhancements for storage of sensitive properties Keith M Wesolowski 14 March 2007 ident "@(#)smf-case 1.6 07/03/21 SMI" 1. Description This case describes a set of modifications to svc.configd(1M) and related administrative tools to support storage of, and restriction of access to, sensitive application properties such as passwords. This case seeks Micro/Patch Release binding. 2. Discussion 2.1. The read_authorization property Currently, creation, modification, and deletion of property groups and properties is permitted only to client processes with the full set of effective privileges. In addition, processes with certain RBAC authorizations are permitted to change repository contents under certain circumstances. Finally, smf permits the addition of arbitrary authorizations to perform these actions on a per-property group basis[0]. All properties in all property groups may be read by any process. This case introduces read_authorization as an analogue to the existing value_authorization and modify_authorization properties. 2.1.1. Definition The read_authorization property may optionally be added to any property group of type application (SCF_GROUP_APPLICATION). It is defined to be a string-valued property with zero or more values. Each string value (if any) of this property will be interpreted as the name of an rbac(5) authorization defined in auth_attr(4). A read_authorization property which is not string-valued will not be interpreted specially. Property groups of types framework, method, and dependency describe the state and configuration of the service or instance with respect to SMF itself. Because properties in these groups have specific well-defined effects on the behaviour of SMF, any mechanism which may render any combination of these properties invisible may have complex side effects. Because the schemas of these groups are already well-defined and none of the data they contain is sensitive, there is no reason to address the complex failure semantics associated with read access controls on these group types. Therefore, this case reserves, but does not define, the behaviour of the 'read_authorization' property with respect to these group types. Future enhancements such as templates[1] are expected to permit finer-grained control over the meaning of this and similar properties within a particular group. 2.1.2. svc.configd(1M) RPC changes Property create, modify, and delete semantics are not modified by this case, nor are create and delete semantics of property groups. Read semantics are unchanged with respect to properties in property groups which do not contain a string-valued read_authorization property. Those property groups which do contain this property, even if it has no values, are referred to herein as sensitive property groups (SPGs). The behaviour observed by clients attempting to obtain the value(s) of a property in a SPG will be as follows: - If the requesting client would be permitted to modify the property, it will be permitted to read the value(s); otherwise, - If the requesting client has one or more of the authorizations named by the 'read_authorization' property in the same SPG, it will be permitted to read the value(s); otherwise, - The requesting client will not be permitted to read the value(s) and will receive the REP_PROTOCOL_FAIL_PERMISSION_DENIED error code. While the client cannot distinguish between failure due to locally-enforced policy and backend-enforced policy (in the networked repository case), this shortcoming also exists with respect to the existing add/modify/delete policies. This case does not attempt to address this deficiency. 2.2. libscf(3LIB) changes libscf(3LIB), as originally defined[2] and updated[3] already provides an appropriate error code for use by clients when the contacted svc.configd(1M) denies permission to perform the requested operation. This case extends the use of that error code to the cases listed in 2.1.2 above. The following functions will fail and set the libscf(3LIB) error value for the calling thread to SCF_ERROR_PERMISSION_DENIED if the contacted svc.configd(1M) returns an error code of REP_PROTOCOL_FAIL_PERMISSION_DENIED in response: scf_property_get_value scf_iter_next_value 2.3. svcprop(1) changes With respect to SPGs, svcprop(1)'s behaviour is modified as follows: - If a property or property group was explicitly specified with -p, and svc.configd(1M) denies access to the values of the specified property/ies, svcprop(1) will abort and, unless the '-q' option was provided, display an error message. - If no property or property group was specified, properties for which the user lacks appropriate authorization to read will be displayed as if they had zero values (the present behaviour is to display the empty string for the value of such properties). 2.4. svccfg(1M) changes 2.4.1. export changes, introduction of export -a 'svccfg export' is modified to export the values of properties in SPGs as if they had no values, regardless of whether the user performing the operation has the required authorization. This prevents accidental exposure of sensitive data in XML documents used for interchange purposes. To provide the ability to export documents containing the values of sensitive properties, we introduce the '-a' option to the export subcommand. With this option, 'export' will export all properties in SPGs if the user has sufficient authorization to read them. Otherwise, upon encountering a property which cannot be read due to access controls, the command terminates and displays an appropriate error message. 2.4.2. archive changes The purpose of the 'archive' subcommand is to dump the entire repository in a format "suitable for a relocatable repository backup"[4]. In the presence of SPGs, this effectively requires that the user executing the command have sufficient authorization to read all values of all properties, else the archive will be incomplete. Accordingly, this subcommand will fail and display an error message if a property value cannot be read. 2.5. auditing An AUE_smf_read_prop audit record will be generated when an attempt is made to read properties in SPGs. This record will contain the FMRI of the property being read and the status (success or failure) of the attempt to read it, as well as the authorization used (if successful) or the most specific authorization that would have been required (if unsuccessful) to read the value. 3. Manual page changes Diffs to relevant manual pages are included in the case materials. Modified man pages are: svcprop(1) svccfg(1M) scf_property_create(3SCF) scf_iter_create(3SCF) smf_security(5) 4. SMF policy changes This section details changes required to the 'Service Management Facility (SMF) usage' policy[5]. 4.1. Guidance The third bulleted item in 'Guidance for Delivery of SMF Services' currently reads: # Services must provide service related RBAC authorizations, as # appropriate, by providing service specific values for the # action_authorization, modify_authorization and # value_authorization of property groups. See smf_security(5). # These authorizations must follow the form of # "solaris.smf.{manage, modify, value}." respectively. These # authorizations must be delivered into an appropriate Rights # profile, either new or existing. This guidance shall be altered to read: # Services must provide service related RBAC authorizations, as # appropriate, by providing service specific values for the | action_authorization, modify_authorization, | value_authorization, and read_authorization of property | groups. See smf_security(5). These authorizations must follow | the form of | "solaris.smf.{manage, modify, value, read}.," # respectively. These authorizations must be delivered into an # appropriate Rights profile, either new or existing. 4.2. Appendix B Appendix B currently reads: # It should be noted that configuration data residing in the SCF # repository is world-readable. Projects with configuration data # that is deemed sensitive in nature or that should remain # private from a security standpoint must consult with the ARC # to determine if the Service Configuration Facility is the # appropriate repository for their data. With the implementation of the changes specified above, this guidance is no longer correct. It shall be amended to read as follows: # It should be noted that configuration data residing in the SCF | repository is world-readable by default. Projects with | configuration data that is deemed sensitive in nature or that | should remain private from a security standpoint must consult | with the ARC to determine if the Service Configuration | Facility is the appropriate repository for their data. If so, | the property group(s) intended to contain sensitive data must | be defined in manifests with an appropriate read_authorization | property (see smf_security(5)), and no sensitive information | may be delivered in the manifest itself. 5. Interface table 5.1. Interfaces Exported Well-known property 'read_authorization' Committed No case explicitly defines the commitment level of the well-known properties 'modify_authorization' and 'value_authorization'[6]. Given their semantics, their presence in smf_security(5), and the clear intent that they be introduced as Evolving, this case also clarifies them as follows: Well-known property 'modify_authorization' Committed Well-known property 'value_authorization' Committed The intent of this case is that 'read_authorization' be a peer of these existing well-known properties and therefore have the same commitment level. 5.2. Interfaces Imported None. 6. References [0] PSARC/2002/547 Greenline; see C.35, smf_security(5) [1] http://www.opensolaris.org/os/project/vpanels/templates/ [2] PSARC/2002/547 Greenline; see C.10, scf_error(3SCF) [3] PSARC/2004/525 libscf(3LIB) updates [4] Ibid.; see C.6, svccfg(1M) [5] http://www.opensolaris.org/os/community/arc/policies/SMF-policy/ [6] PSARC/2002/547 Greenline; see App. D From sacadmin Thu Mar 22 11:57:19 2007 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MIvJLd012841 for ; Thu, 22 Mar 2007 11:57:19 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MIvHH5019635; Thu, 22 Mar 2007 14:57:17 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2MIvH4K028906; Thu, 22 Mar 2007 14:57:17 -0400 (EDT) Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage From: Bill Sommerfeld To: Michael Shapiro Cc: psarc@sac.sfbay.sun.com, mws@sun.com, keith.wesolowski@sun.com In-Reply-To: <200703221809.l2MI9n8a015947@zion.eng.sun.com> References: <200703221809.l2MI9n8a015947@zion.eng.sun.com> Content-Type: text/plain Date: Thu, 22 Mar 2007 14:57:15 -0400 Message-Id: <1174589836.27921.28.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 582 I'm not comfortable with mixing sensitive properties into the main property database - in the past, my advice to other projects (including the wifi folks) has always been to isolate sensitive properties into separate files so that we can in the future improve the protection of them without complicating access to non-sensitive fields. In addition, the recommendation in the "password storage" best practice: http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp is that passwords and similar sensitive values be encrypted when stored in the filesystem. - Bill From sacadmin Thu Mar 22 13:12:16 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MKCGVJ014538 for ; Thu, 22 Mar 2007 13:12:16 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MKCGNM019359; Thu, 22 Mar 2007 13:12:16 -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 l2MLCGnE026580; Thu, 22 Mar 2007 13:12:16 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2MLCGF6026579; Thu, 22 Mar 2007 13:12:16 -0800 (PST) Date: Thu, 22 Mar 2007 13:12:16 -0800 (PST) From: Gary Winiger Message-Id: <200703222112.l2MLCGF6026579@marduk.eng.sun.com> To: mws@zion.eng.sun.com, sommerfeld@sun.com Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage Cc: psarc@sac.sfbay.sun.com, mws@sun.com, keith.wesolowski@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1826 > I'm not comfortable with mixing sensitive properties into the main > property database - in the past, my advice to other projects (including > the wifi folks) has always been to isolate sensitive properties into > separate files so that we can in the future improve the protection of > them without complicating access to non-sensitive fields. > > In addition, the recommendation in the "password storage" best practice: > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > is that passwords and similar sensitive values be encrypted when stored > in the filesystem. I've not read the actual submission, however I took part in the os.o prediscussion. The repository database is rw to root only. I'm not sure I see a distinction, nor added value in factoring the database. lrwxrwxrwx 1 root root 31 Mar 9 11:55 /etc/svc/repository-boot -> repository-boot-20070309_115513 -rw------- 1 root root 3205120 Feb 2 15:32 /etc/svc/repository-boot-20070202_153233 -rw------- 1 root root 3231744 Feb 25 15:46 /etc/svc/repository-boot-20070225_154638 -rw------- 1 root root 3234816 Feb 25 16:00 /etc/svc/repository-boot-20070225_160030 -rw------- 1 root root 3234816 Mar 9 11:55 /etc/svc/repository-boot-20070309_115513 -rw------- 1 root sys 3373056 Mar 12 13:27 /etc/svc/repository.db lrwxrwxrwx 1 root root 42 Mar 9 11:55 /etc/svc/repository-manifest_import -> repository-manifest_import-20070309_115553 -rw------- 1 root root 3121152 Jan 18 13:55 /etc/svc/repository-manifest_import-20070118_135545 -rw------- 1 root root 3234816 Feb 25 15:46 /etc/svc/repository-manifest_import-20070225_154650 -rw------- 1 root root 3363840 Mar 9 11:55 /etc/svc/repository-manifest_import-20070309_115553 Gary.. From sacadmin Thu Mar 22 13:26:46 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MKQjPB014878 for ; Thu, 22 Mar 2007 13:26:45 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MKQjcI005539; Thu, 22 Mar 2007 13:26:45 -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 l2MLQjtO026647; Thu, 22 Mar 2007 13:26:45 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2MLQjrj026646; Thu, 22 Mar 2007 13:26:45 -0800 (PST) Date: Thu, 22 Mar 2007 13:26:45 -0800 (PST) From: Gary Winiger Message-Id: <200703222126.l2MLQjrj026646@marduk.eng.sun.com> To: mws@zion.eng.sun.com, sommerfeld@sun.com, gww@eng.sun.com Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage Cc: psarc@sac.sfbay.sun.com, mws@sun.com, keith.wesolowski@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 256 > Cc: psarc@sac.sfbay.sun.com, mws@sun.com, keith.wesolowski@sun.com ^^^^^^^^^^^^^^^^^^^^^^^ Missed noting this is a closed case. Since it was prediscussed on os.o, I'd think it should be open and smf-discuss would be an appropriate cc. Gary.. From sacadmin Thu Mar 22 13:27:46 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MKRk48014890 for ; Thu, 22 Mar 2007 13:27:46 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MKRkQt595002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 13:27:46 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2MKRkfH595001; Thu, 22 Mar 2007 13:27:46 -0700 (PDT) Date: Thu, 22 Mar 2007 13:27:46 -0700 From: Keith M Wesolowski To: Gary Winiger Cc: mws@zion.eng.sun.com, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, mws@sun.com Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage Message-ID: <20070322202745.GC560447@sun.com> References: <200703222126.l2MLQjrj026646@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703222126.l2MLQjrj026646@marduk.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 503 On Thu, Mar 22, 2007 at 01:26:45PM -0800, Gary Winiger wrote: > > Cc: psarc@sac.sfbay.sun.com, mws@sun.com, keith.wesolowski@sun.com > ^^^^^^^^^^^^^^^^^^^^^^^ > > Missed noting this is a closed case. Since it was prediscussed > on os.o, I'd think it should be open and smf-discuss would be > an appropriate cc. Yes to both. If you have the ability to open the case, please do so. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From sacadmin Thu Mar 22 13:31:07 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MKV7Xm015056 for ; Thu, 22 Mar 2007 13:31:07 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MKV6xD008883; Thu, 22 Mar 2007 13:31:06 -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 l2MLV639026676; Thu, 22 Mar 2007 13:31:06 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2MLV6gn026675; Thu, 22 Mar 2007 13:31:06 -0800 (PST) Date: Thu, 22 Mar 2007 13:31:06 -0800 (PST) From: Gary Winiger Message-Id: <200703222131.l2MLV6gn026675@marduk.eng.sun.com> To: gww@eng.sun.com, keith.wesolowski@sun.com Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage Cc: mws@zion.eng.sun.com, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, mws@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 245 > Yes to both. If you have the ability to open the case, please do so. I'll let the case owner start the email over. Mike, if you don't know, change the IAM Exposure to open and mail to psarc-ext@sun.com rather than psarc@sac.eng. Gary.. From sacadmin Thu Mar 22 14:04:28 2007 Received: from absurd.sfbay.sun.com (absurd.SFBay.Sun.COM [129.146.228.172]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2ML4Sdf016938 for ; Thu, 22 Mar 2007 14:04:28 -0700 (PDT) Received: from absurd (localhost [127.0.0.1]) by absurd.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2ML4Son026352; Thu, 22 Mar 2007 14:04:28 -0700 (PDT) Message-Id: <200703222104.l2ML4Son026352@absurd.sfbay.sun.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gary Winiger cc: mws@zion.eng.sun.com, sommerfeld@sun.com, psarc@sac.sfbay.sun.com, mws@sun.com, keith.wesolowski@sun.com Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-Reply-To: <200703222112.l2MLCGF6026579@marduk.eng.sun.com> From: Liane Praza Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Mar 2007 14:04:28 -0700 Sender: lianep@absurd.sfbay.sun.com Status: RO Content-Length: 1454 Gary Winiger writes: > > I'm not comfortable with mixing sensitive properties into the main > > property database - in the past, my advice to other projects (including > > the wifi folks) has always been to isolate sensitive properties into > > separate files so that we can in the future improve the protection of > > them without complicating access to non-sensitive fields. > > > > In addition, the recommendation in the "password storage" best practice: > > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > > is that passwords and similar sensitive values be encrypted when stored > > in the filesystem. > > I've not read the actual submission, however I took part in the > os.o prediscussion. The repository database is rw to root only. > I'm not sure I see a distinction, nor added value in factoring > the database. I agree with Gary, and also want to note that the format and file structure of the repository is currently private. If some future improvement of protection for sensitive fields appears, we're free to split those fields into a different file to take advantage of that improvement. No public interface change would be required to make that split, so it seems sensible to defer that implementation choice until we've got a compelling reason to add a third repository file for configd to keep track of. liane -- Liane Praza, Solaris Kernel Development liane.praza@sun.com - http://blogs.sun.com/lianep From mws@zion.eng.sun.com Thu Mar 22 14:24:19 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MLOJqh018201 for ; Thu, 22 Mar 2007 14:24:19 -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 l2MLOHWl008106; Thu, 22 Mar 2007 15:24:18 -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 <0JFB00B0FQ4HEY00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 14:24:17 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFB00B3IQ4GD000@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 14:24:16 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2MLOFMe028172; Thu, 22 Mar 2007 14:24:15 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2MLOFEF011281; Thu, 22 Mar 2007 14:24:15 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l2MLOF0x011280; Thu, 22 Mar 2007 14:24:15 -0700 (PDT) Date: Thu, 22 Mar 2007 14:24:15 -0700 (PDT) From: Michael Shapiro Subject: PSARC 2007/177 SMF Sensitive Property Storage To: psarc-ext@sun.com Cc: mws@sun.com, keith.wesolowski@sun.com Message-id: <200703222124.l2MLOF0x011280@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 10968 (re-sending to the open alias) I'm sponsoring the following fast track for Keith Wesolowski. The case seeks binding for a Micro/Patch release (i.e. a Solaris Update). The timer is set for March 30. The case spec is below and a copy is in the inception.materials/ directory. Also found in the materials directory are diffs to all relevant SMF man pages. -Mike --8<-- smf(5) enhancements for storage of sensitive properties Keith M Wesolowski 14 March 2007 ident "@(#)smf-case 1.6 07/03/21 SMI" 1. Description This case describes a set of modifications to svc.configd(1M) and related administrative tools to support storage of, and restriction of access to, sensitive application properties such as passwords. This case seeks Micro/Patch Release binding. 2. Discussion 2.1. The read_authorization property Currently, creation, modification, and deletion of property groups and properties is permitted only to client processes with the full set of effective privileges. In addition, processes with certain RBAC authorizations are permitted to change repository contents under certain circumstances. Finally, smf permits the addition of arbitrary authorizations to perform these actions on a per-property group basis[0]. All properties in all property groups may be read by any process. This case introduces read_authorization as an analogue to the existing value_authorization and modify_authorization properties. 2.1.1. Definition The read_authorization property may optionally be added to any property group of type application (SCF_GROUP_APPLICATION). It is defined to be a string-valued property with zero or more values. Each string value (if any) of this property will be interpreted as the name of an rbac(5) authorization defined in auth_attr(4). A read_authorization property which is not string-valued will not be interpreted specially. Property groups of types framework, method, and dependency describe the state and configuration of the service or instance with respect to SMF itself. Because properties in these groups have specific well-defined effects on the behaviour of SMF, any mechanism which may render any combination of these properties invisible may have complex side effects. Because the schemas of these groups are already well-defined and none of the data they contain is sensitive, there is no reason to address the complex failure semantics associated with read access controls on these group types. Therefore, this case reserves, but does not define, the behaviour of the 'read_authorization' property with respect to these group types. Future enhancements such as templates[1] are expected to permit finer-grained control over the meaning of this and similar properties within a particular group. 2.1.2. svc.configd(1M) RPC changes Property create, modify, and delete semantics are not modified by this case, nor are create and delete semantics of property groups. Read semantics are unchanged with respect to properties in property groups which do not contain a string-valued read_authorization property. Those property groups which do contain this property, even if it has no values, are referred to herein as sensitive property groups (SPGs). The behaviour observed by clients attempting to obtain the value(s) of a property in a SPG will be as follows: - If the requesting client would be permitted to modify the property, it will be permitted to read the value(s); otherwise, - If the requesting client has one or more of the authorizations named by the 'read_authorization' property in the same SPG, it will be permitted to read the value(s); otherwise, - The requesting client will not be permitted to read the value(s) and will receive the REP_PROTOCOL_FAIL_PERMISSION_DENIED error code. While the client cannot distinguish between failure due to locally-enforced policy and backend-enforced policy (in the networked repository case), this shortcoming also exists with respect to the existing add/modify/delete policies. This case does not attempt to address this deficiency. 2.2. libscf(3LIB) changes libscf(3LIB), as originally defined[2] and updated[3] already provides an appropriate error code for use by clients when the contacted svc.configd(1M) denies permission to perform the requested operation. This case extends the use of that error code to the cases listed in 2.1.2 above. The following functions will fail and set the libscf(3LIB) error value for the calling thread to SCF_ERROR_PERMISSION_DENIED if the contacted svc.configd(1M) returns an error code of REP_PROTOCOL_FAIL_PERMISSION_DENIED in response: scf_property_get_value scf_iter_next_value 2.3. svcprop(1) changes With respect to SPGs, svcprop(1)'s behaviour is modified as follows: - If a property or property group was explicitly specified with -p, and svc.configd(1M) denies access to the values of the specified property/ies, svcprop(1) will abort and, unless the '-q' option was provided, display an error message. - If no property or property group was specified, properties for which the user lacks appropriate authorization to read will be displayed as if they had zero values (the present behaviour is to display the empty string for the value of such properties). 2.4. svccfg(1M) changes 2.4.1. export changes, introduction of export -a 'svccfg export' is modified to export the values of properties in SPGs as if they had no values, regardless of whether the user performing the operation has the required authorization. This prevents accidental exposure of sensitive data in XML documents used for interchange purposes. To provide the ability to export documents containing the values of sensitive properties, we introduce the '-a' option to the export subcommand. With this option, 'export' will export all properties in SPGs if the user has sufficient authorization to read them. Otherwise, upon encountering a property which cannot be read due to access controls, the command terminates and displays an appropriate error message. 2.4.2. archive changes The purpose of the 'archive' subcommand is to dump the entire repository in a format "suitable for a relocatable repository backup"[4]. In the presence of SPGs, this effectively requires that the user executing the command have sufficient authorization to read all values of all properties, else the archive will be incomplete. Accordingly, this subcommand will fail and display an error message if a property value cannot be read. 2.5. auditing An AUE_smf_read_prop audit record will be generated when an attempt is made to read properties in SPGs. This record will contain the FMRI of the property being read and the status (success or failure) of the attempt to read it, as well as the authorization used (if successful) or the most specific authorization that would have been required (if unsuccessful) to read the value. 3. Manual page changes Diffs to relevant manual pages are included in the case materials. Modified man pages are: svcprop(1) svccfg(1M) scf_property_create(3SCF) scf_iter_create(3SCF) smf_security(5) 4. SMF policy changes This section details changes required to the 'Service Management Facility (SMF) usage' policy[5]. 4.1. Guidance The third bulleted item in 'Guidance for Delivery of SMF Services' currently reads: # Services must provide service related RBAC authorizations, as # appropriate, by providing service specific values for the # action_authorization, modify_authorization and # value_authorization of property groups. See smf_security(5). # These authorizations must follow the form of # "solaris.smf.{manage, modify, value}." respectively. These # authorizations must be delivered into an appropriate Rights # profile, either new or existing. This guidance shall be altered to read: # Services must provide service related RBAC authorizations, as # appropriate, by providing service specific values for the | action_authorization, modify_authorization, | value_authorization, and read_authorization of property | groups. See smf_security(5). These authorizations must follow | the form of | "solaris.smf.{manage, modify, value, read}.," # respectively. These authorizations must be delivered into an # appropriate Rights profile, either new or existing. 4.2. Appendix B Appendix B currently reads: # It should be noted that configuration data residing in the SCF # repository is world-readable. Projects with configuration data # that is deemed sensitive in nature or that should remain # private from a security standpoint must consult with the ARC # to determine if the Service Configuration Facility is the # appropriate repository for their data. With the implementation of the changes specified above, this guidance is no longer correct. It shall be amended to read as follows: # It should be noted that configuration data residing in the SCF | repository is world-readable by default. Projects with | configuration data that is deemed sensitive in nature or that | should remain private from a security standpoint must consult | with the ARC to determine if the Service Configuration | Facility is the appropriate repository for their data. If so, | the property group(s) intended to contain sensitive data must | be defined in manifests with an appropriate read_authorization | property (see smf_security(5)), and no sensitive information | may be delivered in the manifest itself. 5. Interface table 5.1. Interfaces Exported Well-known property 'read_authorization' Committed No case explicitly defines the commitment level of the well-known properties 'modify_authorization' and 'value_authorization'[6]. Given their semantics, their presence in smf_security(5), and the clear intent that they be introduced as Evolving, this case also clarifies them as follows: Well-known property 'modify_authorization' Committed Well-known property 'value_authorization' Committed The intent of this case is that 'read_authorization' be a peer of these existing well-known properties and therefore have the same commitment level. 5.2. Interfaces Imported None. 6. References [0] PSARC/2002/547 Greenline; see C.35, smf_security(5) [1] http://www.opensolaris.org/os/project/vpanels/templates/ [2] PSARC/2002/547 Greenline; see C.10, scf_error(3SCF) [3] PSARC/2004/525 libscf(3LIB) updates [4] Ibid.; see C.6, svccfg(1M) [5] http://www.opensolaris.org/os/community/arc/policies/SMF-policy/ [6] PSARC/2002/547 Greenline; see App. D -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From Keith.Wesolowski@sun.com Thu Mar 22 15:04:28 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2MM4SbM019787 for ; Thu, 22 Mar 2007 15:04:28 -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 l2MM4SjA015607; Thu, 22 Mar 2007 15:04:28 -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 <0JFB00D0HRZF7W00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 15:04:27 -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 <0JFB00BG3RZDD220@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Mar 2007 15:04:25 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2MM4PDi608344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 15:04:25 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2MM4PdR608317; Thu, 22 Mar 2007 15:04:25 -0700 (PDT) Date: Thu, 22 Mar 2007 15:04:16 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1174589836.27921.28.camel@thunk> To: Bill Sommerfeld Cc: Michael Shapiro , psarc-ext@sun.com Message-id: <20070322220416.GB596353@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: <200703221809.l2MI9n8a015947@zion.eng.sun.com> <1174589836.27921.28.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2721 On Thu, Mar 22, 2007 at 02:57:15PM -0400, Bill Sommerfeld wrote: > I'm not comfortable with mixing sensitive properties into the main > property database - in the past, my advice to other projects (including > the wifi folks) has always been to isolate sensitive properties into > separate files so that we can in the future improve the protection of > them without complicating access to non-sensitive fields. > > In addition, the recommendation in the "password storage" best practice: > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > is that passwords and similar sensitive values be encrypted when stored > in the filesystem. This case does not propose a change to that policy. If the ARC feels that the repository (which as Gary pointed out is readable only by root and stored in a non-shared filesystem, as specified by the policy) does not provide "sufficient protection" as defined by the policy with respect to a particular project, it is free to require that project team to take alternate measures. Nevertheless, storing encrypted or, especially, obfuscated passwords in the repository is advantageous because it allows optional assignment of fine-grained authorizations. It also makes possible adherence to the SMF Policy[0], specifically the requirement that "[p]rojects intending to integrate new system or service configuration files (which traditionally reside within the /etc/* directory hierarchy) into Solaris must use the Service Configuration Facility (SCF), libscf(3LIB), as their repository for system configuration..." by reducing the set of circumstances in which security considerations would preclude a project team from doing so. As an example, PSARC/2000/363 (Native LDAP Phase II) places an obfuscated password in /var/ldap/ldap_client_cred. Converting this service to use the SMF repository demands the capability proposed by this case; to quote from that case's materials[1]: # All credential information stored in this file is encrypted using # a simple two way encryption mechanism. The security of the # credential is not the encryption, but rather the file permission. The functionality proposed here permits such a credential to be stored securely in the SMF repository, by default readable only by root, and at the same time would allow greater administrative flexibility in accessing or modifying this value, reducing the number of potential administrative tasks requiring full privileges. [0] http://www.opensolaris.org/os/community/arc/policies/SMF-policy/ [1] PSARC/2000/363 Native LDAP Phase II, Architecture Specification sec. 8.2. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From gww@eng.sun.com Tue Mar 27 15:29:45 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2RMTid6003894 for ; Tue, 27 Mar 2007 15:29:44 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2RMTYfK023944; Tue, 27 Mar 2007 23:29:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFL002012HGYW00@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 15:29:40 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL0009M2HFDP30@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Mar 2007 15:29:39 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2RMTdio009279; Tue, 27 Mar 2007 15:29:39 -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 l2RNT0Jc004542; Tue, 27 Mar 2007 15:29:00 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2RNT0mt004541; Tue, 27 Mar 2007 15:29:00 -0800 (PST) Date: Tue, 27 Mar 2007 15:29:00 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage To: mws@zion.eng.sun.com, psarc-ext@sun.com Cc: keith.wesolowski@sun.com, mws@sun.com Message-id: <200703272329.l2RNT0mt004541@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2514 > 2.1.1. Definition > > The read_authorization property may optionally be added to any > property group of type application (SCF_GROUP_APPLICATION). It is > defined to be a string-valued property with zero or more values. Each > string value (if any) of this property will be interpreted as the name > of an rbac(5) authorization defined in auth_attr(4). A > read_authorization property which is not string-valued will not be > interpreted specially. I don't understand this last sentence. I thought that the read_authorization property was similar to method, modify, and value_authorizations in that its type was string. > 2.3. svcprop(1) changes > > With respect to SPGs, svcprop(1)'s behaviour is modified as follows: > > - If a property or property group was explicitly specified with -p, > and svc.configd(1M) denies access to the values of the specified > property/ies, svcprop(1) will abort and, unless the '-q' option was > provided, display an error message. What does abort mean in this context? Does it call abort(3C), or does it return an error? > - If no property or property group was specified, properties for > which the user lacks appropriate authorization to read will be > displayed as if they had zero values (the present behaviour is to > display the empty string for the value of such properties). I don't understand this last sentence. Is the present behavior being modified? Would string valued properties have "0" returned? Would string valued properties have an empty string returned? > smf_security(5) > value_authorization Authorizations allow changing the > values of any property of the property > - group except modify_authorization. > + group except modify_authorization, and > + the retrieval of any property values > + except modify_authorization from the > + property group if sensitive. Does this case modify the action of value_authorization with respect to modify_authorization? I'm not sure what it is saying. I can read it as saying the value_authorization doesn't allow the retrieval of the value of a modify_authorization that is present in a sensitive property group. I'm not sure that makes sense. The way I've read this proposal, if I can change the sensitive property value, I can read it. Please clarify. Gary.. From Keith.Wesolowski@sun.com Tue Mar 27 17:05:21 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S05KlV006554 for ; Tue, 27 Mar 2007 17:05:21 -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 l2S05G6j000280; Wed, 28 Mar 2007 08:05:17 +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 <0JFL002056WSD200@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 18:05:16 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL00NS46WO13C0@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 18:05:12 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S05CwG173623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2007 17:05:12 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2S05CrC173622; Tue, 27 Mar 2007 17:05:12 -0700 (PDT) Date: Tue, 27 Mar 2007 17:05:12 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200703272329.l2RNT0mt004541@marduk.eng.sun.com> To: Gary Winiger Cc: mws@zion.eng.sun.com, psarc-ext@sun.com, mws@sun.com Message-id: <20070328000511.GD101312@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: <200703272329.l2RNT0mt004541@marduk.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 4800 On Tue, Mar 27, 2007 at 03:29:00PM -0800, Gary Winiger wrote: > > 2.1.1. Definition > > > > The read_authorization property may optionally be added to any > > property group of type application (SCF_GROUP_APPLICATION). It is > > defined to be a string-valued property with zero or more values. Each > > string value (if any) of this property will be interpreted as the name > > of an rbac(5) authorization defined in auth_attr(4). A > > read_authorization property which is not string-valued will not be > > interpreted specially. > > I don't understand this last sentence. I thought that the > read_authorization property was similar to method, modify, and > value_authorizations in that its type was string. It is. Feedback indicated that the original expression was unclear, that it could have been read to mean we would prevent the creation of non-string-valued properties with these names. That is not how the existing properties work, nor is it how we intend read_authorization to work. To clarify this, we require that the property be string-valued in order to be subject to the interpretation we define. It is permitted, but not meaningful with respect to this case, to create read_authorization properties with non-string types. As clear as I can make it: The semantics of read_authorization with respect to property type are identical to those of the existing well-known properties. > > 2.3. svcprop(1) changes > > > > With respect to SPGs, svcprop(1)'s behaviour is modified as follows: > > > > - If a property or property group was explicitly specified with -p, > > and svc.configd(1M) denies access to the values of the specified > > property/ies, svcprop(1) will abort and, unless the '-q' option was > > provided, display an error message. > > What does abort mean in this context? Does it call abort(3C), > or does it return an error? It returns an error. > > - If no property or property group was specified, properties for > > which the user lacks appropriate authorization to read will be > > displayed as if they had zero values (the present behaviour is to > > display the empty string for the value of such properties). > > I don't understand this last sentence. Is the present behavior > being modified? Would string valued properties have "0" returned? > Would string valued properties have an empty string returned? Neither. The existing implementation has well-defined behaviour in the face of properties with zero values (that is, the cardinality of the set of values for the property is 0): it prints nothing - not "", not '', not 0, but nothing at all: the zero-length string. This case defines the behaviour in the face of insufficient permission to be identical unless -p is specified. No existing behaviour is being modified with respect to zero-valued properties, nor with respect to non-sensitive property groups. This demonstrates the existing behaviour of svcprop(1) on zero-valued properties. root@fallout:~ # cat /tmp/testprop #! /bin/sh die() { echo $1 >&2 exit 1 } svccfg < > smf_security(5) > > > value_authorization Authorizations allow changing the > > values of any property of the property > > - group except modify_authorization. > > + group except modify_authorization, and > > + the retrieval of any property values > > + except modify_authorization from the > > + property group if sensitive. > > Does this case modify the action of value_authorization with > respect to modify_authorization? I'm not sure what it is > saying. I can read it as saying the value_authorization > doesn't allow the retrieval of the value of a modify_authorization > that is present in a sensitive property group. I'm not sure > that makes sense. > > The way I've read this proposal, if I can change the sensitive > property value, I can read it. Please clarify. Correct - if you can change it, you can read it. Having an authorization named by value_authorization is not sufficient to change the values of modify_authorization; therefore, for sensitive property groups, neither is it sufficient to read those values. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From Keith.Wesolowski@sun.com Tue Mar 27 18:11:45 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S1BjqQ007886 for ; Tue, 27 Mar 2007 18:11:45 -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 l2S1Bj3E006148; Tue, 27 Mar 2007 18:11:45 -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 <0JFL008039ZKZR00@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 19:11:44 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL00N129ZK11D0@brm-avmta-1.central.sun.com>; Tue, 27 Mar 2007 19:11:44 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2S1BhkW180911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2007 18:11:43 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2S1BhQ1180905; Tue, 27 Mar 2007 18:11:43 -0700 (PDT) Date: Tue, 27 Mar 2007 18:11:29 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200703222124.l2MLOF0x011280@zion.eng.sun.com> To: psarc-ext@sun.com Cc: mws@sun.com Message-id: <20070328011129.GE101312@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_f8hRg8h0P3gvmbevyomn2w)" Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200703222124.l2MLOF0x011280@zion.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 29884 --Boundary_(ID_f8hRg8h0P3gvmbevyomn2w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline On Thu, Mar 22, 2007 at 02:24:15PM -0700, Michael Shapiro wrote: > 2.4.1. export changes, introduction of export -a > > 'svccfg export' is modified to export the values of properties in > SPGs as if they had no values, regardless of whether the user performing > the operation has the required authorization. This prevents accidental > exposure of sensitive data in XML documents used for interchange > purposes. > > To provide the ability to export documents containing the values of > sensitive properties, we introduce the '-a' option to the export > subcommand. With this option, 'export' will export all properties in > SPGs if the user has sufficient authorization to read them. Otherwise, > upon encountering a property which cannot be read due to access > controls, the command terminates and displays an appropriate error > message. It's been brought to my attention that the man page diffs for svccfg(1M) that describe this functionality are incorrect in the case materials. The only error is that the functionality described here under export -a was incorrectly defined under a new exportall command. The above description is the correct one and is unchanged, as is the behaviour itself. I've attached the corrected svccfg.1m and diffs. The rest of the materials are correct. The diffs should read as follows: --- svccfg.1m.orig Thu Mar 15 11:28:46 2007 +++ svccfg.1m Tue Mar 27 17:53:09 2007 @@ -183,6 +183,15 @@ properties such as service state, and is suitable for a relocatable repository backup. + If one or more property groups + contains sensitive information + (identified by the presence of + the read_authorization property + - see smf_security(5)), and + insufficient privileges exist + to read the values of the + persistent properties in those + groups, an error results. @@ -211,7 +220,8 @@ - export service_FMRI [>file] The service description for the | + export [-a] service_FMRI [>file] | + The service description for the specified service and its instances is written to stan- dard output or redirected to @@ -220,7 +230,17 @@ perty set to true are omitted in the belief that they were created on behalf of another - service. | + service. Without the -a option, | + property groups containing | + sensitive information | + (identified by the presence of | + the read_authorization property | + - see smf_security(5)) will be | + exported without their property | + values. When the -a option is | + given, an error results if | + there are insufficient | + privileges to read these values. | Apologies for the error. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" --Boundary_(ID_f8hRg8h0P3gvmbevyomn2w) Content-type: text/plain; NAME=svccfg.1m; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=svccfg.1m System Administration Commands svccfg(1M) NAME svccfg - import, export, and modify service configurations SYNOPSIS /usr/sbin/svccfg [-v] [-s FMRI] /usr/sbin/svccfg [-v] [-s FMRI] subcommand [args]... /usr/sbin/svccfg [-v] [-s FMRI] -f command-file DESCRIPTION The svccfg command manipulates data in the service confi- guration repository. svccfg can be invoked interactively, with an individual subcommand, or by specifying a command file that contains a series of subcommands. Changes made to an existing service in the repository typi- cally do not take effect for that service until the next time the service instance is refreshed. See the refresh sub- command on the svcadm(1M) man page for more details. OPTIONS The following options are supported: -f command-file Reads and executes svccfg subcommands from command-file. -s FMRI Selects the entity indicated by FMRI (a fault management resource identifier) before executing any subcommands. -v Verbose. SUBCOMMANDS The following subcommands are supported: SunOS 5.11 Last change: 8 Apr 2005 1 System Administration Commands svccfg(1M) end Exits immediately. exit quit set [-v|-V] Sets optional behavior. If no options are specified, set displays the options currently in effect. -v Turns on verbose mode. -V Turns off verbose mode. repository repfile Uses repfile as a private repository. By default, svccfg(1M) uses the system repository. Service profile subcommands apply file If file is a service profile, then service instances specified within the file are enabled or disabled according to it. See smf(5) for a description of service pro- files. This command requires privileges to modify the "general/enabled" property of the service instances. See smf_security(5) for the privileges required to modify pro- perties. If file is not a service profile, the subcommand fails. extract [> file] Prints a service profile which represents the enabled status of the service instances in the repository to standard output. The output may be redirected to a file. SunOS 5.11 Last change: 8 Apr 2005 2 System Administration Commands svccfg(1M) Service manifest subcommands import file If file is a service manifest, then the services and instances it specifies are imported into the repository. According to the file, dependencies may be created in other services. See smf(5) for a description of service manifests. See smf_security(5) for the privileges required to create and modify service configura- tions. For existing services and instances, properties which have not changed since the last import snapshot was taken are upgraded to those specified by the manifest. Conflicts (pro- perties which have been changed both in the repository and the manifest) are reported on the standard error stream. svccfg will never upgrade the "general/enabled" and "general/restarter" properties, since they represent adminis- trator preference. archive Dumps a full XML service description for all services, instances, and their persistent properties in the repository. This does not include transient properties such as service state, and is suitable for a relocatable repository backup. If one or more property groups contains sensitive information (identified by the presence of the read_authorization property - see smf_security(5)), and insufficient privileges exist to read the values of the persistent properties in those groups, an error results. validate file file is processed similarly to import, but no changes are made SunOS 5.11 Last change: 8 Apr 2005 3 System Administration Commands svccfg(1M) to the repository. If any errors are detected, svccfg(1M) exits with a nonzero exit status. export [-a] service_FMRI [>file] The service description for the specified service and its instances is written to stan- dard output or redirected to the given file. Dependencies with a boolean "external" pro- perty set to true are omitted in the belief that they were created on behalf of another service. Without the -a option, property groups containing sensitive information (identified by the presence of the read_authorization property - see smf_security(5)) will be exported without their property values. When the -a option is given, an error results if there are insufficient privileges to read these values. inventory file If file is determined to be a service manifest, then the FMRIs of the services and instances the file describes are printed. For each service, the FMRIs of its instances are displayed before the FMRI of the service. Entity selection, modification, and navigation subcommands An "entity" refers to a scope, service, or service instance. select {name | fmri} If the argument names a child of the current selection, it becomes the current selection. Otherwise, the argument is interpreted as an FMRI and the entity that the argument specifies becomes the current selection. SunOS 5.11 Last change: 8 Apr 2005 4 System Administration Commands svccfg(1M) unselect The parent of the current selec- tion becomes the current selec- tion. list [pattern] The child entities of the current selection whose names match the glob pattern pattern are displayed (see fnmatch(5)). ':properties' is also listed for property-bearing entities, namely services and service instances. add name A new entity with the given name is created as a child of the current selection. See smf_security(5) for the privileges required to create entities. delete [-f] {name | fmri} The named child of the current selection or the entity specified by fmri is deleted. Attempts to delete service instances in the "online" or "degraded" state will fail unless the -f flag is speci- fied. If a service or service instance has a "dependents" pro- perty group of type "framework", then for each of its properties with type "astring" or "fmri", if the property has a single value which names a service or service instance then the dependency pro- perty group in the indicated ser- vice or service instance with the same name as the property will be deleted. See smf_security(5) for the privileges required to delete service configurations. SunOS 5.11 Last change: 8 Apr 2005 5 System Administration Commands svccfg(1M) Property inspection and modification subcommands listpg [pattern] Displays the names, types, and flags of property groups of the current selection. If an argument is given, it is taken as a glob pattern and only property groups with names which match the argument are listed. addpg name type [flags] Adds a property group with the given name and type to the current selection. flags is a string of characters which designates the flags with which to create the pro- perty group. 'P' represents SCF_PG_FLAG_NONPERSISTENT (see scf_service_add_pg(3SCF)). See smf_security(5) for the privileges required to create property groups. delpg name Deletes the property group name of the current selec- tion. See smf_security(5) for the privileges required to delete property groups. listprop [pattern] Lists property groups and properties of the current selection. For property groups, names, types, and flags are listed. For properties, names (prepended by the pro- perty group name and a slash (/)), types, and values are listed. See scf_value_create(3SCF) for a list of avail- able property types. If an argument is supplied it is taken as a glob pattern and only property groups and properties with names which match the argument are listed. SunOS 5.11 Last change: 8 Apr 2005 6 System Administration Commands svccfg(1M) setprop pg/name = [type:] value setprop pg/name = [type:] ([values ...]) Sets the name property of the pg property group of the current selection to the given values of type type. See scf_value_create(3SCF) for a list of available property types. If the property already exists and the type disagrees with the existing type on the property, the subcommand fails. Values may be enclosed in double- quotes. String values which contain double-quotes or backslashes must be enclosed by double-quotes and the contained double-quotes and backslashes must be quoted by backslashes. If the named property does not exist, it is created, as long as the type is specified. See smf_security(5) for the privileges required to create or modify properties. delprop pg[/name] Deletes the named property group or property of the current selection. See smf_security(5) for the privileges required to delete properties. editprop Comments of commands to reproduce the property groups and properties of the current selection are placed in a temporary file and the program named by the EDITOR environment variable is invoked to edit it. Upon comple- tion, the commands in the temporary file are executed. The default editor is vi(1). See smf_security(5) for the privileges required to create, modify, or delete proper- ties. addpropvalue pg/name [type:] value Adds the given value to a property. If type is given and the property exists, then if type does not agree with the property's type, the subcommand fails. The values SunOS 5.11 Last change: 8 Apr 2005 7 System Administration Commands svccfg(1M) may be enclosed in double-quotes. String values contain- ing double-quotes or backslashes must be enclosed by double-quotes and the contained double-quotes and backslashes must be quoted by backslashes. Nonexistent properties are created, in which case the type specifier must be present. See scf_value_create(3SCF) for a list of available property types. See smf_security(5) for the privileges required to modify properties. delpropvalue pg/name globpattern Deletes all values matching the given glob pattern in the named property. Succeeds even if no values match. See smf_security(5) for the privileges required to modify properties. setenv [-i | -s] [-m method_name] envvar value Sets a method environment variable for a service or instance by changing the "environment" property in the method_name property group, if that property group has type "method". If method_name is not specified and the -i option is used, the "method_context" property group is used, if an instance is currently selected. If the -s option is used and a service is currently selected, its "method_context" property group is used. If the -s option is used and an instance is currently selected, the "method_context" property group of its parent is used. If neither the -i option nor the -s option is used, the "start" property group is searched for in the currently selected entity and, if an instance is currently selected, its parent is also searched. If the "inetd_start" property group is not located, it is searched for in a similiar manner. Once the property is located, all values which begin with envvar followed by a "=" are removed, and the value "envvar=value" is added. See smf_security(5) for the privileges required to modify properties. SunOS 5.11 Last change: 8 Apr 2005 8 System Administration Commands svccfg(1M) unsetenv [-i | -s] [-m method_name] envvar value Removes a method environment variable for a service or instance by changing the "environment" property in the method_name property group, if that property group has type "method". If method_name is not specified and the -i option is used, the "method_context" property group is used, if an instance is currently selected. If the -s option is used and a service is currently selected, its "method_context" property group is used. If the -s option is used and an instance is currently selected, the "method_context" property group of its parent is used. If neither the -i option nor the -s option is used, the "start" property group is searched for in the currently selected entity and, if an instance is currently selected, its parent is also searched. If the "inetd_start" property group is not located, it is searched for in a similiar manner. Once the property is located, all values which begin with envvar followed by "=" are removed. See smf_security(5) for the privileges required to modify properties. Snapshot navigation and selection subcommands listsnap Displays snapshots available for the currently selected instance. selectsnap [name] Changes the current snapshot to the one named by name. If no name is specified, deselect the currently selected snapshot. Snapshots are read-only. revert [snapshot] Reverts the properties of the currently selected instance and its service to those recorded in the named snapshot. If no argument is given, use the currently SunOS 5.11 Last change: 8 Apr 2005 9 System Administration Commands svccfg(1M) selected snapshot and deselect it on suc- cess. The changed property values can be made active via the refresh subcommand of svcadm(1M). See smf_security(5) for the privileges required to change properties. All commands that accept FMRIs also accept abbreviated or globbed patterns. Instances and services can be abbreviated by specifying the instance name, or the trailing portion of the service name. For example, given the FMRI: svc:/network/smtp:sendmail All the following are valid abbreviations: sendmail :sendmail smtp smtp:sendmail network/smtp While the following are invalid: mail network network/smt Abbreviated forms of FMRIs are unstable, and should not be used in scripts or other permanent tools. If a pattern matches more than one instance or service, an error message is printed and no action is taken. EXAMPLES Example 1 Exporting a Service Description SunOS 5.11 Last change: 8 Apr 2005 10 System Administration Commands svccfg(1M) To export a service description on the local system: $ svccfg export dumpadm >/tmp/dump.xml Example 2 Deleting a Service Instance To delete a service instance: $ svccfg delete network/inetd-upgrade:default Example 3 Importing a Service Description To interactively import a service description into a private repository: $ svccfg svc:> repository /tmp/repository svc:> import /home/hjs/svc/box-factory.xml svc:> end Example 4 Modifying a Start Method To modify LD_PRELOAD for a start method and enable the use of libumem(3LIB) with debugging features active: $ svccfg -s system/service setenv LD_PRELOAD libumem.so $ svccfg -s system/service setenv UMEM_DEBUG default ENVIRONMENTAL VARIABLES EDITOR The command to run when the editprop subcommand is used. The default editor is vi(1). SunOS 5.11 Last change: 8 Apr 2005 11 System Administration Commands svccfg(1M) EXIT STATUS The following exit values are returned: 0 Successful execution. 1 One or more subcommands resulted in failure. Error mes- sages are written to the standard error stream. 2 Invalid command line options were specified. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | Interface Stability | See below. | |_____________________________|_____________________________| The interactive output is Unstable. The invocation and non- interactive output are Evolving. SEE ALSO svcprop(1), svcs(1), svcadm(1M), svc.configd(1M), libscf(3LIB), libumem(3LIB), scf_service_add_pg(3SCF), scf_value_create(3SCF), contract(4), attributes(5), fnmatch(5), smf(5), smf_method(5), smf_security(5) SunOS 5.11 Last change: 8 Apr 2005 12 --Boundary_(ID_f8hRg8h0P3gvmbevyomn2w) Content-type: text/plain; NAME=svccfg.1m.diff; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=svccfg.1m.diff --- svccfg.1m.orig Thu Mar 15 11:28:46 2007 +++ svccfg.1m Tue Mar 27 17:53:09 2007 @@ -183,6 +183,15 @@ properties such as service state, and is suitable for a relocatable repository backup. + If one or more property groups + contains sensitive information + (identified by the presence of + the read_authorization property + - see smf_security(5)), and + insufficient privileges exist + to read the values of the + persistent properties in those + groups, an error results. @@ -211,7 +220,8 @@ - export service_FMRI [>file] The service description for the + export [-a] service_FMRI [>file] + The service description for the specified service and its instances is written to stan- dard output or redirected to @@ -220,7 +230,17 @@ perty set to true are omitted in the belief that they were created on behalf of another - service. + service. Without the -a option, + property groups containing + sensitive information + (identified by the presence of + the read_authorization property + - see smf_security(5)) will be + exported without their property + values. When the -a option is + given, an error results if + there are insufficient + privileges to read these values. --Boundary_(ID_f8hRg8h0P3gvmbevyomn2w)-- From gww@eng.sun.com Tue Mar 27 23:29:40 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2S6Tdma013060 for ; Tue, 27 Mar 2007 23:29:39 -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 l2S6TOwT010111; Wed, 28 Mar 2007 14:29:36 +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 <0JFL00I03OP83G00@brm-avmta-1.central.sun.com>; Wed, 28 Mar 2007 00:29:32 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFL00FVKOP8KV00@brm-avmta-1.central.sun.com>; Wed, 28 Mar 2007 00:29:32 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2S6TVem006331; Tue, 27 Mar 2007 23:29:31 -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 l2S7SrWQ005596; Tue, 27 Mar 2007 23:28:53 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2S7Srbm005595; Tue, 27 Mar 2007 23:28:53 -0800 (PST) Date: Tue, 27 Mar 2007 23:28:53 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage To: gww@eng.sun.com, Keith.Wesolowski@sun.com Cc: mws@zion.eng.sun.com, psarc-ext@sun.com, mws@sun.com Message-id: <200703280728.l2S7Srbm005595@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1836 > > > value_authorization Authorizations allow changing the > > > values of any property of the property > > > - group except modify_authorization. > > > + group except modify_authorization, and > > > + the retrieval of any property values > > > + except modify_authorization from the > > > + property group if sensitive. > > > > Does this case modify the action of value_authorization with > > respect to modify_authorization? I'm not sure what it is > > saying. I can read it as saying the value_authorization > > doesn't allow the retrieval of the value of a modify_authorization > > that is present in a sensitive property group. I'm not sure > > that makes sense. > > > > The way I've read this proposal, if I can change the sensitive > > property value, I can read it. Please clarify. > > Correct - if you can change it, you can read it. Having an > authorization named by value_authorization is not sufficient to change > the values of modify_authorization; therefore, for sensitive property > groups, neither is it sufficient to read those values. Hummm, the reply doesn't make sense to me. Maybe I still don't understand it. Without authorization can't I read all property values today, including the ones I can't set? It seems to me that I should be able to read all the property values, including the ones I can't set that do not have a read_authorization associated with them. I don't see a reason to change this. If changed, it would seem to be an incompatible change. tundra.eng-gww[141]: svcprop network/ipv4-forwarding routeadm/default-ipv4-forwarding boolean false routeadm/value_authorization astring solaris.smf.value.routing Gary.. From Keith.Wesolowski@sun.com Wed Mar 28 07:55:39 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SEtdb0021815 for ; Wed, 28 Mar 2007 07:55:39 -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 l2SEtZtw016902; Wed, 28 Mar 2007 07:55:38 -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 <0JFM00K3BC4QOG00@brm-avmta-1.central.sun.com>; Wed, 28 Mar 2007 08:55:38 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFM007T1C4OM4A0@brm-avmta-1.central.sun.com>; Wed, 28 Mar 2007 08:55:36 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SEtaoH270243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2007 07:55:36 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2SEtaAN270242; Wed, 28 Mar 2007 07:55:36 -0700 (PDT) Date: Wed, 28 Mar 2007 07:55:36 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200703280728.l2S7Srbm005595@marduk.eng.sun.com> To: Gary Winiger Cc: mws@zion.eng.sun.com, psarc-ext@sun.com, mws@sun.com Message-id: <20070328145536.GB264988@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: <200703280728.l2S7Srbm005595@marduk.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 3044 On Tue, Mar 27, 2007 at 11:28:53PM -0800, Gary Winiger wrote: > Without authorization can't I read all property values today, > including the ones I can't set? Yes. > It seems to me that I should > be able to read all the property values, including the ones I > can't set that do not have a read_authorization associated with > them. You can. The behaviour of reading from property groups that don't have a string-valued read_authorization property is absolutely and completely unchanged by this case. I'm not sure how else to clarify this. Perhaps a table. +---------------------------+--------------+----------------+ | PG contains string-valued | Can read | Can read after | | read_authorization prop | values today | this case | +---------------------------+--------------+----------------+ | No | Always | Always | +---------------------------+--------------+----------------+ | Yes | Always | See 2.1.2 | +---------------------------+--------------+----------------+ In table form, the algorithm in 2.1.2 could be expressed as follows. X = Don't care. Auths: R = one or more of read_authorization's entries, V = one or more of value_authorization's entries, M = one or more of solaris.smf.modify or modify_authorization's entries. +---------------------------+------------+-------+----------+ | Property | All privs? | Auths | Can read | +---------------------------+------------+-------+----------+ | X | Yes | X | Yes | +---------------------------+------------+-------+----------+ | X | No | R | Yes | +---------------------------+------------+-------+----------+ | X | No | M | Yes | +---------------------------+------------+-------+----------+ | modify_authorization | No | V | No | +---------------------------+------------+-------+----------+ | ! modify_authorization | No | V | Yes | +---------------------------+------------+-------+----------+ This table reflects the simple rule for read access to SPGs: If you can change it, or you have one of $read_authorization, you can read it. Otherwise, you can't. > tundra.eng-gww[141]: svcprop network/ipv4-forwarding > routeadm/default-ipv4-forwarding boolean false > routeadm/value_authorization astring solaris.smf.value.routing Unless you or a subsequent manifest update add a string-valued read_authorization property to the routeadm property group, this behaviour is unchanged by this case. If such a property were to be added, having solaris.smf.value.routing would still be sufficient to read and change all properties in the group, except for (if it existed) the modify_authorization property. Again, with respect to changing values, that's the same behaviour we have today. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From sommerfeld@Sun.COM Wed Mar 28 08:29:42 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SFTgrU022486 for ; Wed, 28 Mar 2007 08:29:42 -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 l2SFTZxP011260; Wed, 28 Mar 2007 09:29:42 -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 <0JFM00807DPB3T00@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 08:29:35 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFM0068TDPBB750@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 08:29:35 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2SFTXPU016771; Wed, 28 Mar 2007 11:29:33 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SFTXV6025687; Wed, 28 Mar 2007 11:29:33 -0400 (EDT) Date: Wed, 28 Mar 2007 11:29:32 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070322220416.GB596353@sun.com> To: Keith M Wesolowski Cc: Michael Shapiro , psarc-ext@Sun.COM Message-id: <1175095772.25315.43.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703221809.l2MI9n8a015947@zion.eng.sun.com> <1174589836.27921.28.camel@thunk> <20070322220416.GB596353@sun.com> Status: RO Content-Length: 2489 On Thu, 2007-03-22 at 15:04 -0700, Keith M Wesolowski wrote: > On Thu, Mar 22, 2007 at 02:57:15PM -0400, Bill Sommerfeld wrote: > > > I'm not comfortable with mixing sensitive properties into the main > > property database - in the past, my advice to other projects (including > > the wifi folks) has always been to isolate sensitive properties into > > separate files so that we can in the future improve the protection of > > them without complicating access to non-sensitive fields. > > > > In addition, the recommendation in the "password storage" best practice: > > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > > is that passwords and similar sensitive values be encrypted when stored > > in the filesystem. FWIW, the password storage best practice is also published at: http://www.opensolaris.org/os/community/arc/bestpractices/passwords-files/ > This case does not propose a change to that policy. If the ARC feels > that the repository (which as Gary pointed out is readable only by > root and stored in a non-shared filesystem, as specified by the > policy) does not provide "sufficient protection" as defined by the > policy with respect to a particular project, it is free to require > that project team to take alternate measures. I believe that for reasons cited in the Best Practice that SMF should take additional measures to protect property values identified as sensitive and that those measures should receive open review. This is especially true since if this option is successful there may be large numbers of sensitive values stored in that file. > Nevertheless, storing encrypted or, especially, obfuscated passwords > in the repository is advantageous because it allows optional > assignment of fine-grained authorizations. ... > The functionality proposed here permits such a credential to be stored > securely in the SMF repository, by default readable only by root, and > at the same time would allow greater administrative flexibility in > accessing or modifying this value, reducing the number of potential > administrative tasks requiring full privileges. I'm a little confused about exactly who becomes responsible for encrypting the sensitive credential in this case -- is it SMF or is it the individual service? I'm uncomfortable with leaving this to the individual service (since it effectively forces each service to reinvent their own wheel), especially without very specific guidance in the SMF documentation. - Bill From Darren.Moffat@sun.com Wed Mar 28 08:34:26 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SFYQJt022545 for ; Wed, 28 Mar 2007 08:34:26 -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 l2SFYNnu012257; Wed, 28 Mar 2007 08:34:25 -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 <0JFM00813DXCA400@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 08:34:24 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFM0066CDXAB650@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 08:34:23 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2SFYMfL007427; Wed, 28 Mar 2007 15:34:22 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFM00401DX4YM00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 28 Mar 2007 16:34:22 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFM00EZ9DX9ZL10@d1-emea-09.sun.com>; Wed, 28 Mar 2007 16:34:22 +0100 (BST) Date: Wed, 28 Mar 2007 16:34:21 +0100 From: Darren J Moffat Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175095772.25315.43.camel@thunk> Sender: Darren.Moffat@sun.com To: Bill Sommerfeld Cc: Keith M Wesolowski , Michael Shapiro , psarc-ext@sun.com Message-id: <460A8AFD.9070507@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: <200703221809.l2MI9n8a015947@zion.eng.sun.com> <1174589836.27921.28.camel@thunk> <20070322220416.GB596353@sun.com> <1175095772.25315.43.camel@thunk> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 870 Bill Sommerfeld wrote: >> The functionality proposed here permits such a credential to be stored >> securely in the SMF repository, by default readable only by root, and >> at the same time would allow greater administrative flexibility in >> accessing or modifying this value, reducing the number of potential >> administrative tasks requiring full privileges. > > I'm a little confused about exactly who becomes responsible for > encrypting the sensitive credential in this case -- is it SMF or is it > the individual service? > > I'm uncomfortable with leaving this to the individual service (since it > effectively forces each service to reinvent their own wheel), especially > without very specific guidance in the SMF documentation. and where is the decryption key (or PIN to authenticate to the keystore) going to come from during boot ? -- Darren J Moffat From Nicolas.Williams@Sun.COM Wed Mar 28 08:53:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SFrZMu023033 for ; Wed, 28 Mar 2007 08:53:35 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SFrTTN011983; Wed, 28 Mar 2007 16:53:32 +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 <0JFM00903ET60800@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 08:53:30 -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 <0JFM006UWET6B360@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 08:53:30 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2SFqhlV002358; Wed, 28 Mar 2007 10:52:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2SFqhD8002357; Wed, 28 Mar 2007 10:52:43 -0500 (CDT) Date: Wed, 28 Mar 2007 10:52:43 -0500 From: Nicolas Williams Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <460A8AFD.9070507@Sun.COM> To: Darren J Moffat Cc: Bill Sommerfeld , psarc-ext@Sun.COM, Keith M Wesolowski , Michael Shapiro Message-id: <20070328155242.GJ1666@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: <200703221809.l2MI9n8a015947@zion.eng.sun.com> <1174589836.27921.28.camel@thunk> <20070322220416.GB596353@sun.com> <1175095772.25315.43.camel@thunk> <460A8AFD.9070507@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: 1132 On Wed, Mar 28, 2007 at 04:34:21PM +0100, Darren J Moffat wrote: > Bill Sommerfeld wrote: > >I'm a little confused about exactly who becomes responsible for > >encrypting the sensitive credential in this case -- is it SMF or is it > >the individual service? > > > >I'm uncomfortable with leaving this to the individual service (since it > >effectively forces each service to reinvent their own wheel), especially > >without very specific guidance in the SMF documentation. > > and where is the decryption key (or PIN to authenticate to the keystore) > going to come from during boot ? Having a key hierarchy rooted at a very small number of keys will make it practical to store such keys in the OBP (as in WANboot) or in the TPM (when we get support for that) or other token. Until then and on systems that lack such key storage tokens encrypting passwords and secret keys will amount to scrambling. Given that ISTM that asking SMF to encrypt read-sensitive values is probably not helpful at this time, that it can always be added later, provided that consumers get plaintext from SMF now and don't apply their own scrambling. From sommerfeld@sun.com Wed Mar 28 09:04:08 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SG47xX023998 for ; Wed, 28 Mar 2007 09:04:08 -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 l2SG459j029522; Thu, 29 Mar 2007 00:04:06 +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 <0JFM0092JFATHA00@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 09:04:05 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFM006OBFASB670@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 09:04:04 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2SG42xd004929; Wed, 28 Mar 2007 12:04:02 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SG41QH025794; Wed, 28 Mar 2007 12:04:01 -0400 (EDT) Date: Wed, 28 Mar 2007 12:04:00 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <460A8AFD.9070507@Sun.COM> To: Darren J Moffat Cc: Keith M Wesolowski , Michael Shapiro , psarc-ext@sun.com Message-id: <1175097840.25315.58.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703221809.l2MI9n8a015947@zion.eng.sun.com> <1174589836.27921.28.camel@thunk> <20070322220416.GB596353@sun.com> <1175095772.25315.43.camel@thunk> <460A8AFD.9070507@Sun.COM> Status: RO Content-Length: 883 On Wed, 2007-03-28 at 16:34 +0100, Darren J Moffat wrote: > > I'm uncomfortable with leaving this to the individual service (since it > > effectively forces each service to reinvent their own wheel), especially > > without very specific guidance in the SMF documentation. > > and where is the decryption key (or PIN to authenticate to the keystore) > going to come from during boot ? I this as a risk reduction exercise. Making components other than SMF do the encryption/obfuscation doesn't actually solve that problem, and, if anything, makes solving the problem harder. In the absence of a secure token, merely placing the SMF repository key in a separate file reduces the risk of accidental exposure of sensitive properties (for instance, through a "grep .. *" as root in the wrong directory). It also reduces (but does not eliminate) exposure in backups. - Bill From Keith.Wesolowski@sun.com Wed Mar 28 09:32:53 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SGWrae025288 for ; Wed, 28 Mar 2007 09:32:53 -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 l2SGWnDC027141; Wed, 28 Mar 2007 09:32:53 -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 <0JFM00A01GMTGM00@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 09:32:53 -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 <0JFM006BJGMSB9A0@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Mar 2007 09:32:52 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SGWqjT292043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2007 09:32:52 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2SGWqf6292001; Wed, 28 Mar 2007 09:32:52 -0700 (PDT) Date: Wed, 28 Mar 2007 09:32:44 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175095772.25315.43.camel@thunk> To: Bill Sommerfeld Cc: Michael Shapiro , psarc-ext@sun.com Message-id: <20070328163244.GA283365@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: <200703221809.l2MI9n8a015947@zion.eng.sun.com> <1174589836.27921.28.camel@thunk> <20070322220416.GB596353@sun.com> <1175095772.25315.43.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1967 On Wed, Mar 28, 2007 at 11:29:32AM -0400, Bill Sommerfeld wrote: > I believe that for reasons cited in the Best Practice that SMF should > take additional measures to protect property values identified as > sensitive and that those measures should receive open review. There are two general possibilities. A keyless reversible scheme (such as used in the ldap_client_cred case I noted previously) would provide no additional protection, only obscurity. A keyed scheme, as Darren pointed out, would still need to obtain a master key of some kind from somewhere. In the long run, hardware may help, but that hardware does not exist or cannot be used effectively today. So it would have to be either the repository or another locally-stored file owned by root and readable to no one else. This seems to provide additional complexity with no additional benefit, given that the repository itself already has those attributes. > I'm a little confused about exactly who becomes responsible for > encrypting the sensitive credential in this case -- is it SMF or is it > the individual service? > > I'm uncomfortable with leaving this to the individual service (since it > effectively forces each service to reinvent their own wheel), especially > without very specific guidance in the SMF documentation. There are two preexisting problems here: storage of sensitive data, and reversible obfuscation or encryption of it. Today's world leaves each service responsible for all aspects of both. This case attempts to solve the first of these by providing a repository-based protection mechanism superior to the use of discrete files. It does not attempt to resolve the other orthogonal problem: providing a generic mechanism for obfuscation or encryption of sensitive data prior to its storage. I believe this second problem should be addressed separately. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From Keith.Wesolowski@Sun.COM Wed Mar 28 09:48:48 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SGmlKq025887 for ; Wed, 28 Mar 2007 09:48:47 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2SGmZ6A000715; Wed, 28 Mar 2007 17:48:46 +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 <0JFM0070XHD9OT00@brm-avmta-1.central.sun.com>; Wed, 28 Mar 2007 10:48:45 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFM00214HD8IA50@brm-avmta-1.central.sun.com>; Wed, 28 Mar 2007 10:48:44 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2SGmioq295730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2007 09:48:44 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l2SGmhji295700; Wed, 28 Mar 2007 09:48:43 -0700 (PDT) Date: Wed, 28 Mar 2007 09:48:33 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175097840.25315.58.camel@thunk> To: Bill Sommerfeld Cc: Darren J Moffat , Michael Shapiro , psarc-ext@Sun.COM Message-id: <20070328164833.GB283365@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: <200703221809.l2MI9n8a015947@zion.eng.sun.com> <1174589836.27921.28.camel@thunk> <20070322220416.GB596353@sun.com> <1175095772.25315.43.camel@thunk> <460A8AFD.9070507@Sun.COM> <1175097840.25315.58.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1876 On Wed, Mar 28, 2007 at 12:04:00PM -0400, Bill Sommerfeld wrote: > Making components other than SMF do the encryption/obfuscation doesn't > actually solve that problem, and, if anything, makes solving the problem > harder. We're not imposing any new requirements on those components. They already have to (and do, to the extent that they adhere to the policy) encrypt or obfuscate the tokens. This case deals only with where the encrypted/obfuscated tokens are stored, not how they are transformed. A future case could provide a generic mechanism for encrypting and decrypting these properties, and libscf mechanisms for doing so. However, without extreme care that would actually cause a net reduction in security: all services wishing to read the property values would have to be run as root, or with the full set of privileges, in order to read the key file. As it stands, services could be run with reduced privileges and make use of more specific authorizations to obtain the values of its own properties (but not those associated with other services). An intermediate solution might provide for a simple keyless obfuscation mechanism that would not suffer from this deficiency. Either way, however, I assert that this issue is orthogonal to the one being addressed here. > In the absence of a secure token, merely placing the SMF repository key > in a separate file reduces the risk of accidental exposure of sensitive > properties (for instance, through a "grep .. *" as root in the wrong > directory). That's true only to the extent that the components would fail to encrypt or obscure sensitive data stored in the repository, but would do so properly when storing it in files. Such a bug is made no more likely by changing the storage mechanism. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From gww@eng.sun.com Fri Mar 30 16:42:43 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2UNghpj023363 for ; Fri, 30 Mar 2007 16:42:43 -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 l2UJohRa006386; Fri, 30 Mar 2007 12:50:44 -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 <0JFQ00B0BF4J5E00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 Mar 2007 12:50:43 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFQ00AA8F4IKEE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 Mar 2007 12:50:42 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2UJoggp017918; Fri, 30 Mar 2007 12:50:42 -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 l2UKo0G7010466; Fri, 30 Mar 2007 12:50:00 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2UKo00j010465; Fri, 30 Mar 2007 12:50:00 -0800 (PST) Date: Fri, 30 Mar 2007 12:50:00 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage To: Keith.Wesolowski@sun.com, sommerfeld@sun.com Cc: mws@zion.eng.sun.com, psarc-ext@sun.com Message-id: <200703302050.l2UKo00j010465@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3193 > > > I'm not comfortable with mixing sensitive properties into the main > > > property database - in the past, my advice to other projects (including > > > the wifi folks) has always been to isolate sensitive properties into > > > separate files so that we can in the future improve the protection of > > > them without complicating access to non-sensitive fields. Perhaps I'm miss remembering. I thought the wifi folk wanted to have the unsentivive properties accessible to all through a file of 644 permissions. Thus the WEP/WPA/ ... keys needed to be kept elsewhere. svc.configd is the arbritrator of the repository. The repository is mode 600. I believe this is a difference between these cases. > > > > > > In addition, the recommendation in the "password storage" best practice: > > > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > > > is that passwords and similar sensitive values be encrypted when stored > > > in the filesystem. > > FWIW, the password storage best practice is also published at: > http://www.opensolaris.org/os/community/arc/bestpractices/passwords-files/ I believe this proposal is designed to meet the actual policy as it would be applied to authorized use: If a program must store a principal's reusable password on a filesystem in order to automate future authentication attempts, then the program must place the password in a file which is readable only to the principal whose password is stored in the file. The permissions of the file should grant no access to either group or world. The repository is 600 to root; svc.configd interprets authorization as created by the administrator for access to sensitive properties. Now, the "Further, it is recommended ... encrypted ..." is not actually met. One might consider derailing to write an opinion that it is impossible for this case to provide a *master* way of encrypting sensitive property values without other technology (perhaps functional TPMs on all HW on which Nevada will ever run) -- and a project to make TPMs and master HW keys a requirement for Nevada be created. I'm not sure that's valuable. What is probably far more appropriate is to properly document the level of protection given to sensitive properties and leave it to the reader/writer of the property to provide greater protection as they see fit. IIRC, as Greenline was approved, the spec included something about properties being publically viewable and that any sensitive values should be encrypted by the application. This project corrects the publically viewable aspect. Consider the analogy of when passwd(4) contained the unix crypt values. The shadow(4) project made the unix crypt values hidden from public read access. The application is still responsible for creating and otherwise using the values stored there. I'm not sure why this project should be responsible for doing more than it proposes. Yes, it would be great to not rely on applications. I believe Solaris provides insufficient means to not rely on the application. Again, advice for a project to provide strong keying material for hands off operation. Gary.. From gww@eng.sun.com Fri Mar 30 16:42:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2UNgpD1023377 for ; Fri, 30 Mar 2007 16:42:52 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2UIu4qk004747; Fri, 30 Mar 2007 19:56:06 +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 <0JFQ00K0HCLGR200@brm-avmta-1.central.sun.com>; Fri, 30 Mar 2007 12:56:04 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFQ00LUXCLCMWC0@brm-avmta-1.central.sun.com>; Fri, 30 Mar 2007 12:56:00 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2UIu0DU009697; Fri, 30 Mar 2007 11:56:00 -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 l2UJtIFE010383; Fri, 30 Mar 2007 11:55:18 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2UJtH37010382; Fri, 30 Mar 2007 11:55:17 -0800 (PST) Date: Fri, 30 Mar 2007 11:55:17 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage To: gww@eng.sun.com, Keith.Wesolowski@sun.com Cc: mws@zion.eng.sun.com, psarc-ext@sun.com, mws@sun.com Message-id: <200703301955.l2UJtH37010382@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 409 > > It seems to me that I should > > be able to read all the property values, including the ones I > > can't set that do not have a read_authorization associated with > > them. > > You can. The behaviour of reading from property groups that don't > have a string-valued read_authorization property is absolutely and > completely unchanged by this case. OK, I guess I've just been dense. Gary.. From mws@zion.eng.sun.com Tue Apr 3 12:25:41 2007 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 l33JPeIm023540 for ; Tue, 3 Apr 2007 12:25: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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l33JP0r3028897; Tue, 3 Apr 2007 20:25:08 +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 <0JFX00I0RSLS7J00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 12:25:04 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFX00BETSLSOR60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 12:25:04 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l33JP3gD005726; Tue, 03 Apr 2007 12:25:03 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l33JP3gA013103; Tue, 03 Apr 2007 12:25:03 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l33JP2VP013102; Tue, 03 Apr 2007 12:25:02 -0700 (PDT) Date: Tue, 03 Apr 2007 12:25:02 -0700 (PDT) From: Michael Shapiro Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175097840.25315.58.camel@thunk> To: sommerfeld@sun.com (Bill Sommerfeld) Cc: Darren.Moffat@sun.com, Keith.Wesolowski@sun.com, psarc-ext@sun.com Message-id: <200704031925.l33JP2VP013102@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3669 > I this as a risk reduction exercise. > > Making components other than SMF do the encryption/obfuscation doesn't > actually solve that problem, and, if anything, makes solving the problem > harder. > > In the absence of a secure token, merely placing the SMF repository key > in a separate file reduces the risk of accidental exposure of sensitive > properties (for instance, through a "grep .. *" as root in the wrong > directory). > > It also reduces (but does not eliminate) exposure in backups. > > - Bill Bill, I've seen several replies to your questions, including from the various security folks, but I haven't seen any resolution from you yet. Can you clarify where we are on this case? Fundamentally here is what I see: Today in Solaris we have two potential repositories of credentials and passwords on the local system: local files owned by root mode 600, such as /etc/shadow and the ldap passwd, and the SMF database, also in effect a large file owned by root mode 0600. At the lowest level there is no security difference between these models: the security of data in either location is left up to the implementors in terms of how they represent and encode the information. There is nothing preventing anyone (including non-Sun ISVs etc.) from using either or both mechanisms in a relatively safe way, like the encrypted /etc/shadow form, or a relatively dumb way, like a cleartext password. The only thing we have to guide today is our ARC reviews and Best Practices. What this case proposes is a significant improvement to the SMF mechanism, namely that it enables the use of fine-grained authorizations already present in SMF to restrict access to passwords that are placed there, and this affords us the opportunity to improve our best practices by guiding people to this new mechanism. The new mechanism is an advantage not only because it offers authorizations but because it enables for these security properties the other benefits of SMF: rollback, observability, APIs, etc. Yet with these improvements, it is still an expectation that we have ARC review and Best Practices and that we advise people not to store cleartext data. There are extant projects which have or will need shortly to create such properties (e.g. iSCSI). With this case, we have a useful and better direction for them. Without it we don't and they do the same old dumb thing of having these ridiculous 0600 files with stuff scattered everywhere. Fundamentally if you want to go beyond this case towards encrypted storage, you must by definition have some key management mechanism in place (and I hope that isn't just another 0600 root file). There is no mechanism in place today for an admin to perform local key management for a local private store associated with the base operating system. And there are a very large number of design issues that crop up there (install, upgrade, h/w smart-cards, etc.) To ask this case to provide one would to me be an example of the ARC playing "go fetch a rock" asking the project team to not improve the world as it stands because you're asking for some large unspecified future project. And given that we're moving to ZFS with forthcoming encryption (which requires key mgmt) and for use as the root fs, it would also be entirely premature. This case is an obvious safe extension to what we have now that will improve the ARC's guidance for project teams and the resulting deliverables. Including advice for the steering committees to go think about key management is a useful companion but we shouldn't be further entangling this case. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From sommerfeld@sun.com Tue Apr 3 16:58:13 2007 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 l33NwDPj005729 for ; Tue, 3 Apr 2007 16:58:13 -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 l33NvgUB014641; Tue, 3 Apr 2007 16:57:42 -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 <0JFY00G0B5860R00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 16:57:42 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFY004R257Y9J80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 16:57:35 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l33NvW04026195; Tue, 03 Apr 2007 19:57:33 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l33NvWL7007174; Tue, 03 Apr 2007 19:57:32 -0400 (EDT) Date: Tue, 03 Apr 2007 19:57:31 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070403233127.GA290321@sun.com> To: Keith M Wesolowski Cc: Nicolas Williams , Michael Shapiro , psarc-ext@sun.com Message-id: <1175644651.1001.149.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704032142.l33LgOiA016621@zion.eng.sun.com> <1175639107.1001.112.camel@thunk> <20070403230139.GZ28748@Sun.COM> <20070403233127.GA290321@sun.com> Status: RO Content-Length: 877 (I'm taking the liberty of cc:ing this message from a side discussion to the case since it identifies a security issue with the current spec). On Tue, 2007-04-03 at 16:31 -0700, Keith M Wesolowski wrote: > On Tue, Apr 03, 2007 at 06:01:40PM -0500, Nicolas Williams wrote: > > > Also, what happens if one creates a property first, then one marks it > > sensitive? > > Just to clarify, sensitivity is specified on a property-group > granularity. So this condition would always exist unless > read_authorization is the first property created in a group. For whatever reason, that surprised me. It shouldn't have, but in any event, this seems like something that should be explicitly mentioned in the spec. I believe a spec update is required which warns about this problem and describes how this problem is avoided when importing a saved property group. - Bill From gww@eng.sun.com Tue Apr 3 17:13:51 2007 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 l340DoFp005886 for ; Tue, 3 Apr 2007 17:13:51 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l340DGG4010839; Wed, 4 Apr 2007 01:13:18 +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 <0JFY00H0B5Y43Z00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 17:13:16 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFY004Q95Y09P60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 17:13:12 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l340DCsl010862; Tue, 03 Apr 2007 17:13: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 l340E0SZ014826; Tue, 03 Apr 2007 17:14:00 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l340E0Uc014825; Tue, 03 Apr 2007 17:14:00 -0700 (PDT) Date: Tue, 03 Apr 2007 17:14:00 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage To: Keith.Wesolowski@sun.com, sommerfeld@sun.com Cc: Nicolas.Williams@sun.com, mws@zion.eng.sun.com, psarc-ext@sun.com Message-id: <200704040014.l340E0Uc014825@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1009 > On Tue, 2007-04-03 at 16:31 -0700, Keith M Wesolowski wrote: > > On Tue, Apr 03, 2007 at 06:01:40PM -0500, Nicolas Williams wrote: > > > > > Also, what happens if one creates a property first, then one marks it > > > sensitive? > > > > Just to clarify, sensitivity is specified on a property-group > > granularity. So this condition would always exist unless > > read_authorization is the first property created in a group. > > For whatever reason, that surprised me. It shouldn't have, but in any > event, this seems like something that should be explicitly mentioned in > the spec. > > I believe a spec update is required which warns about this problem and > describes how this problem is avoided when importing a saved property > group. What exactly is the concern here? Is it converting a previously existing property group into an SPG? It seemed to me that new manifests would be delivered with an SPG read_authorization value and then the admin would set the value(s) in that PG. Gary.. From sommerfeld@Sun.COM Tue Apr 3 17:21:56 2007 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 l340Ltmg006170 for ; Tue, 3 Apr 2007 17:21: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 l340LEle007805; Wed, 4 Apr 2007 08:21: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 <0JFY000076BL6100@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Apr 2007 17:21:21 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFY00LBP6BL6J20@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Apr 2007 17:21:21 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l340LHba024197; Tue, 03 Apr 2007 20:21:17 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l340LHbh007281; Tue, 03 Apr 2007 20:21:17 -0400 (EDT) Date: Tue, 03 Apr 2007 20:21:15 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200704040014.l340E0Uc014825@marduk.eng.sun.com> To: Gary Winiger Cc: Keith.Wesolowski@Sun.COM, Nicolas.Williams@Sun.COM, mws@zion.eng.sun.com, psarc-ext@Sun.COM Message-id: <1175646075.1001.160.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704040014.l340E0Uc014825@marduk.eng.sun.com> Status: RO Content-Length: 1030 On Tue, 2007-04-03 at 17:14 -0700, Gary Winiger wrote: > > I believe a spec update is required which warns about this problem and > > describes how this problem is avoided when importing a saved property > > group. > > What exactly is the concern here? Is it converting a previously > existing property group into an SPG? That would be one such case of concern, but it also includes the use of svccfg import to restore a backup of a secure property group into a repository in which the property group doesn't previously exist. (the backup would presumably have been created by the proposed svccfg exportall) > It seemed to me that new > manifests would be delivered with an SPG read_authorization value > and then the admin would set the value(s) in that PG. that doesn't help if the property group didn't exist prior to import of the backup. if the properties are not restored in the correct order, there may be a window of time during which a sensitive value will not be appropriately protected. - Bill From Keith.Wesolowski@Sun.COM Tue Apr 3 17:41:03 2007 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 l340f2wH006344 for ; Tue, 3 Apr 2007 17:41:02 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l340eNBp016589; Wed, 4 Apr 2007 01:40:29 +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 <0JFY00M0177F6V00@brm-avmta-1.central.sun.com>; Tue, 03 Apr 2007 18:40:27 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFY0080077EBFC0@brm-avmta-1.central.sun.com>; Tue, 03 Apr 2007 18:40:26 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l340eQks308472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 03 Apr 2007 17:40:26 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l340eQRX308471; Tue, 03 Apr 2007 17:40:26 -0700 (PDT) Date: Tue, 03 Apr 2007 17:40:26 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175644651.1001.149.camel@thunk> To: Bill Sommerfeld Cc: Nicolas Williams , Michael Shapiro , psarc-ext@Sun.COM Message-id: <20070404004026.GB290321@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: <200704032142.l33LgOiA016621@zion.eng.sun.com> <1175639107.1001.112.camel@thunk> <20070403230139.GZ28748@Sun.COM> <20070403233127.GA290321@sun.com> <1175644651.1001.149.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 483 On Tue, Apr 03, 2007 at 07:57:31PM -0400, Bill Sommerfeld wrote: > I believe a spec update is required which warns about this problem and > describes how this problem is avoided when importing a saved property > group. It appears that an import is done as a single transaction, so the window of vulnerability should be nonexistent. I can update the spec to reflect that. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From sommerfeld@Sun.COM Tue Apr 3 18:15:05 2007 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 l341F4N6007035 for ; Tue, 3 Apr 2007 18:15:05 -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 l341EFOa019400; Wed, 4 Apr 2007 09:14:32 +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 <0JFY00L038S7Q700@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 18:14:32 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFY004MC8S79JB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 18:14:31 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l341ETks027060; Tue, 03 Apr 2007 21:14:29 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l341ET8l007552; Tue, 03 Apr 2007 21:14:29 -0400 (EDT) Date: Tue, 03 Apr 2007 21:14:27 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070404004026.GB290321@sun.com> To: Keith M Wesolowski Cc: Nicolas Williams , Michael Shapiro , psarc-ext@Sun.COM Message-id: <1175649267.1001.183.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704032142.l33LgOiA016621@zion.eng.sun.com> <1175639107.1001.112.camel@thunk> <20070403230139.GZ28748@Sun.COM> <20070403233127.GA290321@sun.com> <1175644651.1001.149.camel@thunk> <20070404004026.GB290321@sun.com> Status: RO Content-Length: 589 On Tue, 2007-04-03 at 17:40 -0700, Keith M Wesolowski wrote: > On Tue, Apr 03, 2007 at 07:57:31PM -0400, Bill Sommerfeld wrote: > > > I believe a spec update is required which warns about this problem and > > describes how this problem is avoided when importing a saved property > > group. > > It appears that an import is done as a single transaction, so the > window of vulnerability should be nonexistent. I can update the spec > to reflect that. ok. sounds to me like it warrants a mention in smf_security(5) and the atomicity of import warrants a mention in svccfg(1m). From sommerfeld@Sun.COM Tue Apr 3 19:14:09 2007 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 l342E8au007938 for ; Tue, 3 Apr 2007 19:14:09 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l342DVPc015081; Wed, 4 Apr 2007 03:13:36 +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 <0JFY00509BIN0R00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 19:13:35 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFY004EWBIM9ID0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Apr 2007 19:13:34 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l342DTSq008702; Tue, 03 Apr 2007 22:13:29 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l342DT8C007751; Tue, 03 Apr 2007 22:13:29 -0400 (EDT) Date: Tue, 03 Apr 2007 22:13:28 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200704031925.l33JP2VP013102@zion.eng.sun.com> To: Michael Shapiro Cc: Darren.Moffat@Sun.COM, Keith.Wesolowski@Sun.COM, psarc-ext@Sun.COM Message-id: <1175652808.1001.235.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704031925.l33JP2VP013102@zion.eng.sun.com> Status: RO Content-Length: 4313 On Tue, 2007-04-03 at 12:25 -0700, Michael Shapiro wrote: > I've seen several replies to your questions, including from the various > security folks, but I haven't seen any resolution from you yet. > Can you clarify where we are on this case? It appears that the discussion was interrupted by the sac.eng update eating several messages. The discussion stumbled on during the outage in several private threads and rather than resurrecting the old messages I think I'll attempt to summarize my current position (since it has evolved somewhat through the discussion). Fundamentally I think we have a disagreement about appropriate practices for dealing with sensitive, immediately exploitable data such as raw passwords and keying material. I believe there are some simple and closely bounded changes to the spec which address my concerns; I don't believe that it's fair to characterize this as an unbounded "fetch a rock" exercise. My concerns are built on an intuitive understanding that commingling sensitive and non-sensitive data in the same file leads to trouble. It's a practice I've followed in systems I've built in the past and I haven't previously run into trouble convincing people to do this -- in short my past experience has been that taking extra care with sensitive is obviously the right thing to do. Several more specific concerns: 1) depending on details of the database's on-disk representation, the deletion of properties may not immediately overwrite the regions of the backing file with non-sensitive data; the sensitive data may linger on inside the file and be recoverable. (This is the same problem facing secure deletion in filesystems -- blocks are generally not zeroed on delete -- but adding a proper secure deletion mechanism to the underlying filesystem doesn't do anything about this problem within the database) 2) in many shared-secret-based systems such as kerberos, the sensitive keying material found on a typical host is entirely expendible; it is not necessary to back it up, and I know that it is not uncommon for sites using kerberos to exclude files such as /etc/krb5/krb5.keytab from backups. Commingling means that there will be no simple means to back up non-sensitive values while excluding sensitive but expendable properties. Existing practice in solaris is admittedly irregular. Sensitive values are generally found in files that have documented (and effectively Committed) names, though the the details of the file format are often Private. Documentation of the name is sufficient to allow the file to be excluded from backups with most backup software. 3) one suggestion which has been made but which seems difficult to put into practice is for sysadmins to exclude the entire database from backups but instead hook the backup system to create a filtered dump excluding sensitive properties. this seems much more difficult to get right than the current practice (where, with many subsystems, admins have some chance of being aware of which files contain expendable keys). I believe that there are some relatively well-contained changes to the proposal which avoid a regression in the ability of system administrators to better protect sensitive values. - encryption of sensitive values using a separately stored master key (a worked example of this can be found in the kerberos KDC software included in ON; see krb5kdc and kdb5_util's documentation of the "stash file". I can provide more specific details if the project team wants to pursue this course). - segregation of sensitive data into a separate backing file which can potentially be excluded from backups. (which is how wificonfig and dladm store WEP keys, and IPsec & IKE, sshd, apache, etc., all store their sensitive keying material). It is unclear to me why either of these options would create an unreasonable burden for this project. There is another less appealing alternative, which is to integrate this feature largely as proposed but with a global change of "sensitive" in the spec and man pages to a less sensitive term such as "non-public", and make it clear in documentation that it's not suitable for storage of keying material and passwords -- but I think that is inconsistent with many of the currently intended uses of this feature. - Bill From bart.smaalders@sun.com Wed Apr 4 11:30:31 2007 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 l34IUUx5028211 for ; Wed, 4 Apr 2007 11:30:30 -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 l34ITeIQ020687; Thu, 5 Apr 2007 02:29:56 +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 <0JFZ00B0DKPUG100@brm-avmta-1.central.sun.com>; Wed, 04 Apr 2007 12:29:54 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFZ005W3KPUEX40@brm-avmta-1.central.sun.com>; Wed, 04 Apr 2007 12:29:54 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l34ITqtt022113; Wed, 04 Apr 2007 11:29:52 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l34ITqjp008935; Wed, 04 Apr 2007 11:29:52 -0700 (PDT) Date: Wed, 04 Apr 2007 11:28:49 -0700 From: Bart Smaalders Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175652808.1001.235.camel@thunk> To: Bill Sommerfeld Cc: Michael Shapiro , psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <4613EE61.9030601@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.2.0.264296 References: <200704031925.l33JP2VP013102@zion.eng.sun.com> <1175652808.1001.235.camel@thunk> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1457 Bill Sommerfeld wrote: > Fundamentally I think we have a disagreement about appropriate practices > for dealing with sensitive, immediately exploitable data such as raw > passwords and keying material. > > I believe there are some simple and closely bounded changes to the spec > which address my concerns; I don't believe that it's fair to > characterize this as an unbounded "fetch a rock" exercise. Well, you've made two proposals: 1) an alternate key store using a separate 600 file (we cannot rely on always have kerberos available), which key is used to encrypt the secret data in the repository and 2) redesigning the transaction boundaries and database in SMF to use two files. Both these are attempts to deal with the security of backups issue. Neither one does anything to increase the security of the machine's data in-situ; the goal is to make the backed up data useless w/o additional keys that are hopefully backed up in some other way. It seems to me that this problem needs to be solved by providing a secure backup technology, not by forcing each project to implement workarounds that merely act as band-aids for the problem. You are suggesting that the only data worth preserving from casual perusal by ill-intentioned backup personnel is that which is storing security-related info, which is of course not the case. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sommerfeld@sun.com Wed Apr 4 13:25:37 2007 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 l34KPbHX001627 for ; Wed, 4 Apr 2007 13:25:37 -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 l34KP47O011052; Wed, 4 Apr 2007 13:25:04 -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 <0JFZ00C0VQ1SUK00@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Apr 2007 13:25:04 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFZ00B8ZQ1P4N50@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Apr 2007 13:25:02 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l34KOmZr003762; Wed, 04 Apr 2007 16:24:48 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34KOmPD001321; Wed, 04 Apr 2007 16:24:48 -0400 (EDT) Date: Wed, 04 Apr 2007 16:24:47 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <4613EE61.9030601@Sun.COM> To: Bart Smaalders Cc: Michael Shapiro , psarc-ext@sun.com, Keith.Wesolowski@sun.com, darren.moffat@sun.com Message-id: <1175718287.992.13.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704031925.l33JP2VP013102@zion.eng.sun.com> <1175652808.1001.235.camel@thunk> <4613EE61.9030601@Sun.COM> Status: RO Content-Length: 1324 I believe you've misread my arguments. On Wed, 2007-04-04 at 11:28 -0700, Bart Smaalders wrote: > Well, you've made two proposals: 1) an alternate key store > using a separate 600 file (we cannot rely on always have kerberos > available) I was not proposing using kerberos. I was suggesting that the mechanism used by the kerberos KDC to additionally protect sensitive values was a simple and appropriate model to copy. > You are > suggesting that the only data worth preserving from casual perusal > by ill-intentioned backup personnel is that which is storing > security-related info, which is of course not the case. I don't believe I actually said or implied that. Keying material (which in my mind includes shared secrets or passwords) is widely recognized as deserving of *additional* protection beyond the protections given to other sensitive data. My comments about backups reflect how they're commonly done today. Of course, they can be done better (and we are, in fact, working on products in that space; there was a recent extended discussion about key management for the T10000 encrypting tape drive on security-interest), but no matter how well they're done I'd still want to be able to easily exclude keying material from them if the material didn't actually need to be backed up. - Bill From mws@zion.eng.sun.com Wed Apr 4 13:58:33 2007 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 l34KwXXQ003065 for ; Wed, 4 Apr 2007 13:58:33 -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 l34Kw0Du027986; Wed, 4 Apr 2007 13:58:00 -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 <0JFZ00E09RKO8E00@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Apr 2007 13:58:00 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFZ00BKNRKO4LA0@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Apr 2007 13:58:00 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l34KvwSi011685; Wed, 04 Apr 2007 13:57:58 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l34Kvwik013121; Wed, 04 Apr 2007 13:57:58 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l34Kvw6O013120; Wed, 04 Apr 2007 13:57:58 -0700 (PDT) Date: Wed, 04 Apr 2007 13:57:58 -0700 (PDT) From: Michael Shapiro Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175718287.992.13.camel@thunk> To: sommerfeld@sun.com (Bill Sommerfeld) Cc: bart.smaalders@sun.com, psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <200704042057.l34Kvw6O013120@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2905 > I believe you've misread my arguments. > > On Wed, 2007-04-04 at 11:28 -0700, Bart Smaalders wrote: > > Well, you've made two proposals: 1) an alternate key store > > using a separate 600 file (we cannot rely on always have kerberos > > available) > > I was not proposing using kerberos. I was suggesting that the mechanism > used by the kerberos KDC to additionally protect sensitive values was a > simple and appropriate model to copy. Are you talking about the master password for encrypting krb5kdc's database? That's the key management issue to which I referred earlier -- how is that supposed to be set up and managed? That's a major architectural change to SMF and also to install, and I don't think we should go there. > > You are > > suggesting that the only data worth preserving from casual perusal > > by ill-intentioned backup personnel is that which is storing > > security-related info, which is of course not the case. > > I don't believe I actually said or implied that. > > Keying material (which in my mind includes shared secrets or passwords) > is widely recognized as deserving of *additional* protection beyond the > protections given to other sensitive data. > > My comments about backups reflect how they're commonly done today. Of > course, they can be done better (and we are, in fact, working on > products in that space; there was a recent extended discussion about key > management for the T10000 encrypting tape drive on security-interest), > but no matter how well they're done I'd still want to be able to easily > exclude keying material from them if the material didn't actually need > to be backed up. > > - Bill And for those who wish to do so, they can do that by: - create a crontab entry to svccfg archive (all xml minus sensitive stuff) to etc/svc/repository.xml, where a backup will pick it up - add etc/svc/repository.db to exclusion list The result is that any local backup will exclude the repository but pick up the safe XML, which can then be re-imported upon restore. By definition, anyone who is adopting your exclusion list approach must be doing manual procedures on restore anyway, because they're omitting metadata which is required for the restored filesystem to begin functioning without intervention. The above can trivially be documented as part of this case's man page changes. If that isn't acceptable to you, then it seems to me you're asking for a very large architectural change and an implied set of requirements for this project which you (and the ARC as a whole) are not applying to existing projects that are implementing 0600 root files. I also don't think it's feasible to have separate files given the SMF database design and keep transactional semantics, so the result is we will have nothing but the continuing series of 0600 files. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From sommerfeld@sun.com Wed Apr 4 15:09:06 2007 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 l34M965G004219 for ; Wed, 4 Apr 2007 15:09:06 -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 l34M8VKB005331; Wed, 4 Apr 2007 15:08:34 -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 <0JFZ0090HUU8RY00@brm-avmta-1.central.sun.com>; Wed, 04 Apr 2007 16:08:32 -0600 (MDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFZ004MDUU7FQ30@brm-avmta-1.central.sun.com>; Wed, 04 Apr 2007 16:08:32 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l34M8I6i018777; Wed, 04 Apr 2007 18:08:18 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l34M8EjG001653; Wed, 04 Apr 2007 18:08:14 -0400 (EDT) Date: Wed, 04 Apr 2007 18:08:08 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200704042057.l34Kvw6O013120@zion.eng.sun.com> To: Michael Shapiro Cc: bart.smaalders@sun.com, psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <1175724488.992.49.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704042057.l34Kvw6O013120@zion.eng.sun.com> Status: RO Content-Length: 1582 On Wed, 2007-04-04 at 13:57 -0700, Michael Shapiro wrote: > Are you talking about the master password for encrypting krb5kdc's database? yes. > That's the key management issue to which I referred earlier -- how is > that supposed to be set up and managed? That's a major architectural > change to SMF and also to install, and I don't think we should go there. maybe it's just my level of comfort and experience with cryptographic techniques but it doesn't strike me as a "major" change. I believe this can be handled entirely within SMF, with no changes needed to install. The initial seed repository contents are is public and by definition have no actual sensitive content. In the initial implementation, the first store of a sensitive property would generate a random master AES key, store it in a file in /etc/svc, and then use it to encrypt the sensitive property values. I don't think it's appropriate to do more detailed design here, but I'd be happy to work offline with the project team to help prototype this. > If that isn't acceptable to you, then it seems to me you're asking for a very > large architectural change again, we disagree about the scale of the change. > and an implied set of requirements for this project > which you (and the ARC as a whole) are not applying to existing projects that > are implementing 0600 root files. we only have the power to force incremental change -- new requirements are most commonly applied as projects/technologies come through for review of various changes (sometimes even unrelated changes). - Bill From bart.smaalders@sun.com Wed Apr 4 15:10:16 2007 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 l34MAGsM004327 for ; Wed, 4 Apr 2007 15:10:16 -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 l34M9hEu014887; Wed, 4 Apr 2007 15:09:43 -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 <0JFZ00H07UW4PI00@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Apr 2007 15:09:40 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFZ00GYAUW3MU10@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Apr 2007 15:09:39 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l34M9bAJ020531; Wed, 04 Apr 2007 15:09:37 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l34M9bRj014943; Wed, 04 Apr 2007 15:09:37 -0700 (PDT) Date: Wed, 04 Apr 2007 15:08:37 -0700 From: Bart Smaalders Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175718287.992.13.camel@thunk> To: Bill Sommerfeld Cc: Michael Shapiro , psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <461421E5.40208@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.2.0.264296 References: <200704031925.l33JP2VP013102@zion.eng.sun.com> <1175652808.1001.235.camel@thunk> <4613EE61.9030601@Sun.COM> <1175718287.992.13.camel@thunk> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2131 Bill Sommerfeld wrote: > I believe you've misread my arguments. > > On Wed, 2007-04-04 at 11:28 -0700, Bart Smaalders wrote: >> Well, you've made two proposals: 1) an alternate key store >> using a separate 600 file (we cannot rely on always have kerberos >> available) > > I was not proposing using kerberos. I was suggesting that the mechanism > used by the kerberos KDC to additionally protect sensitive values was a > simple and appropriate model to copy. > >> You are >> suggesting that the only data worth preserving from casual perusal >> by ill-intentioned backup personnel is that which is storing >> security-related info, which is of course not the case. > > I don't believe I actually said or implied that. > > Keying material (which in my mind includes shared secrets or passwords) > is widely recognized as deserving of *additional* protection beyond the > protections given to other sensitive data. > > My comments about backups reflect how they're commonly done today. Of > course, they can be done better (and we are, in fact, working on > products in that space; there was a recent extended discussion about key > management for the T10000 encrypting tape drive on security-interest), > but no matter how well they're done I'd still want to be able to easily > exclude keying material from them if the material didn't actually need > to be backed up. > So what your new rule states is that any project that uses passwords must provide separate files for the storage of those passwords, and (unstated, but required if to be useful) the fact that the passwords are stored in those files must be told to administrators so those files can be backed up separately using unspecified more secure mechanisms. The reason that a separate file must be used is that there is some unspecified limit on the size of the more secure backup, or is it something else? So where is the list of files that contain secrets kept? How does one back this up in a secure way? Is anyone working on this as a project? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From mws@zion.eng.sun.com Wed Apr 4 15:22:14 2007 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 l34MMEmb004534 for ; Wed, 4 Apr 2007 15:22:14 -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 l34MLf4Q017404; Wed, 4 Apr 2007 15:21:41 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JFZ00B03VG54K00@brm-avmta-1.central.sun.com>; Wed, 04 Apr 2007 16:21:41 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JFZ004Q5VG4FV40@brm-avmta-1.central.sun.com>; Wed, 04 Apr 2007 16:21:41 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l34MLcCt021628; Wed, 04 Apr 2007 15:21:38 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l34MLcVC015291; Wed, 04 Apr 2007 15:21:38 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l34MLcgE015290; Wed, 04 Apr 2007 15:21:38 -0700 (PDT) Date: Wed, 04 Apr 2007 15:21:38 -0700 (PDT) From: Michael Shapiro Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1175724488.992.49.camel@thunk> To: sommerfeld@sun.com (Bill Sommerfeld) Cc: bart.smaalders@sun.com, psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <200704042221.l34MLcgE015290@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2429 > On Wed, 2007-04-04 at 13:57 -0700, Michael Shapiro wrote: > > Are you talking about the master password for encrypting krb5kdc's database? > yes. > > > That's the key management issue to which I referred earlier -- how is > > that supposed to be set up and managed? That's a major architectural > > change to SMF and also to install, and I don't think we should go there. > > maybe it's just my level of comfort and experience with cryptographic > techniques but it doesn't strike me as a "major" change. > > I believe this can be handled entirely within SMF, with no changes > needed to install. > > The initial seed repository contents are is public and by definition > have no actual sensitive content. > > In the initial implementation, the first store of a sensitive property > would generate a random master AES key, store it in a file in /etc/svc, > and then use it to encrypt the sensitive property values. This has several problems. Chief among them is that it entirely breaks the model for repository backup and restore, since now we have a separate key file, which by virtue of being a separate file means we can't have transactional backup/restore. I also think it solves the problem at the wrong level. We have encrypted tapes now and we will soon have encrypted ZFS, both of which already require key mgmt and provide the better solution for this. Let me repeat what I said in the last e-mail to address your issue in terms of what we're talking about for this case: - create a crontab entry to svccfg archive (all xml minus sensitive stuff) to etc/svc/repository.xml, where a backup will pick it up - add etc/svc/repository.db to exclusion list The result is that any local backup will exclude the repository but pick up the safe XML, which can then be re-imported upon restore. By definition, anyone who is adopting your exclusion list approach must be doing manual procedures on restore anyway, because they're omitting metadata which is required for the restored filesystem to begin functioning without intervention. The above can trivially be documented as part of this case's man page changes. If this is satisfactory to you (or some reasonable modification thereof) then this case should be approved. If not, you should derail it and let the ARC consider your input and what everyone else has said in response. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From sommerfeld@sun.com Tue Apr 10 11:01:58 2007 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 l3AI1uvv000835 for ; Tue, 10 Apr 2007 11:01:57 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3AI1Ji9013687; Tue, 10 Apr 2007 19:01:20 +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 <0JGA00405NE6V200@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Apr 2007 11:01:18 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA000EONE5OX60@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Apr 2007 11:01:18 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3AI1D4w024362; Tue, 10 Apr 2007 14:01:13 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3AI1C6D025777; Tue, 10 Apr 2007 14:01:12 -0400 (EDT) Date: Tue, 10 Apr 2007 14:01:11 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <461421E5.40208@Sun.COM> To: Bart Smaalders Cc: Michael Shapiro , psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <1176228071.22952.93.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704031925.l33JP2VP013102@zion.eng.sun.com> <1175652808.1001.235.camel@thunk> <4613EE61.9030601@Sun.COM> <1175718287.992.13.camel@thunk> <461421E5.40208@Sun.COM> Status: RO Content-Length: 2280 (I've been slow in responding in part because the project team said they thought this wasn't particularly urgent, and in part because I spent a good portion of the past few days dealing with a head cold. This is the first of three messages; I'm replying primarily for the record; see the third message for a suggested way forward). On Wed, 2007-04-04 at 15:08 -0700, Bart Smaalders wrote: > So what your new rule states It's incorrect to characterize this as a "new rule". It's a long-established practice among multiple subsystems from multiple authors, many of which are incorporated into solaris. > is that any project that uses passwords > must provide separate files for the storage of those passwords, and > (unstated, but required if to be useful) the fact that the passwords > are stored in those files must be told to administrators so those files > can be backed up separately using unspecified more secure mechanisms. That's the existing practice across open-source implementations of kerberos, ssh, pgp, openssl, pppd & chat, etc., etc. Files containing keying material are documented interfaces of each package. > The reason that a separate file must be used is that there is some > unspecified limit on the size of the more secure backup, or is it > something else? to anyone working on cryptographic systems, keying material is generally seen as qualitatively different from non-keying material. there are two distinct differences: 1) it can be used directly to gain access to other data 2) it's usually tiny compared with the scale of the rest of the system (a few hundred bits for symmetric keys; a few thousand for public keys). fundamentally, keying material must be protected at least as well as anything else on the system. Fortunately, keys and passwords are typically much smaller than other data worth protecting. In some cases I've seen an index card or floppy disk sealed in an envelope, which is then locked up, used to back up keying material. In any event, for alternate architectures, take a look at the Apple Keychain or the GNOME keyring. It appears that MacOS has both a "system keychain" and per-user keychains, specifically for storing passwords and similar data separately from other configuration data. - Bill From sommerfeld@sun.com Tue Apr 10 11:02:00 2007 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 l3AI20vw000890 for ; Tue, 10 Apr 2007 11:02:00 -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 l3AI1Iec008314; Tue, 10 Apr 2007 11:01:24 -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 <0JGA0022PNECAD00@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 12:01:24 -0600 (MDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA00KWMNE97F20@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 12:01:21 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3AI1HjT015437; Tue, 10 Apr 2007 14:01:17 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3AI1HC0025780; Tue, 10 Apr 2007 14:01:17 -0400 (EDT) Date: Tue, 10 Apr 2007 14:01:17 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200704042221.l34MLcgE015290@zion.eng.sun.com> To: Michael Shapiro Cc: bart.smaalders@sun.com, psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <1176228077.22952.94.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704042221.l34MLcgE015290@zion.eng.sun.com> Status: RO Content-Length: 998 (This is the second of three messages; I'm replying primarily for the record; see the third message for a suggested way forward). On Wed, 2007-04-04 at 15:21 -0700, Michael Shapiro wrote: > Let me repeat what I said in the last e-mail to address your issue > in terms of what we're talking about for this case: > > - create a crontab entry to svccfg archive (all xml minus sensitive stuff) > to etc/svc/repository.xml, where a backup will pick it up there is a significant problem with this proposal: the cron job will necessarily run asynchronously with the backup and thus the backup may be out of synch with the rest of the system, restoring an older version of the repository. > If this is satisfactory to you (or some reasonable modification thereof) > then this case should be approved. If not, you should derail it and > let the ARC consider your input and what everyone else has said in response. I believe I need to take this route. Specifics will be in a forthcoming message. From sommerfeld@sun.com Tue Apr 10 11:02:25 2007 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 l3AI2Oo4000938 for ; Tue, 10 Apr 2007 11:02:25 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3AI1el6013794; Tue, 10 Apr 2007 19:01:48 +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 <0JGA0023FNEWCB00@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 12:01:44 -0600 (MDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA00KRTNEV7J30@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 12:01:44 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3AI1fZN015510; Tue, 10 Apr 2007 14:01:41 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3AI1f9O025784; Tue, 10 Apr 2007 14:01:41 -0400 (EDT) Date: Tue, 10 Apr 2007 14:01:38 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200704042221.l34MLcgE015290@zion.eng.sun.com> To: Michael Shapiro Cc: bart.smaalders@sun.com, psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <1176228099.22952.95.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704042221.l34MLcgE015290@zion.eng.sun.com> Status: RO Content-Length: 1919 (This is the third of three replies). On Wed, 2007-04-04 at 15:21 -0700, Michael Shapiro wrote: > If not, you should derail it and > let the ARC consider your input and what everyone else has said in response. So, I see considerable resistance from you and others to providing what I believe to be appropriate levels of protection for sensitive data. PSARC is limited in its power. We cannot actually force project teams to do anything when they really don't want to do it; we can only encourage them. I don't think there's anything architecturally wrong with including the ability to store read-protected data in the SMF property repository. The point of argument seems to center on whether that is adequate as a mechanism for protecting sensitive keying material. Given that the project team suggested early in the review that clients of this interface should provide additional protection for the sensitive data they store in SMF, I think that it's inappropriate to say this project is suitable for "sensitive" property storage. I think the course that is most likely to result in change meaningful to me is to derail, and seek the following spec changes: - TCR to remove all instances of the word "Sensitive" in the case title, the spec, and in any other documentation, rewording to "read-protected", "non-public", or other terms emphasising the mechanism used rather than the type of data stored. - Set precedent that other projects must not be required to use this mechanism to store passwords, shared secrets or keying material. - Recommend that a follow-up projects produce a general system keystore/keyring/keychain facility specifically designed to use multiple layers of protection for sensitive data. I'd appreciate comments from the project team, other members of the ARC, and any other interested parties on this way forward before this Wedneday's meeting. - Bill From mws@zion.eng.sun.com Tue Apr 10 11:16:36 2007 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 l3AIGa2G001348 for ; Tue, 10 Apr 2007 11:16:36 -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 l3AIFtki064651; Tue, 10 Apr 2007 12:15:55 -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 <0JGA00307O2JJQ00@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 12:15:55 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGA00KVHO2I7P30@brm-avmta-1.central.sun.com>; Tue, 10 Apr 2007 12:15:54 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3AIFrXj016792; Tue, 10 Apr 2007 11:15:53 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l3AIFrT2024203; Tue, 10 Apr 2007 11:15:53 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l3AIFqi5024202; Tue, 10 Apr 2007 11:15:52 -0700 (PDT) Date: Tue, 10 Apr 2007 11:15:52 -0700 (PDT) From: Michael Shapiro Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176228077.22952.94.camel@thunk> To: sommerfeld@sun.com (Bill Sommerfeld) Cc: bart.smaalders@sun.com, psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <200704101815.l3AIFqi5024202@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1211 > (This is the second of three messages; I'm replying primarily for the > record; see the third message for a suggested way forward). > > On Wed, 2007-04-04 at 15:21 -0700, Michael Shapiro wrote: > > Let me repeat what I said in the last e-mail to address your issue > > in terms of what we're talking about for this case: > > > > - create a crontab entry to svccfg archive (all xml minus sensitive stuff) > > to etc/svc/repository.xml, where a backup will pick it up > > there is a significant problem with this proposal: the cron job will > necessarily run asynchronously with the backup and thus the backup may > be out of synch with the rest of the system, restoring an older version > of the repository. You're really reaching: it takes on the order of one second of wallclock time to execute svccfg archive. Starting a backup a few *minutes* later will easily suffice. Or do this: svccfg archive && do_backup We can discuss your proposed resolution under the other thread as I don't think it relates to this issue in any case. But the thing I proposed is a simple and effect resolution to the problem that you posed. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From Keith.Wesolowski@sun.com Tue Apr 10 11:51:00 2007 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 l3AIp0gS001972 for ; Tue, 10 Apr 2007 11:51:00 -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 l3AIoJjJ023858; Tue, 10 Apr 2007 11:50:22 -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 <0JGA0062DPNXNQ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 11:50:21 -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 <0JGA004QSPNVKHE0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Apr 2007 11:50:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3AIoJh1447322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 11:50:19 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l3AIoJkw447321; Tue, 10 Apr 2007 11:50:19 -0700 (PDT) Date: Tue, 10 Apr 2007 11:50:19 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176228099.22952.95.camel@thunk> To: Bill Sommerfeld Cc: Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <20070410185019.GA446834@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: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1908 On Tue, Apr 10, 2007 at 02:01:38PM -0400, Bill Sommerfeld wrote: > Given that the project team suggested early in the review that clients > of this interface should provide additional protection for the sensitive > data they store in SMF, I think that it's inappropriate to say this > project is suitable for "sensitive" property storage. Ok. Given the changes you're suggesting, I don't think it's necessary to derail. > I think the course that is most likely to result in change meaningful to > me is to derail, and seek the following spec changes: > > - TCR to remove all instances of the word "Sensitive" in the case > title, the spec, and in any other documentation, rewording to > "read-protected", "non-public", or other terms emphasising the mechanism > used rather than the type of data stored. This is fine with us. We're willing to make this change in the materials, and document Mike's backup strategy in smf_security(5). I'll update the materials to reflect these changes. > - Set precedent that other projects must not be required to use this > mechanism to store passwords, shared secrets or keying material. We have never suggested that any project team is required to use this mechanism. However, it's also important to clarify that they should not be prevented from using it, either. The ARC should provide project teams with guidance as to whether the mechanism is appropriate to their needs. This was the gist of the changes I proposed to the SMF guidance; I'm open to suggestions for alternate language that would better achieve the effect you're seeking. > - Recommend that a follow-up projects produce a general system > keystore/keyring/keychain facility specifically designed to use multiple > layers of protection for sensitive data. Agree completely. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From sommerfeld@sun.com Wed Apr 11 09:17:37 2007 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 l3BGHbXE017733 for ; Wed, 11 Apr 2007 09:17:37 -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 l3BGH06R029315; Wed, 11 Apr 2007 09:17:00 -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 <0JGC00303D8CVJ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Apr 2007 09:17:00 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGC00EEBD8BP2A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Apr 2007 09:16:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3BGGsJ8019301; Wed, 11 Apr 2007 12:16:54 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3BGGsSC029675; Wed, 11 Apr 2007 12:16:54 -0400 (EDT) Date: Wed, 11 Apr 2007 12:16:53 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070410185019.GA446834@sun.com> To: Keith M Wesolowski Cc: Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <1176308213.22952.173.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> Status: RO Content-Length: 2147 On Tue, 2007-04-10 at 11:50 -0700, Keith M Wesolowski wrote: > Ok. Given the changes you're suggesting, I don't think it's necessary > to derail. For PSARC to formally recommend the followup work (which might be done by a different team - a system keyring would seem to be in scope for the EF/KMF folks) we would need an opinion and a vote, which requires a derail. I don't think we necessarily need to be that formal, though. > > I think the course that is most likely to result in change meaningful to > > me is to derail, and seek the following spec changes: > > > > - TCR to remove all instances of the word "Sensitive" in the case > > title, the spec, and in any other documentation, rewording to > > "read-protected", "non-public", or other terms emphasising the mechanism > > used rather than the type of data stored. > > This is fine with us. We're willing to make this change in the > materials, and document Mike's backup strategy in smf_security(5). > I'll update the materials to reflect these changes. Let me know when this is done. > > - Set precedent that other projects must not be required to use this > > mechanism to store passwords, shared secrets or keying material. > > We have never suggested that any project team is required to use this > mechanism. In general, we have a bias towards directing projects to use common infrastructure. > However, it's also important to clarify that they should > not be prevented from using it, either. The ARC should provide > project teams with guidance as to whether the mechanism is appropriate > to their needs. This was the gist of the changes I proposed to the > SMF guidance; I'm open to suggestions for alternate language that > would better achieve the effect you're seeking. I'll look at this and produce some specific text but the outline would be: - there are no really good solutions to storing sensitive data - when dealing with sensitive data, all implementation details matter - using this does not automatically lead to compliance with the "password storage in files" Best Practice; additional protections may be necessary. - Bill From sommerfeld@sun.com Wed Apr 11 09:18:31 2007 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 l3BGIUPj017812 for ; Wed, 11 Apr 2007 09:18:31 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3BGHli4015989; Wed, 11 Apr 2007 17:17:52 +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 <0JGC00L0LD9QDL00@brm-avmta-1.central.sun.com>; Wed, 11 Apr 2007 10:17:50 -0600 (MDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGC00GPKD9POV30@brm-avmta-1.central.sun.com>; Wed, 11 Apr 2007 10:17:49 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3BGHj25019456; Wed, 11 Apr 2007 12:17:45 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3BGHjFq029680; Wed, 11 Apr 2007 12:17:45 -0400 (EDT) Date: Wed, 11 Apr 2007 12:17:44 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200704101815.l3AIFqi5024202@zion.eng.sun.com> To: Michael Shapiro Cc: bart.smaalders@sun.com, psarc-ext@sun.com, Keith.Wesolowski@sun.com, Darren.Moffat@sun.com Message-id: <1176308264.22952.176.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704101815.l3AIFqi5024202@zion.eng.sun.com> Status: RO Content-Length: 781 On Tue, 2007-04-10 at 11:15 -0700, Michael Shapiro wrote: > it takes on the order of one second of wallclock > time to execute svccfg archive. Starting a backup a few *minutes* later > will easily suffice. Existing distributed backup systems I've administered (including both networker/EBS and amanda) schedule a limited number of dumps in parallel to maximize throughput to the tape device without thrashing. As a result, the time at which any individual filesystem is backed up will vary significantly from day to day depending in part on how much change occurred on other systems.. > Or do this: > > svccfg archive && do_backup This is often not an option; the "do_backup" part is generally scheduled under the control of the centralized backup system. - Bill From Keith.Wesolowski@sun.com Wed Apr 11 09:52:24 2007 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 l3BGqOXd019369 for ; Wed, 11 Apr 2007 09:52:24 -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 l3BGpitw013635; Wed, 11 Apr 2007 09:51:44 -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 <0JGC00201EU8V600@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Apr 2007 09:51:44 -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 <0JGC00MG9EU8K070@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Apr 2007 09:51:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3BGpiPO613976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 09:51:44 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l3BGpi6N613975; Wed, 11 Apr 2007 09:51:44 -0700 (PDT) Date: Wed, 11 Apr 2007 09:51:44 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176308213.22952.173.camel@thunk> To: Bill Sommerfeld Cc: Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <20070411165144.GB610575@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: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2117 On Wed, Apr 11, 2007 at 12:16:53PM -0400, Bill Sommerfeld wrote: > > This is fine with us. We're willing to make this change in the > > materials, and document Mike's backup strategy in smf_security(5). > > I'll update the materials to reflect these changes. > > Let me know when this is done. The updated materials are in commit.materials in the case directory. The files that have changed are smf_security.5, svccfg.1m, and the spec. I've introduced svccfg archive -a and documented its use with respect to backups in smf_security(5). I've also changed all referenced to "sensitive" to "protected." > I'll look at this and produce some specific text but the outline would > be: > - there are no really good solutions to storing sensitive data > - when dealing with sensitive data, all implementation details matter > - using this does not automatically lead to compliance with the > "password storage in files" Best Practice; additional protections may be > necessary. Would this be acceptable? # It should be noted that configuration data residing in the SCF | repository is world-readable by default. Projects with | configuration data that requires protection for security | reasons must consult with the ARC to determine if the Service | Configuration Facility is the appropriate repository for that data, | and what if any additional protections may be needed to comply with | best practices for storage of such data. Such project teams are | also advised to pay careful attention to implementation details, | and if possible avoid altogether storing such sensitive data. | If the SCF repository is used to store information requiring | protection, the property group(s) intended to contain that data | must be defined in manifests with an appropriate read_authorization | property (see smf_security(5)), and no data requiring protection | may be delivered in the manifest itself. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From David.Bustos@sun.com Fri Apr 13 16:40:33 2007 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 l3DNeWhG019026 for ; Fri, 13 Apr 2007 16:40:33 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3DNdidj022629; Sat, 14 Apr 2007 00:39:52 +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 <0JGG00901N2GX400@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Apr 2007 16:39:52 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGG001CUN2F8P60@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Apr 2007 16:39:51 -0700 (PDT) Received: from bargle.sfbay.sun.com (bargle.SFBay.Sun.COM [129.146.226.170]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l3DNdn90004823; Fri, 13 Apr 2007 16:39:49 -0700 (PDT) Received: from bargle.sfbay.sun.com (localhost [127.0.0.1]) by bargle.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3DNd8YA028387; Fri, 13 Apr 2007 16:39:08 -0700 (PDT) Received: (from bustos@localhost) by bargle.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l3DNd8aw028386; Fri, 13 Apr 2007 16:39:08 -0700 (PDT) Date: Fri, 13 Apr 2007 16:39:08 -0700 From: David Bustos Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070411165144.GB610575@sun.com> To: Keith M Wesolowski Cc: Bill Sommerfeld , Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <20070413233908.GA28379@bargle> 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: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> <20070411165144.GB610575@sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 523 Quoth Keith M Wesolowski on Wed, Apr 11, 2007 at 09:51:44AM -0700: > The updated materials are in commit.materials in the case directory. > The files that have changed are smf_security.5, svccfg.1m, and the > spec. I've introduced svccfg archive -a and documented its use with > respect to backups in smf_security(5). I've also changed all > referenced to "sensitive" to "protected." Does it make a difference that the output of svccfg archive can't be imported, and can only be used as a human-readable backup? David From sommerfeld@sun.com Mon Apr 16 15:03:26 2007 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 l3GM3Q07010339 for ; Mon, 16 Apr 2007 15:03:26 -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 l3GM2hgZ030727; Mon, 16 Apr 2007 16:02:44 -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 <0JGM00I052KKDK00@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Apr 2007 15:02:44 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGM00I9D2KJ0D10@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Apr 2007 15:02:44 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3GM2eOB011732; Mon, 16 Apr 2007 18:02:40 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3GM2dnw001211; Mon, 16 Apr 2007 18:02:39 -0400 (EDT) Date: Mon, 16 Apr 2007 18:02:39 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070413233908.GA28379@bargle> To: David Bustos Cc: Keith M Wesolowski , Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <1176760959.29780.14.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> <20070411165144.GB610575@sun.com> <20070413233908.GA28379@bargle> Status: RO Content-Length: 847 On Fri, 2007-04-13 at 16:39 -0700, David Bustos wrote: > Quoth Keith M Wesolowski on Wed, Apr 11, 2007 at 09:51:44AM -0700: > > The updated materials are in commit.materials in the case directory. > > The files that have changed are smf_security.5, svccfg.1m, and the > > spec. I've introduced svccfg archive -a and documented its use with > > respect to backups in smf_security(5). I've also changed all > > referenced to "sensitive" to "protected." > > Does it make a difference that the output of svccfg archive can't be > imported, and can only be used as a human-readable backup? If that is the case, I think it does -- any mention of "svccfg archive" as a backup mechanism is pointless unless there's some way to restore the backup. Are there plans to actually allow the output of "svccfg archive" to be reimported? - Bill From Keith.Wesolowski@sun.com Mon Apr 16 15:09:03 2007 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 l3GM92B2010451 for ; Mon, 16 Apr 2007 15:09:02 -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 l3GM8CNk013618; Tue, 17 Apr 2007 06:08:15 +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 <0JGM00B0R2TOX700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Apr 2007 15:08:12 -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 <0JGM00BN22TO4A00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Apr 2007 15:08:12 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3GM8CM2781459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 15:08:12 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l3GM8Clu781456; Mon, 16 Apr 2007 15:08:12 -0700 (PDT) Date: Mon, 16 Apr 2007 15:08:10 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176760959.29780.14.camel@thunk> To: Bill Sommerfeld Cc: David Bustos , Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <20070416220810.GA780273@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: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> <20070411165144.GB610575@sun.com> <20070413233908.GA28379@bargle> <1176760959.29780.14.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 839 On Mon, Apr 16, 2007 at 06:02:39PM -0400, Bill Sommerfeld wrote: > > Does it make a difference that the output of svccfg archive can't be > > imported, and can only be used as a human-readable backup? > > If that is the case, I think it does -- any mention of "svccfg archive" > as a backup mechanism is pointless unless there's some way to restore > the backup. > > Are there plans to actually allow the output of "svccfg archive" to be > reimported? Is there some reason to believe that an archive without the protected values is unimportable? It should be the same as today's output, just incomplete - and that incompleteness is desirable under a policy regime of the sort Bill envisions. Or am I missing something here? -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From David.Bustos@sun.com Mon Apr 16 16:21:06 2007 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 l3GNL55M012772 for ; Mon, 16 Apr 2007 16:21:05 -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 l3GNKEN2017520; Tue, 17 Apr 2007 07:20:22 +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 <0JGM00M0165XO000@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Apr 2007 16:20:21 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGM00ILS65W0DB0@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Apr 2007 16:20:20 -0700 (PDT) Received: from bargle.sfbay.sun.com (bargle.SFBay.Sun.COM [129.146.226.170]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3GNKInf016481; Mon, 16 Apr 2007 16:20:18 -0700 (PDT) Received: from bargle.sfbay.sun.com (localhost [127.0.0.1]) by bargle.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3GNJYqW000952; Mon, 16 Apr 2007 16:19:34 -0700 (PDT) Received: (from bustos@localhost) by bargle.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l3GNJYpp000951; Mon, 16 Apr 2007 16:19:34 -0700 (PDT) Date: Mon, 16 Apr 2007 16:19:34 -0700 From: David Bustos Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176760959.29780.14.camel@thunk> To: Bill Sommerfeld Cc: Keith M Wesolowski , Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <20070416231934.GA932@bargle> 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: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> <20070411165144.GB610575@sun.com> <20070413233908.GA28379@bargle> <1176760959.29780.14.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 563 Quoth Bill Sommerfeld on Mon, Apr 16, 2007 at 06:02:39PM -0400: > On Fri, 2007-04-13 at 16:39 -0700, David Bustos wrote: > > Does it make a difference that the output of svccfg archive can't be > > imported, and can only be used as a human-readable backup? > > If that is the case, I think it does -- any mention of "svccfg archive" > as a backup mechanism is pointless unless there's some way to restore > the backup. > > Are there plans to actually allow the output of "svccfg archive" to be > reimported? I have not seen backup work on any roadmap. David From Liane.Praza@sun.com Mon Apr 16 20:16:15 2007 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 l3H3GE8g021935 for ; Mon, 16 Apr 2007 20:16: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 l3H3FSq1000408; Tue, 17 Apr 2007 11:15:29 +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 <0JGM00C01H1TGV00@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Apr 2007 20:15:29 -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 <0JGM005EHH1SNH30@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Apr 2007 20:15:28 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3H3FSan828341; Mon, 16 Apr 2007 20:15:28 -0700 (PDT) Date: Mon, 16 Apr 2007 20:15:28 -0700 From: Liane Praza Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070416231934.GA932@bargle> Sender: Liane.Praza@sun.com To: David Bustos Cc: Bill Sommerfeld , psarc-ext@sun.com, Keith M Wesolowski , Michael Shapiro Message-id: <200704170315.l3H3FSan828341@jurassic-x4600.sfbay.sun.com> MIME-version: 1.0 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: interest Status: RO Content-Length: 984 David Bustos writes: > Quoth Bill Sommerfeld on Mon, Apr 16, 2007 at 06:02:39PM -0400: > > On Fri, 2007-04-13 at 16:39 -0700, David Bustos wrote: > > > Does it make a difference that the output of svccfg archive can't be > > > imported, and can only be used as a human-readable backup? > > > > If that is the case, I think it does -- any mention of "svccfg archive" > > as a backup mechanism is pointless unless there's some way to restore > > the backup. > > > > Are there plans to actually allow the output of "svccfg archive" to be > > reimported? > > I have not seen backup work on any roadmap. While David may not remember explicitly, additional backup work has appeared on multiple roadmap versions. Yes, we'd like for the output of svccfg archive to be able to be re-imported. However, it hasn't yet gotten the staffing necessary to achieve a completed design. That technical design would, of course, appear as a PSARC case as it would constitute new interface. liane From Keith.Wesolowski@sun.com Tue Apr 17 16:11:58 2007 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 l3HNBw72008130 for ; Tue, 17 Apr 2007 16:11:58 -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 l3HNBCoj025715; Tue, 17 Apr 2007 16:11:13 -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 <0JGO00B050EPD900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Apr 2007 16:11:13 -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 <0JGO00B2O0EO6X00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Apr 2007 16:11:12 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3HNBCJ5174964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 16:11:12 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0/Submit) id l3HNBCYx174963; Tue, 17 Apr 2007 16:11:12 -0700 (PDT) Date: Tue, 17 Apr 2007 16:11:12 -0700 From: Keith M Wesolowski Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176760959.29780.14.camel@thunk> To: Bill Sommerfeld Cc: David Bustos , Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <20070417231112.GC144695@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: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> <20070411165144.GB610575@sun.com> <20070413233908.GA28379@bargle> <1176760959.29780.14.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1597 On Mon, Apr 16, 2007 at 06:02:39PM -0400, Bill Sommerfeld wrote: > On Fri, 2007-04-13 at 16:39 -0700, David Bustos wrote: > > Quoth Keith M Wesolowski on Wed, Apr 11, 2007 at 09:51:44AM -0700: > > > The updated materials are in commit.materials in the case directory. > > > The files that have changed are smf_security.5, svccfg.1m, and the > > > spec. I've introduced svccfg archive -a and documented its use with > > > respect to backups in smf_security(5). I've also changed all > > > referenced to "sensitive" to "protected." > > > > Does it make a difference that the output of svccfg archive can't be > > imported, and can only be used as a human-readable backup? > > If that is the case, I think it does -- any mention of "svccfg archive" > as a backup mechanism is pointless unless there's some way to restore > the backup. > > Are there plans to actually allow the output of "svccfg archive" to be > reimported? I see that 6546699 svccfg archive should be able to be reimported has been filed for this. It seems that this means we can't document the backup workaround until that's implemented. My confusion here stemmed from thinking David meant we wouldn't be able to import the archive without the protected properties; now I see that it simply doesn't work at all. Still, since there's a clear intent to offer this functionality (and indeed, existing documentation strongly implies that it's meant to work already), it shouldn't make a difference to this case. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From sommerfeld@sun.com Wed Apr 18 10:09:54 2007 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 l3IH9sPk012200 for ; Wed, 18 Apr 2007 10:09:54 -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 l3IH96DV001903; Wed, 18 Apr 2007 10:09:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JGP00C0ZEB74800@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 10:09:07 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP00AA0EB6EX50@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 10:09:06 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3IH921C022301; Wed, 18 Apr 2007 13:09:02 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3IH92Cw008328; Wed, 18 Apr 2007 13:09:02 -0400 (EDT) Date: Wed, 18 Apr 2007 13:09:01 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <20070417231112.GC144695@sun.com> To: Keith M Wesolowski Cc: David Bustos , Michael Shapiro , bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <1176916141.8060.14.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> <20070411165144.GB610575@sun.com> <20070413233908.GA28379@bargle> <1176760959.29780.14.camel@thunk> <20070417231112.GC144695@sun.com> Status: RO Content-Length: 1125 On Tue, 2007-04-17 at 16:11 -0700, Keith M Wesolowski wrote: > Still, since there's a clear intent to offer this functionality (and > indeed, existing documentation strongly implies that it's meant to > work already), it shouldn't make a difference to this case. At the time we approved zones, there was *intent* to support upgrade but it didn't show up for a while. I think it depends on what you want to use the case for -- I'd say that the facilities provided by this case aren't suitable as an alternative to storing passwords in separate files without a *working* mechanism to exclude keying material from backups, and until 6546699 is fixed, svccfg archive doesn't count. I'd think that we'd want to hold off on approving any project which moves passwords or keying material into smf until there's a viable way to exclude it from backups. No, this isn't going to be a disaster on a par with our letting zones escape into the wild before we figured out how to upgrade them, but there does seem to be increasing mgmt attention directed towards ensuring projects aren't missing pieces at integration. - Bill From mws@zion.eng.sun.com Wed Apr 18 11:22:03 2007 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 l3IIM2Kx016056 for ; Wed, 18 Apr 2007 11:22:03 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3IILHgb018747; Wed, 18 Apr 2007 19:21:17 +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 <0JGP00M07HNGC900@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:21:16 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP009OCHNG1MC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:21:16 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3IILE55005419; Wed, 18 Apr 2007 11:21:14 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l3IILEno012259; Wed, 18 Apr 2007 11:21:14 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l3IILE5J012258; Wed, 18 Apr 2007 11:21:14 -0700 (PDT) Date: Wed, 18 Apr 2007 11:21:14 -0700 (PDT) From: Michael Shapiro Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176916141.8060.14.camel@thunk> To: sommerfeld@sun.com (Bill Sommerfeld) Cc: Keith.Wesolowski@sun.com, David.Bustos@sun.com, bart.smaalders@sun.com, psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <200704181821.l3IILE5J012258@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1742 > On Tue, 2007-04-17 at 16:11 -0700, Keith M Wesolowski wrote: > > Still, since there's a clear intent to offer this functionality (and > > indeed, existing documentation strongly implies that it's meant to > > work already), it shouldn't make a difference to this case. > > At the time we approved zones, there was *intent* to support upgrade but > it didn't show up for a while. > > I think it depends on what you want to use the case for -- I'd say that > the facilities provided by this case aren't suitable as an alternative > to storing passwords in separate files without a *working* mechanism to > exclude keying material from backups, and until 6546699 is fixed, svccfg > archive doesn't count. > > I'd think that we'd want to hold off on approving any project which > moves passwords or keying material into smf until there's a viable way > to exclude it from backups. > > No, this isn't going to be a disaster on a par with our letting zones > escape into the wild before we figured out how to upgrade them, but > there does seem to be increasing mgmt attention directed towards > ensuring projects aren't missing pieces at integration. > > - Bill PSARC case approvals shouldn't be affected by bugs. If there is a bug then write the ARC opinion to indicate that this case should not be integrated (i.e. the C-team should verify that) until the given bug ID is fixed, either beforehand, or by putback at the same time. Certainly the project team will adhere to that constraint: we want this to work. We've already agreed upon the solution from an ARC perspective: the presence of some SMF bug doesn't change what the ARC reviewed or approved. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From bart.smaalders@sun.com Wed Apr 18 11:39:10 2007 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 l3IId9xA016967 for ; Wed, 18 Apr 2007 11:39:10 -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 l3IIcKEt018785; Thu, 19 Apr 2007 02:38:23 +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 <0JGP00005IFYTT00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:38:22 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP000EAIFYKR00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:38:22 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3IIcK77008327; Wed, 18 Apr 2007 11:38:20 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l3IIcJDY012926; Wed, 18 Apr 2007 11:38:19 -0700 (PDT) Date: Wed, 18 Apr 2007 11:37:08 -0700 From: Bart Smaalders Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <1176916141.8060.14.camel@thunk> To: Bill Sommerfeld Cc: Keith M Wesolowski , David Bustos , Michael Shapiro , psarc-ext@sun.com, Darren.Moffat@sun.com Message-id: <46266554.3070900@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.2.0.264296 References: <200704042221.l34MLcgE015290@zion.eng.sun.com> <1176228099.22952.95.camel@thunk> <20070410185019.GA446834@sun.com> <1176308213.22952.173.camel@thunk> <20070411165144.GB610575@sun.com> <20070413233908.GA28379@bargle> <1176760959.29780.14.camel@thunk> <20070417231112.GC144695@sun.com> <1176916141.8060.14.camel@thunk> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1855 Bill Sommerfeld wrote: > On Tue, 2007-04-17 at 16:11 -0700, Keith M Wesolowski wrote: >> Still, since there's a clear intent to offer this functionality (and >> indeed, existing documentation strongly implies that it's meant to >> work already), it shouldn't make a difference to this case. > > At the time we approved zones, there was *intent* to support upgrade but > it didn't show up for a while. > > I think it depends on what you want to use the case for -- I'd say that > the facilities provided by this case aren't suitable as an alternative > to storing passwords in separate files without a *working* mechanism to > exclude keying material from backups, and until 6546699 is fixed, svccfg > archive doesn't count. > > I'd think that we'd want to hold off on approving any project which > moves passwords or keying material into smf until there's a viable way > to exclude it from backups. > > No, this isn't going to be a disaster on a par with our letting zones > escape into the wild before we figured out how to upgrade them, but > there does seem to be increasing mgmt attention directed towards > ensuring projects aren't missing pieces at integration. > > - Bill > > You suggest that there are architectural restrictions on password storage in files as a way of facilitating manual exclusion of those files by administrators as part of their backup procedures. How does an administrator who wishes to follow a security conscious backup plan do this? Where do we describe a proper backup plan with alternate more secure methods used for password/key files? Where is the list of files that contain passwords/keys published? How is this list maintained in the face of projects like wificonfig/dladm, etc? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From John.Plocher@sun.com Wed Apr 18 11:39:22 2007 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 l3IIdLZR016983 for ; Wed, 18 Apr 2007 11:39:22 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3IIcTWJ023794; Wed, 18 Apr 2007 19:38:34 +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 <0JGP00009IGAU700@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:38:34 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP000F6IG8KR00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:38:32 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3IIcWhU027869; Wed, 18 Apr 2007 11:38:32 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGP00G01ICYVY00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 18 Apr 2007 11:38:32 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGP00MCXIG7DBYW@d1-sfbay-10.sun.com>; Wed, 18 Apr 2007 11:38:32 -0700 (PDT) Date: Wed, 18 Apr 2007 11:38:28 -0700 From: John Plocher Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <200704181821.l3IILE5J012258@zion.eng.sun.com> Sender: John.Plocher@sun.com To: Michael Shapiro Cc: Bill Sommerfeld , psarc-ext@sun.com, David.Bustos@sun.com, Keith.Wesolowski@sun.com Message-id: <462665A4.3000003@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: <200704181821.l3IILE5J012258@zion.eng.sun.com> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 963 Michael Shapiro wrote: > PSARC case approvals shouldn't be affected by bugs. This bug affects the architecture of this new feature - it can't be used as intended because of this bug. If the feature were deployed before this bug were fixed, known bad things would happen. Since we know about this disconnect now (before this feature has integrated), the only thing we need to do is ensure that the C-Team & gatekeepers are aware of this synchronization need. The case opinion should have something like the following in it: Section 2. Decision & Precedence Information The project is approved as specified in reference [1]... The project may be delivered in an XXX release of the YYY consolidation. The project depends on the following other project and may not be delivered before it: BugID ####### - Description of bug i.e., it is not a spec change (and thus not a TCR) and it is not simply advice. -John From mws@zion.eng.sun.com Wed Apr 18 11:41:55 2007 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 l3IIfsso017146 for ; Wed, 18 Apr 2007 11:41:54 -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 l3IIf9Gu047656; Wed, 18 Apr 2007 12:41:09 -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 <0JGP00117IKL1T00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:41:09 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP000TSIKKKR00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 11:41:09 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3IIf88J009352; Wed, 18 Apr 2007 11:41:08 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l3IIf8Ka013128; Wed, 18 Apr 2007 11:41:08 -0700 (PDT) Received: (from mws@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l3IIf8nV013127; Wed, 18 Apr 2007 11:41:08 -0700 (PDT) Date: Wed, 18 Apr 2007 11:41:08 -0700 (PDT) From: Michael Shapiro Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <462665A4.3000003@Sun.Com> To: John.Plocher@sun.com (John Plocher) Cc: sommerfeld@sun.com, psarc-ext@sun.com, David.Bustos@sun.com, Keith.Wesolowski@sun.com Message-id: <200704181841.l3IIf8nV013127@zion.eng.sun.com> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL31H (25)] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1102 > Michael Shapiro wrote: > > PSARC case approvals shouldn't be affected by bugs. > > This bug affects the architecture of this new feature - it can't be > used as intended because of this bug. If the feature were deployed > before this bug were fixed, known bad things would happen. Since we > know about this disconnect now (before this feature has integrated), > the only thing we need to do is ensure that the C-Team & gatekeepers > are aware of this synchronization need. The case opinion should have > something like the following in it: > > > Section 2. Decision & Precedence Information > > The project is approved as specified in reference [1]... > The project may be delivered in an XXX release of the YYY > consolidation. The project depends on the following other > project and may not be delivered before it: > > BugID ####### - Description of bug > > > i.e., it is not a spec change (and thus not a TCR) and it is not simply > advice. > > -John Yes, exactly. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From sommerfeld@sun.com Tue Apr 24 13:22:15 2007 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 l3OKMEWG019414 for ; Tue, 24 Apr 2007 13:22:15 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3OKLDKv021336; Tue, 24 Apr 2007 21:21:23 +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 <0JH000101R7NHJ00@brm-avmta-1.central.sun.com>; Tue, 24 Apr 2007 14:21:23 -0600 (MDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH000MVER7MJ1E0@brm-avmta-1.central.sun.com>; Tue, 24 Apr 2007 14:21:22 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3OKLKRR008893; Tue, 24 Apr 2007 16:21:20 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3OKLKha001328; Tue, 24 Apr 2007 16:21:20 -0400 (EDT) Date: Tue, 24 Apr 2007 16:21:18 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Sensitive Property Storage In-reply-to: <462665A4.3000003@Sun.Com> To: John Plocher Cc: Michael Shapiro , psarc-ext@sun.com, David.Bustos@sun.com, Keith.Wesolowski@sun.com Message-id: <1177446078.1083.8.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704181821.l3IILE5J012258@zion.eng.sun.com> <462665A4.3000003@Sun.Com> Status: RO Content-Length: 388 given multiple responses assuming there will be an opinion, guess I'm stuck derailing this case and writing one. I don't believe we need a review meeting as I think there is general agreement about what needs to happen; I'll write a draft opinion which we can vote on. So I've marked the case "waiting need draft opinion". I'll attempt to get the draft done promptly. - Bill From owner-sec-swg-members Tue Jun 19 21:12:16 2007 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 l5K4CF52002014 for ; Tue, 19 Jun 2007 21:12:16 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5K4AZR9016223 for <@newsunmail1brm.central.sun.com:sec-swg-x@sun.com>; Wed, 20 Jun 2007 05:10:35 +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 <0JJX00G0329M7N00@brm-avmta-1.central.sun.com> for sec-swg-x@sun.com (ORCPT sec-swg-x@sun.com); Tue, 19 Jun 2007 22:10:34 -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 <0JJX00FHY29MDU00@brm-avmta-1.central.sun.com> for sec-swg-x@sun.com (ORCPT sec-swg-x@sun.com); Tue, 19 Jun 2007 22:10:34 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5K4AYqE026533 for ; Tue, 19 Jun 2007 21:10:34 -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 <0JJX0010125GCD00@fe-sfbay-09.sun.com> (original mail from Thomas.Tahan@Sun.COM) for sec-swg-x@sun.com (ORCPT sec-swg-x@sun.com); Tue, 19 Jun 2007 21:10:34 -0700 (PDT) Received: from [142.131.215.180] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJX000AQ29HIJA0@fe-sfbay-09.sun.com> for sec-swg-x@sun.com (ORCPT sec-swg-x@sun.com); Tue, 19 Jun 2007 21:10:34 -0700 (PDT) Date: Tue, 19 Jun 2007 21:11:26 -0800 From: Tom Tahan Subject: [Fwd: feedback to security SWG regarding "password storage in filesystem" vs PSARC 2007/177] Sender: Thomas.Tahan@sun.com To: sec-swg-x@sun.com Message-id: <4678B6FE.8050802@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 User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) Status: RO Content-Length: 2181 -------- Original Message -------- Subject: feedback to security SWG regarding "password storage in filesystem" vs PSARC 2007/177 Date: Tue, 19 Jun 2007 18:55:43 -0400 From: Bill Sommerfeld To: Glenn Brunette , Tom Tahan FYI, I ran into a little difficulty attempting to use the words of the Best Practice to support recommendations to a project team and as a result, an opinion I've just drafted for PSARC 2007/177 contains the following text: ------------- 4.2. Applicable Best Practices Many of the recommendations found in existing "Storing Reus- able Passwords on a Filesystem" Best Practice [2] appears to apply to uses of this facility as well. The best practice recommends that, in addition to the use of file permissions, additional protections be used where applicable. For instance: "... it is recommended that the actual reusable pass- word should be stored on the filesystem in either an encrypted or obfuscated format in order to help prevent against accidental disclosure." "... In the case where a single program must store and protect a variety of reusable passwords, consider the use of a master passphrase that is used by the program to encrypt and decrypt the password store." Unfortunately the text is focussed around interactive appli- cation considerations; many of the recommendations contain aspects that are not directly applicable to system com- ponents like SMF; some revision to the document seems to be called for to clearly show applicability of these concepts to system components. ... 6. Advisory Information 1. As discussed above in section 4.2, the Security SWG should review the current password-storage Best Practices document to see if it can be better phrased to apply to system components such as SMF and to sensitive parameters other than passwords. -------------- at this point this is just my opinion and not that of the rest of the ARC.. Any thoughts on what if anything the security swg could do to help? - Bill From sacadmin Wed Jul 18 11:59:52 2007 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 l6IIxqe5029715 for ; Wed, 18 Jul 2007 11:59:52 -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 l6IIvmBm000631; Wed, 18 Jul 2007 11:57: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 <0JLE00D0320B3700@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 11:57:47 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE00BSX20AWH10@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 11:57:46 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6IIvh9D001559; Wed, 18 Jul 2007 14:57:43 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6IIvhJs003512; Wed, 18 Jul 2007 14:57:43 -0400 (EDT) Date: Wed, 18 Jul 2007 14:57:42 -0400 From: Bill Sommerfeld Subject: PSARC 2007/177 SMF Read-Protected Property Storage draft opinion for review and vote. To: psarc Cc: mws@sun.com, "keith.wesolowski" , ahl@eng.sun.com Message-id: <1184785062.3132.8.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 12791 This is an opinion for a derailed fast-track which converged via email (and thus didn't need a meeting slot). I'd like to schedule a vote on this draft during next week's meeting (or by email if we cancel that meeting). TBD's in the draft will be filled in post-vote. - Bill sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: SMF Read-protected Property Storage Submitted by: Keith Wesoloski File: PSARC/2007/177/opinion.ms Date: TBD Committee: TBD Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary The project proposes to extend the access control facility for SMF properties to allow read access to property groups to be restricted to processes in possession of specific RBAC authorizations. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch release of the ON consolidation. The project depends on the following other project and may not be delivered before it: 6546699 svccfg archive should be able to be reimported 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| | | | | | | | | | | | | |____________________|________________|_________________| PSARC/2007/177 Copyright 2007 Sun Microsystems, Inc. - 2 - _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| |read_authorization | Committed | SMF Property;| | | | new with this| | | | project | |modify_authorization| Committed | SMF Property;| | | | revision of| | | | prior Evolving | |value_authorization | Committed | SMF Property;| | | | revision of| | | | prior Evolving | |svccfg export -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg archive -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg import | Committed | All imported| | | | property | | | | changes become| | | | visible simul-| | | | taneously. | | | | (See below) | |____________________|________________|_________________| 4. Opinion This project was originally titled "SMF Sensitive Property Storage". The committee felt it was appropriate to include a mechanism within SMF to allow properties to be read- protected. There was, however, significant difficulty with the assertion by the project team that this mechanism is sufficient for storage of sensitive security-critical values such as passwords and keys. The proposal includes only a read-protection facility based on authorizations; it does not include any additional protections. The primary archi- tectural question before us is whether SMF is the right home for such parameters, and if so, where additional protections belong -- should they live above, or below, the SMF property interface. 4.1. Background First, it's worth noting that when examining system secu- rity, it is necessary to look at across layers at relevant implementation details; in short, it's necessary to get all the details right. This goes against many otherwise well- founded instincts favoring trusting abstrations to deliver what they've committed to deliver. PSARC/2007/177 Copyright 2007 Sun Microsystems, Inc. - 3 - General purpose computer systems provide a regrettably poor environment for the protection of small sensitive items such as keys or passwords. Each additional copy of a sensitive value represents an additional opportunity for the value to leak; each additional component or layer with access to a sensitive value increases the risk that a bug or misconfi- guration may expose the value. The FIPS 140-2 specification for cryptographic modules[3] defines a concept known as a "Critical Security Parameter" as: "security-related information (e.g., secret and private cryptographic keys, and authentication data such as pass- words and PINs) whose disclosure or modification can compromise the security of a cryptographic module." If we replace "cryptographic module" with "system", we can apply this term more broadly to solaris, as this term would appear to cover many properties which service developers may wish to store. These properties tend to be both small, and changeable; the actual value stored matters less than the fact that two or more communicating principals share the same value. 4.2. Applicable Best Practices Many of the recommendations found in existing "Storing Reus- able Passwords on a Filesystem" Best Practice [2] appears to apply to uses of this facility as well. The best practice recommends that, in addition to the use of file permissions, additional protections be used where applicable. For instance: "... it is recommended that the actual reusable pass- word should be stored on the filesystem in either an encrypted or obfuscated format in order to help prevent against accidental disclosure." "... In the case where a single program must store and protect a variety of reusable passwords, consider the use of a master passphrase that is used by the program to encrypt and decrypt the password store." Unfortunately the text is focussed around interactive appli- cation considerations; many of the recommendations contain aspects that are not directly applicable to system com- ponents like SMF; some revision to the document seems to be called for to clearly show applicability of these concepts to system components. 4.3. Existing Practice Many existing subsystems within solaris store critical secu- rity parameters separately from other configuration parame- ters. The practice is somewhat uneven. An early example is the segregation of data between /etc/passwd and /etc/shadow; in addition, ssh/sshd, IKE, and 802.11 WEP/WPA store keys separately from other configuration. This pattern is found PSARC/2007/177 Copyright 2007 Sun Microsystems, Inc. - 4 - both in code native to solaris and code implemented else- where. The kerberos KDC uses a slightly different approach: it stores wrapped keys its database, encrypted using a separately-stored master key. Several other systems (including MacOS's "Apple Keychain" and GNOME's "Keyring") implement subsystems specifically for storage of sensitive properties distinct from the storage of configuration parameters. 4.4. Risks of commingling sensitive data If critical security parameters are mingled in the clear with other configuration data, additional security review is appropriate. In particular, the combination increases the number of factors affecting the risks of accidental expo- sure, exposure through backup media, and exposure through various end-runs around software layers involved in protect- ing the parameters. 4.4.1. Database implementation Details of the database implementation matter, particularly as relates to whether the original value of a property may be recoverable from the backing file after a property update or deletion. 4.4.2. Backup Critical security parameters stored in a shared file are more likely to be exposed in backups; it will also addition- ally be more difficult to exclude just these parameters from backup. 4.5. Use of this facility Use of this facilty to store secrets in the clear without additional practices does not implement all of the recommen- dations of the existing Best Practice for password storage[2]. While this may be no worse than existing behavior in some cases, it is possible to do better; accord- ingly, applications using this facility should carefully review the Best Practice and apply relevant additional pro- tections. In addition, since SMF access control is applied at the pro- perty group level, applications should segregate non-public data into separate property groups for reasons of least privilege. Applications creating property groups which may be used to store data which must be read-protected should be careful to ensure that protections are applied to the property group before any sensitive data is stored. PSARC/2007/177 Copyright 2007 Sun Microsystems, Inc. - 5 - The current implementation of "svccfg import" atomically adds all properties -- either all or none of the imported values are visible. The atomicity of this behavior was not previously documented. However, it has relevance for secu- rity (allowing *_authorization properties to be populated concurrently with the data they protect) and should be a documented and Committed behavior. 4.6. Related Projects The Solaris Cryptographic Framework is based around PKCS#11, which permits (but does not require) keys to be flagged as "sensitive"; when used in conjunction with a hardware key- store, this permits entities to be allowed to use a key without being able to access its value. Products implementing a secure keystore include the SCA 4000 ("Venus"[4]) and SCA6000 ("Mars"[5]); in addition, TPM hardware present on many x86 systems appears to have a simi- lar capability, though software support on solaris is not yet available. Virtualization technologies also have the potential to allow similar functionality to be implemented, keeping the actual value of critical keys out of reach of a hosted OS instance. There is a pending proposal to add the BSD "NODUMP" attri- bute (among others) to request that a file be excluded from backup.[6] 5. Minority Opinion(s) TBD/None 6. Advisory Information 1. As discussed above in section 4.2, the Security SWG should review the current password-storage Best Practices document to see if it can be better phrased to apply to system components such as SMF and to sensitive parameters other than passwords. 2. The Solaris PAC should give priority to a project which implements a protected system keyring inter- face for storage of sensitive properties which can take advantage of underlying hardware keystore facilities if present. 7. Appendices 7.1. Appendix A: Technical Changes Required PSARC/2007/177 Copyright 2007 Sun Microsystems, Inc. - 6 - 1. The project is renamed to "Read-protected property storage in SMF"; documentation must not imply that the feature provides complete protection for sen- sitive values. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/177. 1. Project specification. commit.materials/* 2. "Storing Reusable Passwords on a Filesystem" Best Prac- tice http://www.opensolaris.org/os/community/arc/bestpractices/passwords- files/ 3. "Security Requirements for Cryptographic Modules", FIPS 140-2. http://csrc.nist.gov/cryptval/140-2.htm 4. "Venus 2.0" SNARC 2004/077 5. "Mars 1.0 Project" PSARC 2005/617 6. Extensible Attribute Interfaces PSARC 2007/315 PSARC/2007/177 Copyright 2007 Sun Microsystems, Inc. From sommerfeld@sun.com Wed Jul 18 13:37:07 2007 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 l6IKb6ID002486 for ; Wed, 18 Jul 2007 13:37:07 -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 l6IKZ0sw005689; Thu, 19 Jul 2007 04:35: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 <0JLE00H1L6IBO000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 13:34:59 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE00HCC6IAGZ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 13:34:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6IKYtZH002475; Wed, 18 Jul 2007 16:34:55 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6IKYtCw003946; Wed, 18 Jul 2007 16:34:55 -0400 (EDT) Date: Wed, 18 Jul 2007 16:34:54 -0400 From: Bill Sommerfeld Subject: PSARC 2007/177 SMF Read-Protected Property Storage: draft opinion for review and vote To: PSARC-EXT Cc: mws@sun.com, "keith.wesolowski" , Adam Leventhal Message-id: <1184790894.3132.14.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 12953 This is a draft opinion for a derailed fast-track which converged via email (and thus didn't need a meeting slot). (note: I spazzed, forgot this was an open case, and sent it to the wrong place initially; apologies for the resend). I'd like to schedule a member vote on this draft during next week's meeting (or by email if we cancel that meeting). TBD's in the draft will be filled in post-vote. - Bill sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: SMF Read-protected Property Storage Submitted by: Keith Wesoloski File: PSARC/2007/177/opinion.ms Date: TBD Committee: TBD Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary The project proposes to extend the access control facility for SMF properties to allow read access to property groups to be restricted to processes in possession of specific RBAC authorizations. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch release of the ON consolidation. The project depends on the following other project and may not be delivered before it: 6546699 svccfg archive should be able to be reimported 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| | | | | | | | | | | | | |____________________|________________|_________________| PSARC/2007/177 Copyright 2007 Sun Microsystems - 2 - _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| |read_authorization | Committed | SMF Property;| | | | new with this| | | | project | |modify_authorization| Committed | SMF Property;| | | | revision of| | | | prior Evolving | |value_authorization | Committed | SMF Property;| | | | revision of| | | | prior Evolving | |svccfg export -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg archive -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg import | Committed | All imported| | | | property | | | | changes become| | | | visible simul-| | | | taneously. | | | | (See below) | |____________________|________________|_________________| 4. Opinion This project was originally titled "SMF Sensitive Property Storage". The committee felt it was appropriate to include a mechanism within SMF to allow properties to be read- protected. There was, however, significant difficulty with the assertion by the project team that this mechanism is sufficient for storage of sensitive security-critical values such as passwords and keys. The proposal includes only a read-protection facility based on authorizations; it does not include any additional protections. The primary archi- tectural question before us is whether SMF is the right home for such parameters, and if so, where additional protections belong -- should they live above, or below, the SMF property interface. 4.1. Background First, it's worth noting that when examining system secu- rity, it is necessary to look at across layers at relevant implementation details; in short, it's necessary to get all the details right. This goes against many otherwise well- founded instincts favoring trusting abstrations to deliver what they've committed to deliver. PSARC/2007/177 Copyright 2007 Sun Microsystems - 3 - General purpose computer systems provide a regrettably poor environment for the protection of small sensitive items such as keys or passwords. Each additional copy of a sensitive value represents an additional opportunity for the value to leak; each additional component or layer with access to a sensitive value increases the risk that a bug or misconfi- guration may expose the value. The FIPS 140-2 specification for cryptographic modules[3] defines a concept known as a "Critical Security Parameter" as: "security-related information (e.g., secret and private cryptographic keys, and authentication data such as pass- words and PINs) whose disclosure or modification can compromise the security of a cryptographic module." If we replace "cryptographic module" with "system", we can apply this term more broadly to solaris, as this term would appear to cover many properties which service developers may wish to store. These properties tend to be both small, and changeable; the actual value stored matters less than the fact that two or more communicating principals share the same value. 4.2. Applicable Best Practices Many of the recommendations found in existing "Storing Reus- able Passwords on a Filesystem" Best Practice [2] appears to apply to uses of this facility as well. The best practice recommends that, in addition to the use of file permissions, additional protections be used where applicable. For instance: "... it is recommended that the actual reusable pass- word should be stored on the filesystem in either an encrypted or obfuscated format in order to help prevent against accidental disclosure." "... In the case where a single program must store and protect a variety of reusable passwords, consider the use of a master passphrase that is used by the program to encrypt and decrypt the password store." Unfortunately the text is focussed around interactive appli- cation considerations; many of the recommendations contain aspects that are not directly applicable to system com- ponents like SMF; some revision to the document seems to be called for to clearly show applicability of these concepts to system components. 4.3. Existing Practice Many existing subsystems within solaris store critical secu- rity parameters separately from other configuration parame- ters. The practice is somewhat uneven. An early example is the segregation of data between /etc/passwd and /etc/shadow; in addition, ssh/sshd, IKE, and 802.11 WEP/WPA store keys separately from other configuration. This pattern is found PSARC/2007/177 Copyright 2007 Sun Microsystems - 4 - both in code native to solaris and code implemented else- where. The kerberos KDC uses a slightly different approach: it stores wrapped keys its database, encrypted using a separately-stored master key. Several other systems (including MacOS's "Apple Keychain" and GNOME's "Keyring") implement subsystems specifically for storage of sensitive properties distinct from the storage of configuration parameters. 4.4. Risks of commingling sensitive data If critical security parameters are mingled in the clear with other configuration data, additional security review is appropriate. In particular, the combination increases the number of factors affecting the risks of accidental expo- sure, exposure through backup media, and exposure through various end-runs around software layers involved in protect- ing the parameters. 4.4.1. Database implementation Details of the database implementation matter, particularly as relates to whether the original value of a property may be recoverable from the backing file after a property update or deletion. 4.4.2. Backup Critical security parameters stored in a shared file are more likely to be exposed in backups; it will also addition- ally be more difficult to exclude just these parameters from backup. 4.5. Use of this facility Use of this facilty to store secrets in the clear without additional practices does not implement all of the recommen- dations of the existing Best Practice for password storage[2]. While this may be no worse than existing behavior in some cases, it is possible to do better; accord- ingly, applications using this facility should carefully review the Best Practice and apply relevant additional pro- tections. In addition, since SMF access control is applied at the pro- perty group level, applications should segregate non-public data into separate property groups for reasons of least privilege. Applications creating property groups which may be used to store data which must be read-protected should be careful to ensure that protections are applied to the property group before any sensitive data is stored. PSARC/2007/177 Copyright 2007 Sun Microsystems - 5 - The current implementation of "svccfg import" atomically adds all properties -- either all or none of the imported values are visible. The atomicity of this behavior was not previously documented. However, it has relevance for secu- rity (allowing *_authorization properties to be populated concurrently with the data they protect) and should be a documented and Committed behavior. 4.6. Related Projects The Solaris Cryptographic Framework is based around PKCS#11, which permits (but does not require) keys to be flagged as "sensitive"; when used in conjunction with a hardware key- store, this permits entities to be allowed to use a key without being able to access its value. Products implementing a secure keystore include the SCA 4000 ("Venus"[4]) and SCA6000 ("Mars"[5]); in addition, TPM hardware present on many x86 systems appears to have a simi- lar capability, though software support on solaris is not yet available. Virtualization technologies also have the potential to allow similar functionality to be implemented, keeping the actual value of critical keys out of reach of a hosted OS instance. There is a pending proposal to add the BSD "NODUMP" attri- bute (among others) to request that a file be excluded from backup.[6] 5. Minority Opinion(s) TBD/None 6. Advisory Information 1. As discussed above in section 4.2, the Security SWG should review the current password-storage Best Practices document to see if it can be better phrased to apply to system components such as SMF and to sensitive parameters other than passwords. 2. The Solaris PAC should give priority to a project which implements a protected system keyring inter- face for storage of sensitive properties which can take advantage of underlying hardware keystore facilities if present. 7. Appendices 7.1. Appendix A: Technical Changes Required PSARC/2007/177 Copyright 2007 Sun Microsystems - 6 - 1. The project is renamed to "Read-protected property storage in SMF"; documentation must not imply that the feature provides complete protection for sen- sitive values. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/177. 1. Project specification. commit.materials/* 2. "Storing Reusable Passwords on a Filesystem" Best Prac- tice http://www.opensolaris.org/os/community/arc/bestpractices/passwords- files/ 3. "Security Requirements for Cryptographic Modules", FIPS 140-2. http://csrc.nist.gov/cryptval/140-2.htm 4. "Venus 2.0" SNARC 2004/077 5. "Mars 1.0 Project" PSARC 2005/617 6. Extensible Attribute Interfaces PSARC 2007/315 PSARC/2007/177 Copyright 2007 Sun Microsystems From gww@eng.sun.com Wed Jul 18 14:39:56 2007 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 l6ILdtq4004997 for ; Wed, 18 Jul 2007 14:39:55 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6ILbnYx017624; Wed, 18 Jul 2007 22:37:50 +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 <0JLE000079F0JX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 14:37:48 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE00H2C9EZGZD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 14:37:47 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6ILblVa021413; Wed, 18 Jul 2007 14:37:47 -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 l6ILfGbc027712; Wed, 18 Jul 2007 14:41:16 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l6ILfGvt027711; Wed, 18 Jul 2007 14:41:16 -0700 (PDT) Date: Wed, 18 Jul 2007 14:41:16 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Read-Protected Property Storage: draft opinion for review and vote To: PSARC-EXT@sun.com, sommerfeld@sun.com Cc: mws@sun.com, keith.wesolowski@sun.com, ahl@eng.sun.com Message-id: <200707182141.l6ILfGvt027711@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1303 Bill, > TBD's in the draft will be filled in post-vote. Not as a PSARC review comment as that hasn't started yet, but as a comment in preperation for voting: > 4.5. Use of this facility > In addition, since SMF access control is applied at the pro- > perty group level, applications should segregate non-public > data into separate property groups for reasons of least > privilege. My understanding of the project is that the only way a property becomes a "protected" property is for it to be in a property group that defines a read_authorization value within that property group. VIZ: > Applications creating property groups which may be used to > store data which must be read-protected should be careful to > ensure that protections are applied to the property group > before any sensitive data is stored. Have I misunderstood, or is this part of the opinion trying to express something else? Gary.. P.S. I'd point out the long standing /etc/.rootkey example is not mentioned and probably should be mentioned. From sommerfeld@sun.com Wed Jul 18 15:07:10 2007 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 l6IM79JT006477 for ; Wed, 18 Jul 2007 15:07:10 -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 l6IM4sq4000923; Thu, 19 Jul 2007 06:05:04 +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 <0JLE0092XAODNO00@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 16:05:01 -0600 (MDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE009LRAOC0Y20@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 16:05:00 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6IM4vqm012723; Wed, 18 Jul 2007 18:04:57 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6IM4v3H004227; Wed, 18 Jul 2007 18:04:57 -0400 (EDT) Date: Wed, 18 Jul 2007 18:04:56 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Read-Protected Property Storage: draft opinion for review and vote In-reply-to: <200707182141.l6ILfGvt027711@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC-EXT@sun.com, mws@sun.com, keith.wesolowski@sun.com, ahl@eng.sun.com Message-id: <1184796296.3132.55.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707182141.l6ILfGvt027711@marduk.eng.sun.com> Status: RO Content-Length: 2290 On Wed, 2007-07-18 at 14:41 -0700, Gary Winiger wrote: > > In addition, since SMF access control is applied at the pro- > > perty group level, applications should segregate non-public > > data into separate property groups for reasons of least > > privilege. > > My understanding of the project is that the only way > a property becomes a "protected" property is for it > to be in a property group that defines a read_authorization > value within that property group. VIZ: > > > > value='solaris.smf.read.myservice' /> > That is my understanding as well. A server may need to store properties with differing sensitivity -- for instance, one may really need to be read-protected (security model falls apart if it's disclosed), while others don't need to be read-protected but which doesn't really need to be public (many configuration parameters will be like this). Someone might opt for a single property group in this case, and that would be wrong -- later on they might find they were wrong about the "don't really need to be public" part.. Best to start off with the properties segregated in different property groups. Maybe there's a better way to express this. Any suggestions? > > Applications creating property groups which may be used to > > store data which must be read-protected should be careful to > > ensure that protections are applied to the property group > > before any sensitive data is stored. > > Have I misunderstood, or is this part of the opinion > trying to express something else? if you do things in the other order (store the value, then set the protections), an attacker with good timing could sneak in sideways and steal the value. The next paragraph says "svccfg import" does this right, but my understanding is that import is not the only way to create property groups.. > P.S. I'd point out the long standing /etc/.rootkey example > is not mentioned and probably should be mentioned. I added "Secure RPC" to the list of example technologies; let me know if you think additional detail is needed. From sommerfeld@sun.com Tue Jul 31 18:20:20 2007 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 l711KKrH020370 for ; Tue, 31 Jul 2007 18:20:20 -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 l711I01L002684; Tue, 31 Jul 2007 19:18:05 -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 <0JM200A2LMA55I00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 31 Jul 2007 18:18:05 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM200FNFMA5J760@nwk-avmta-1.sfbay.Sun.COM>; Tue, 31 Jul 2007 18:18:05 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l711I3vj008685; Tue, 31 Jul 2007 21:18:03 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l711I2fE021421; Tue, 31 Jul 2007 21:18:03 -0400 (EDT) Date: Tue, 31 Jul 2007 21:18:01 -0400 From: Bill Sommerfeld Subject: PSARC 2007/177 SMF Read-Protected Property Storage: 2nd draft opinion for review and vote In-reply-to: <1184790894.3132.14.camel@thunk> To: PSARC-EXT Cc: mws@sun.com, "keith.wesolowski" , Adam Leventhal Message-id: <1185931082.18965.136.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1184790894.3132.14.camel@thunk> Status: RO Content-Length: 14827 On Wed, 2007-07-18 at 16:34 -0400, Bill Sommerfeld wrote: > I'd like to schedule a member vote on this draft during next week's > meeting (or by email if we cancel that meeting). the email vote didn't get started because Gary and I were still going back and forth on some edits, so the vote is still on the agenda. This is the 2nd draft; I hope we can vote on this tomorrow. - Bill current version: sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: SMF Read-protected Property Storage Submitted by: Keith Wesoloski File: PSARC/2007/177/opinion.ms Date: TBD Committee: TBD Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary The project proposes to extend the access control facility for SMF properties to allow read access to property groups to be restricted to processes in possession of specific RBAC authorizations. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch release of the ON consolidation. The project depends on the following other project and may not be delivered before it: 6546699 svccfg archive should be able to be reimported 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| | | | | | | | | | | | | |____________________|________________|_________________| PSARC/2007/177 Copyright 2007 Sun Microsystems - 2 - _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| |read_authorization | Committed | SMF Property;| | | | new with this| | | | project | |modify_authorization| Committed | SMF Property;| | | | revision of| | | | prior Evolving | |value_authorization | Committed | SMF Property;| | | | revision of| | | | prior Evolving | |svccfg export -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg archive -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg import | Committed | All imported| | | | property | | | | changes become| | | | visible simul-| | | | taneously. | | | | (See below) | |____________________|________________|_________________| 4. Opinion This project was originally titled "SMF Sensitive Property Storage". The committee felt it was appropriate to include a mechanism within SMF to allow properties to be read- protected. There was, however, significant difficulty with the assertion by the project team that this mechanism is sufficient for storage of sensitive security-critical values such as passwords and keys. The proposal includes only a read-protection facility based on authorizations; it does not include any additional protections. The primary archi- tectural question before us is whether SMF is the right home for such parameters, and if so, where additional protections belong -- should they live above, or below, the SMF property interface. 4.1. Background First, it's worth noting that when examining system secu- rity, it is necessary to look at across layers at relevant implementation details; in short, it's necessary to get all the details right. This goes against many otherwise well- founded instincts favoring trusting abstrations to deliver what they've committed to deliver. PSARC/2007/177 Copyright 2007 Sun Microsystems - 3 - General purpose computer systems provide a regrettably poor environment for the protection of small sensitive items such as keys or passwords. Each additional copy of a sensitive value represents an additional opportunity for the value to leak; each additional component or layer with access to a sensitive value increases the risk that a bug or misconfi- guration may expose the value. The FIPS 140-2 specification for cryptographic modules[3] defines a concept known as a "Critical Security Parameter" as: "security-related information (e.g., secret and private cryptographic keys, and authentication data such as pass- words and PINs) whose disclosure or modification can compromise the security of a cryptographic module." If we replace "cryptographic module" with "system", we can apply this term more broadly to solaris, as this term would appear to cover many properties which service developers may wish to store. These properties tend to be both small, and changeable; the actual value stored matters less than the fact that two or more communicating principals share the same value. 4.2. Applicable Best Practices Many of the recommendations found in existing "Storing Reus- able Passwords on a Filesystem" Best Practice [2] appears to apply to uses of this facility as well. The best practice recommends that, in addition to the use of file permissions, additional protections be used where applicable. For instance: "... it is recommended that the actual reusable pass- word should be stored on the filesystem in either an encrypted or obfuscated format in order to help prevent against accidental disclosure." "... In the case where a single program must store and protect a variety of reusable passwords, consider the use of a master passphrase that is used by the program to encrypt and decrypt the password store." Unfortunately the text is focussed around interactive appli- cation considerations; many of the recommendations contain aspects that are not directly applicable to system com- ponents like SMF; some revision to the document seems to be called for to clearly show applicability of these concepts to system components. 4.3. Existing Practice Many existing subsystems within solaris store critical secu- rity parameters separately from other configuration parame- ters. The practice is somewhat uneven. An early example is the segregation of data between /etc/passwd and /etc/shadow; in addition, Secure RPC, ssh/sshd, IKE, and 802.11 WEP/WPA all store keys separately from other configuration. This PSARC/2007/177 Copyright 2007 Sun Microsystems - 4 - pattern is found both in code native to solaris and code implemented elsewhere. The kerberos KDC uses a slightly different approach: it stores wrapped keys its database, encrypted using a separately-stored master key. Several other systems (including MacOS's "Apple Keychain" and GNOME's "Keyring") implement subsystems specifically for storage of sensitive properties distinct from the storage of configuration parameters. 4.4. Risks of commingling sensitive data If critical security parameters are mingled in the clear with other configuration data, additional security review is appropriate. In particular, the combination increases the number of factors affecting the risks of accidental expo- sure, exposure through backup media, and exposure through various end-runs around software layers involved in protect- ing the parameters. 4.4.1. Database implementation Details of the database implementation matter, particularly as relates to whether the original value of a property may be recoverable from the backing file after a property update or deletion. 4.4.2. Backup Critical security parameters stored in a shared file are more likely to be exposed in backups; it will also addition- ally be more difficult to exclude just these parameters from backup. 4.5. Use of this facility Use of this facilty to store secrets in the clear without additional practices does not implement all of the recommen- dations of the existing Best Practice for password storage[2]. While this may be no worse than existing behavior in some cases, it is possible to do better; accord- ingly, applications using this facility should carefully review the Best Practice and apply relevant additional pro- tections. In addition, since SMF access control is applied at the pro- perty group level, applications must segregate non-public properties into separate read-protected property groups. To avoid the need to grant authorizations too widely, proper- ties which do not need read protection should not be placed in read-protected property groups. Applications creating read-protected property groups do so by including a "read_authorization" property value. The PSARC/2007/177 Copyright 2007 Sun Microsystems - 5 - authorization name must correspond to the SMF Policy requirements for such values and the authorization must be included in an appropriate Rights Profile. During initial install of a package, this authorization value should be set through the import of a service manifest. Consistent with the Secure by Default Policy[7] and the Install-Time Security Policy[8], service manifests delivered as part of the installation of a software package must not permit operation using placeholder sensitive values; ser- vices dependent on these values must behave in a safe manner (typically by denying access) until the sensitive value is appropriately initialized for real. In the event that read-protected property groups are created by other means (for instance, to store per-service-instance data for a dynamically changing set of service instances), the read_authorization property must be set before any sen- sitive data is stored to ensure there is no window of time where the sensitive values are unprotected. The current implementation of "svccfg import" atomically adds all properties -- either all or none of the imported values are visible. The atomicity of this behavior was not previously documented. However, it has relevance for secu- rity (allowing *_authorization properties to be populated concurrently with the data they protect) and should be a documented and Committed behavior. 4.6. Related Projects The Solaris Cryptographic Framework is based around PKCS#11, which permits (but does not require) keys to be flagged as "sensitive"; when used in conjunction with a hardware key- store, this permits entities to be allowed to use a key without being able to access its value. Products implementing a secure keystore include the SCA 4000 ("Venus"[4]) and SCA6000 ("Mars"[5]); in addition, TPM hardware present on many x86 systems appears to have a simi- lar capability, though software support on solaris is not yet available. Virtualization technologies also have the potential to allow similar functionality to be implemented, keeping the actual value of critical keys out of reach of a hosted OS instance. It may be appropriate for projects needing read-protected properties to either encrypt those properties using the encryption framework or store them using a PKCS#11 token instead; as hardware keystores become more generally avail- able this should lead to significantly improved protection against disclosure. PSARC/2007/177 Copyright 2007 Sun Microsystems - 6 - There is also a pending proposal to add the BSD "NODUMP" attribute (among others) to request that a file be excluded from backup.[6] 5. Minority Opinion(s) TBD/None 6. Advisory Information 1. As discussed above in section 4.2, the Security SWG should review the current password-storage Best Practices document to see if it can be better phrased to apply to system components such as SMF and to sensitive parameters other than passwords. 2. The Solaris PAC should give priority to a project which implements a protected system keyring inter- face for storage of sensitive properties which can take advantage of underlying hardware keystore facilities if present. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project is renamed to "Read-protected property storage in SMF"; documentation must not imply that the feature provides complete protection for sen- sitive values. 2. The recommendations in section 4.5 above must be included in the smf_security(5) man page. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/177. 1. Project specification. commit.materials/* 2. "Storing Reusable Passwords on a Filesystem" Best Prac- tice http://www.opensolaris.org/os/community/arc/bestpractices/passwords- files/ 3. "Security Requirements for Cryptographic Modules", FIPS 140-2. http://csrc.nist.gov/cryptval/140-2.htm PSARC/2007/177 Copyright 2007 Sun Microsystems - 7 - 4. "Venus 2.0" SNARC 2004/077 5. "Mars 1.0 Project" PSARC 2005/617 6. Extensible Attribute Interfaces PSARC 2007/315 7. "Secure by Default" Policy http://www.opensolaris.org/os/community/arc/policies/secure- by-default/ 8. "Install-Time Security" Policy http://www.opensolaris.org/os/community/arc/policies/ITS/ PSARC/2007/177 Copyright 2007 Sun Microsystems From gww@eng.sun.com Wed Aug 1 12:46:22 2007 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 l71JkMM6028017 for ; Wed, 1 Aug 2007 12:46:22 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l71Ji3ue012407; Wed, 1 Aug 2007 20:44:04 +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 <0JM4008031HGCD00@brm-avmta-1.central.sun.com>; Wed, 01 Aug 2007 13:44:04 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM40025Q1HFB7A0@brm-avmta-1.central.sun.com>; Wed, 01 Aug 2007 13:44:03 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l71Ji3Hh017520; Wed, 01 Aug 2007 12:44:03 -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 l71JlrPX017522; Wed, 01 Aug 2007 12:47:53 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l71Jlqu3017521; Wed, 01 Aug 2007 12:47:52 -0700 (PDT) Date: Wed, 01 Aug 2007 12:47:52 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Read-Protected Property Storage: 2nd draft opinion for review and vote To: PSARC-EXT@sun.com, sommerfeld@sun.com Cc: ahl@eng.sun.com, Keith.Wesolowski@sun.com, mws@sun.com Message-id: <200708011947.l71Jlqu3017521@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 800 At today's PSARC meeting, I asked for a minor change to TCR 2 to include the recommendations in 4.5 in the SMF Policy, which this case is already updating. The case owner ask me to propose the wording. > 7. Appendices > > 7.1. Appendix A: Technical Changes Required > 2. The recommendations in section 4.5 above must be > included in the smf_security(5) man page. 2. The recommendations in section 4.5 above must be included in both the smf_security(5) man page and the Service Management Facility Policy [9]. > 8. "Install-Time Security" Policy > http://www.opensolaris.org/os/community/arc/policies/ITS/ 9. "Service Management Facility (SMF)" Policy http://opensolaris.org/os/community/arc/policies/SMF-policy/ From gww@eng.sun.com Mon Aug 6 19:11:00 2007 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 l772Ax3p029995 for ; Mon, 6 Aug 2007 19:11:00 -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 l7728VUg010540; Tue, 7 Aug 2007 10:08: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 <0JMD00K09SMCC200@brm-avmta-1.central.sun.com>; Mon, 06 Aug 2007 20:08:36 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMD00GKOSMBU620@brm-avmta-1.central.sun.com>; Mon, 06 Aug 2007 20:08:35 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7728Y5i010120; Mon, 06 Aug 2007 19:08:34 -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 l772CWsD006502; Mon, 06 Aug 2007 19:12:32 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l772CWof006501; Mon, 06 Aug 2007 19:12:32 -0700 (PDT) Date: Mon, 06 Aug 2007 19:12:32 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2007/177 SMF Read-Protected Property Storage: 2nd draft opinion for review and vote To: PSARC-EXT@sun.com, sommerfeld@sun.com Cc: ahl@eng.sun.com, keith.wesolowski@sun.com, mws@sun.com Message-id: <200708070212.l772CWof006501@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 225 Bill, > This is the 2nd draft; I hope we can vote on this tomorrow. Point of order, the IAM says closed approved. Shouldn't it be waiting need opinion? I've not seen the opinion go through PSARC or SAC review. Gary.. From sommerfeld@sun.com Mon Aug 6 19:36:35 2007 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 l772aYIm001217 for ; Mon, 6 Aug 2007 19:36:35 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l772YBCR009856; Tue, 7 Aug 2007 03:34:13 +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 <0JMD00E05TT0LI00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Aug 2007 19:34:13 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMD00CL9TT0HJB0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Aug 2007 19:34:12 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l772YAlp010781; Mon, 06 Aug 2007 22:34:10 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l772YAq6019013; Mon, 06 Aug 2007 22:34:10 -0400 (EDT) Date: Mon, 06 Aug 2007 22:34:09 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/177 SMF Read-Protected Property Storage: 2nd draft opinion for review and vote In-reply-to: <200708070212.l772CWof006501@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC-EXT@sun.com, ahl@eng.sun.com, keith.wesolowski@sun.com, mws@sun.com Message-id: <1186454049.18708.2.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200708070212.l772CWof006501@marduk.eng.sun.com> Status: RO Content-Length: 294 On Mon, 2007-08-06 at 19:12 -0700, Gary Winiger wrote: > Bill, > > > This is the 2nd draft; I hope we can vote on this tomorrow. > > Point of order, the IAM says closed approved. I didn't edit the IAM file -- fixed. > Shouldn't it be waiting need opinion? Yes. - Bill