From sacadmin Tue Dec 9 14:59:40 2003 Date: Tue, 9 Dec 2003 14:53:17 -0800 (PST) From: Gary Winiger To: lsarc@sac.eng.sun.com Subject: PSARC/2002/762 Layered Trusted Solaris Cc: psarc@sac.eng.sun.com Content-Length: 952 Status: RO On behalf of the project team, I'd like to remind LSARC that you are invited to this review. It will be an overview of the Trusted Solaris 10 (X, next) project. The X, CDE and other GUI components are expected to be subcases reviewed by LSARC. The materials for the PSARC review on 17 Dec are in the case directory. http://sac.sfbay.sun.com/arc/PSARC/2002/762/inception.materials/ See http://sac.eng/cgi-bin/agenda?PSARC for the meeting agenda. PSARC/2002/762 -- Layered Trusted Solaris Manifest: Outline - this doc; a suggested starting point (outline.txt) 20 Questions -- 20Questions.txt Overview slides -- 24 pages (Overview.pdf) CDE overview slides -- 9 pages (CDE.pdf) Layered Trusted Solaris -- a work in process; the current snapshot of the project specification document (spec.pdf) CIPSO spec -- not printed reference for the interested (fips188.txt) Gary.. From sacadmin Tue Dec 16 16:13:27 2003 Date: Mon, 16 Dec 2002 16:09:37 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com Subject: Issue replies PSARC/2002/762 - Layered Trusted Solaris -- inception 12/17/2003 Cc: lsarc@sac.eng.sun.com, glenn.faden@sun.com Content-Length: 3415 Status: RO PSARC/2002/762 - Layered Trusted Solaris -- inception 12/17/2003 jdc-0 20q5: what is meant by conditional compilation here? Are we maintaining separate versions of the same binary (in contrast to 1991/061)? If so, why? This sounds like a patch delivery nightmare. Although the vast majority of the conditional logic will be implemented via runtime checks, there are a few programs that are either so extensively modified or have decreased performance that conditional compilation is more appropriate. Such programs will be delivered in unbundled packages, and will have unique names. For example, the TSOL version of dtwm will have a name like tsoldtwm or be delivered into /usr/dt/tsol/bin. Such programs will require their own patches, but we anticipate only a few such applications. jdc-1 Any new protocols (X Window System extensions) to be sent through external bodies? Probably not. This path has been tried with the Trusted Systems Interoperability Group (TSIG). It never came to closure. There was some general consensus on the functions needed, but none on the OTW format. For backward compatibiliity reasons we don't want to make any changes to these protocols. They are probably something like Sun or Committed Private as they currently pass binary labels in a format that is Sun-specific and they depend on features not available in any other OS. There is nothing to perclude future extensions that are controlled by external bodies. jdc-2 Do any policies or features of either Solaris Zones (2002/174) or Solaris Least Privilege (2002/188) need to change? If so, which ones and how? No kernel functional changes in privileges. In userland, we will define additional privileges for X protocol requests, and add privilege support to CDE actions. This may require expanding the number of privileges available. For Zones, we will be modifying some of the policy dealing with cross-zone communication. This will be done via runtime tests based on whether a TSOL policy module is loaded.We will also be adding a label attribute to the zones struct which will be used for mounting and networking policies. jdc-3 Are there any third party applications that depend on the existing TS8 behaviors? Yes, we are aware of a product from General Dynamics called Trusted Network Environment. We have presented our roadmap to them (twice). jdc-4 If I have both TS8 and TS10 systems, how do I keep the configurations synchronized? Since these systems cannot share the same name service, manual procedures will be required. jdc-5 How do labels, removable file systems, and backups interact? If files aren't labeled, how are accidents prevented in this area? If full pathnames are used, and backups are done from the global zone, the relationship between zone, label, and pathname is preserved. We are still researching this issue. jdc-6 Why are multilevel ports configured by interface? Why not as a per-process (or zone) privilege? Because we don't want trust labeled zones to set their own labeling policy. However, a privilege will be required to bind to a multilevel port. jdc-7 1.3.13: says NIS and DNS not supported. Why? Should say NIS and DNS will not be enhanced for TSOL. jdc-8 How are automounter-in-zone bits actually removed? There's only one file delivered Runtime checks will be made in the autofs code to check whether the TSOL kernel module is loaded. From sacadmin Wed Dec 17 11:23:23 2003 Date: Wed, 17 Dec 2003 11:18:30 -0800 (PST) From: Krishna Yenduri Subject: PSARC/2002/762 Layered Trusted Solaris To: psarc@sac.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: n90Xn+gHRm6VBRkecC1zfA== Content-Length: 167 Status: RO It seems a zone typically gets its IP address by using DHCP. So, do you restrict which IP address a zone can get (say based on the zone label)? -Krishna From sacadmin Wed Dec 17 11:25:53 2003 To: Krishna Yenduri cc: psarc@sac.eng.sun.com Subject: Re: PSARC/2002/762 Layered Trusted Solaris Date: Wed, 17 Dec 2003 20:21:32 +0100 From: Casper Dik Content-Length: 285 Status: RO > > It seems a zone typically gets its IP address by using DHCP. > So, do you restrict which IP address a zone can get (say > based on the zone label)? Actually, zones cannot use DHCP. The global zone's administrator is the only one who can set IP addresses in the zones. Casper From sacadmin Wed Dec 17 11:31:30 2003 Date: Wed, 17 Dec 2003 11:27:13 -0800 (PST) From: Kevin Song Subject: Re: PSARC/2002/762 Layered Trusted Solaris To: psarc@sac.eng.sun.com, krishna@bluesky.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mRO2YJirHOZAM2WIlItyFg== Content-Length: 393 Status: RO > > It seems a zone typically gets its IP address by using DHCP. > So, do you restrict which IP address a zone can get (say > based on the zone label)? Currently, global zone can get its IP by using DHCP, while non-global ones cannot. This scenerio is not a problem for TS as global will always have a default label and non-global zone lables are the real "interesting" ones. -Kevin From sacadmin Wed Dec 17 11:33:10 2003 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 17 Dec 2003 14:28:27 -0500 From: James Carlson To: Casper Dik Cc: Krishna Yenduri , psarc@sac.eng.sun.com Subject: Re: PSARC/2002/762 Layered Trusted Solaris Content-Length: 726 Status: RO Casper Dik writes: > > It seems a zone typically gets its IP address by using DHCP. > > So, do you restrict which IP address a zone can get (say > > based on the zone label)? > > > Actually, zones cannot use DHCP. The global zone's administrator > is the only one who can set IP addresses in the zones. True, though this general problem with DHCP (being unable to assign addresses to interface aliases) is something that will eventually be fixed. It's an issue that may have to be addressed then. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Dec 17 12:57:36 2003 Date: Wed, 17 Dec 2003 20:53:18 +0000 (GMT) From: Andrew Gabriel - Internet Engineering Subject: PSARC/2002/762 Layered Trusted Solaris To: psarc@sac.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YPCdtS19/MRmXXR0MB1JMA== Content-Length: 301 Status: RO Someone asked me a question at the beginning of the PSARC meeting about automount in zones -- I didn't clearly catch the question or who asked it. I assumed we would come back to this with issue gcs-1 but that didn't get covered. Perhaps whoever it was can raise the issue here? -- Andrew Gabriel From sacadmin Wed Dec 17 13:43:42 2003 Date: Sat, 27 Dec 2003 13:40:01 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com, krishna@bluesky.sfbay.sun.com Subject: Re: PSARC/2002/762 Layered Trusted Solaris Content-Length: 239 Status: RO Krishna et al, > It seems a zone typically gets its IP address by using DHCP. As there is no network design yet to discuss in front of the committee, please hold project discussions on the project alias not the PSARC alias. Gary.. From sacadmin Wed Dec 17 13:54:18 2003 Date: Sat, 27 Dec 2003 13:50:36 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com, Andrew.Gabriel@sun.com Subject: Re: PSARC/2002/762 Layered Trusted Solaris Content-Length: 190 Status: RO Andrew, > Someone asked me a question at the beginning of the PSARC meeting It was me. We'll deal with this off line. It was based on a discussion I had with Andy T yesterday. Gary.. From sacadmin Wed Mar 15 16:44:37 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.105]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2G0iaIQ013006; Wed, 15 Mar 2006 16:44:37 -0800 (PST) Received: from [129.146.109.11] (d-mpk17-109-11.SFBay.Sun.COM [129.146.109.11]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with ESMTP id k2G0iZB8991524; Wed, 15 Mar 2006 16:44:36 -0800 (PST) Message-ID: <4418B4CD.8020007@sun.com> Date: Wed, 15 Mar 2006 16:43:57 -0800 From: Glenn Faden User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20050718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: PSARC@sac.sfbay.sun.com, LSARC@sac.sfbay.sun.com CC: rampart-dev-team@sun.com, kathy.jenks@sun.com Subject: PSARC 2002/762 Layered Trusted Solaris Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3886 All of the cases described in this umbrella case have now been approved: TSNET: Trusted Networking with Security Labels (PSARC/2005/060) Layered Trusted Solaris Label Interfaces (PSARC/2005/259) Trusted Extensions for Printing (PSARC/2005/573) Trusted Extensions for Device Allocation (PSARC/2005/691) Solaris Trusted Extensions Filesystem Labeling (PSARC/2005/723) Trusted Solaris X Server Extension (LSARC/2004/109) Trusted Solaris CDE (LSARC/2005/075) Trusted Extensions for Solaris Management Console (2006/007) Trusted Extensions for Solaris Management Console (UIRB/2006/006) The project team would like to thank the reviewers and ask for final approval of this project. One issue that has come up is the question of how the new privileges introduced by several of these cases are installed. If fact, there is no installation procedure because these privileges are defined in the standard header files in the package SUNWhea. A question has been raised why the project team chose to bundle these privileges rather that use a dynamic runtime mechanism. This question makes an assumption that such a mechanism exists in Solaris that the project team could have used. In fact, there is no suitable mechanism. I have filed an RTI 6399150 Need a stable interface for adding privileges dynamically which describes some of the deficiencies of the existing support for dynamic privileges. However, the Trusted Extensions project is not really an unbundled product in the conventional sense. Over 90% of the code delivered by the project will be integrated into the WOS gates (ON, CDE, X, Admin) even though some of the packages produced in these consolidations will be delivered as part of the unbundled Trusted Extensions component. This tight integration with Solaris makes it inappropriate for this project to use a dynamic privilege extension mechanism. Nevertheless, in keeping with the spirit of producing a layered product the team first attempted to use a mechanism to define its privileges at run time. On the advice of Jim Carlson the effort was abandoned more than a year ago for the following reasons: 1. No fully supported unbundling mechanism exists. For example there is no unbundled interface for updating priv_names.h. 2. The list of default privileges in a zone is compiled into libzonecfg. So Trusted Extensions privileges needed to be compiled into libzonecfg, too. 3. The various commands that handle privilege strings fail if any of the privileges in the string are undefined. These causes a variety of failures when using commands like pfexec. It also causes adminstrative tools like the SMC to operate poorly. The GUI can't manage privileges that don't exist on the name server. 4. Because the kernel has only a limited amount of storage for dymamically added privileges to be allocated from, Trusted Extensions could not be reliably installed if someone else used up the available privilege space. 5. Although Trusted Extensions is a layered product, the vast majority of the code is integrated into existing Solaris packages. Some of this code checks TX privileges. For example, the privileges net_bindmlp, and net_mac_are checked by bundled kernel code. So the header files defining the privileges needed to be provided at compile time. When a suitable mechanism exists for adding privileges at runtime, PSARC may choose to require unbundled projects to use it, but for Trusted Extensions it is still more appropriate to bundle the privileges. Futhermore, it is not appropriate to require the Trusted Extensions project to provide mechansim for dynamic privileges. Again, I would like to thank the ARC members for their help and suggestions and appreciate one final review to complete this project. --Glenn From sacadmin Wed Mar 15 18:44:29 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2G2iTIQ022113 for ; Wed, 15 Mar 2006 18:44:29 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2G2ha2N017661; Wed, 15 Mar 2006 18:43:36 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2G2haGA017660; Wed, 15 Mar 2006 18:43:36 -0800 (PST) Date: Wed, 15 Mar 2006 18:43:36 -0800 (PST) From: Gary Winiger Message-Id: <200603160243.k2G2haGA017660@marduk.eng.sun.com> To: psarc@sac.eng.sun.com Subject: Converging 2002/762 Layered Trusted Solaris Cc: simon.gordon@marduk.eng.sun.com, casper.dik@sun.com, john.plochersun.com@marduk.eng.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 3054 Sigh, seems things got out of order. I've again been out sick and only working less than at full speed. I'd made Glenn and Simon aware of prior drafts of this, so now here it is: As case owner of PSARC/2002/762, the Trusted eXtensions (TX) umbrella case, I've been trying to converge it off line with the project team and have come upon what appears to be an architectural impasse. When this case was ``incepted'' on 17 December, 2003, it noted 8 sub-cases. A couple fast-tracks and one sub-case have since been added. 7 of the original sub-cases, the fast-tracks, and the added sub-case have been approved in ARC review. The 8th case described as "packaging, installation, and configuration changes: New and updated packages. Integration with Greenline and inetd. Configuring and booting labeled zones for TS10." has not yet been incepted. It's within that case that I believe an architectural issue would have surfaced. That issue is: 1. The TX project delivers an unbundled product. While this may be a marketing decision, it is still the message being given. 2. The TX project interprets privileges (PSARC/2002/188 Least Privilege for Solaris). 3. The privileges project was architected to provide for privileges being delivered from unbundled products. 4. The TX project team says it cannot deliver privileges unbundled from the Solaris WOS. Thus, if delivered bundled, all TX privileges are visible to all users and administrators. One might consider a precedent for this in that the arcitecture for delivering Solaris audit events does not cleanly lead to Solaris unbundled produces delivering audit independently of the Solaris WOS. 5. I interpret my correspondence with the 2002/188 privileges project team to say that the TX project can and should deliver privileges unbundled. The TX project team says that it started down the path of delivering privileges unbundled and found it didn't work. The privileges project team implies it should work. It's unclear to me and the privileges project team why it cannot work -- perhaps bugs or architectural deficiencies that the TX project team needs to ensure are fixed. A few possible resolutions are: 1. The TX project delivers privileges unbundled. 2. The TX project team, privileges project team, and PSARC agree that TX is special and cannot deliver privileges unbundled. And, this sets no precedence. 3. PSARC agrees that this project sets a precedence that allows any unbundled project (including 3rd party projects) to deliver privileges bundled with the Solaris WOS. I believe 2, 3 and perhaps other possible resolutions require materials, a vote and a more complete opinion than a summary. I've marked this case as waiting need spec. If other's believe this is not an architectural issue that needs to be address, I'll move on to closing this case as "closed approved summary" with a short opinion that summarizes the sub-cases, lists the packages and privileges. Thankx, Gary.. From sacadmin Wed Mar 15 18:46:04 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2G2k4IQ022235 for ; Wed, 15 Mar 2006 18:46:04 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2G2jBSh017674; Wed, 15 Mar 2006 18:45:11 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2G2jA89017673; Wed, 15 Mar 2006 18:45:10 -0800 (PST) Date: Wed, 15 Mar 2006 18:45:10 -0800 (PST) From: Gary Winiger Message-Id: <200603160245.k2G2jA89017673@marduk.eng.sun.com> To: psarc@sac.eng.sun.com Subject: Second try Converging 2002/762 Layered Trusted Solaris Cc: simon.gordon@marduk.eng.sun.com, casper.dik@sun.com, john.plocher@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 3089 This with John's address correct. Sigh, seems things got out of order. I've again been out sick and only working less than at full speed. I'd made Glenn and Simon aware of prior drafts of this, so now here it is: As case owner of PSARC/2002/762, the Trusted eXtensions (TX) umbrella case, I've been trying to converge it off line with the project team and have come upon what appears to be an architectural impasse. When this case was ``incepted'' on 17 December, 2003, it noted 8 sub-cases. A couple fast-tracks and one sub-case have since been added. 7 of the original sub-cases, the fast-tracks, and the added sub-case have been approved in ARC review. The 8th case described as "packaging, installation, and configuration changes: New and updated packages. Integration with Greenline and inetd. Configuring and booting labeled zones for TS10." has not yet been incepted. It's within that case that I believe an architectural issue would have surfaced. That issue is: 1. The TX project delivers an unbundled product. While this may be a marketing decision, it is still the message being given. 2. The TX project interprets privileges (PSARC/2002/188 Least Privilege for Solaris). 3. The privileges project was architected to provide for privileges being delivered from unbundled products. 4. The TX project team says it cannot deliver privileges unbundled from the Solaris WOS. Thus, if delivered bundled, all TX privileges are visible to all users and administrators. One might consider a precedent for this in that the arcitecture for delivering Solaris audit events does not cleanly lead to Solaris unbundled produces delivering audit independently of the Solaris WOS. 5. I interpret my correspondence with the 2002/188 privileges project team to say that the TX project can and should deliver privileges unbundled. The TX project team says that it started down the path of delivering privileges unbundled and found it didn't work. The privileges project team implies it should work. It's unclear to me and the privileges project team why it cannot work -- perhaps bugs or architectural deficiencies that the TX project team needs to ensure are fixed. A few possible resolutions are: 1. The TX project delivers privileges unbundled. 2. The TX project team, privileges project team, and PSARC agree that TX is special and cannot deliver privileges unbundled. And, this sets no precedence. 3. PSARC agrees that this project sets a precedence that allows any unbundled project (including 3rd party projects) to deliver privileges bundled with the Solaris WOS. I believe 2, 3 and perhaps other possible resolutions require materials, a vote and a more complete opinion than a summary. I've marked this case as waiting need spec. If other's believe this is not an architectural issue that needs to be address, I'll move on to closing this case as "closed approved summary" with a short opinion that summarizes the sub-cases, lists the packages and privileges. Thankx, Gary.. From sacadmin Wed Mar 15 18:46:58 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2G2kwIQ022261 for ; Wed, 15 Mar 2006 18:46:58 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2G2k5CA017682; Wed, 15 Mar 2006 18:46:05 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2G2k5Ex017681; Wed, 15 Mar 2006 18:46:05 -0800 (PST) Date: Wed, 15 Mar 2006 18:46:05 -0800 (PST) From: Gary Winiger Message-Id: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> To: psarc@sac.eng.sun.com Subject: Third try Converging 2002/762 Layered Trusted Solaris Cc: simon.gordon@sun.com, casper.dik@sun.com, john.plocher@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 3092 This with all addresses correct ;-) Sigh, seems things got out of order. I've again been out sick and only working less than at full speed. I'd made Glenn and Simon aware of prior drafts of this, so now here it is: As case owner of PSARC/2002/762, the Trusted eXtensions (TX) umbrella case, I've been trying to converge it off line with the project team and have come upon what appears to be an architectural impasse. When this case was ``incepted'' on 17 December, 2003, it noted 8 sub-cases. A couple fast-tracks and one sub-case have since been added. 7 of the original sub-cases, the fast-tracks, and the added sub-case have been approved in ARC review. The 8th case described as "packaging, installation, and configuration changes: New and updated packages. Integration with Greenline and inetd. Configuring and booting labeled zones for TS10." has not yet been incepted. It's within that case that I believe an architectural issue would have surfaced. That issue is: 1. The TX project delivers an unbundled product. While this may be a marketing decision, it is still the message being given. 2. The TX project interprets privileges (PSARC/2002/188 Least Privilege for Solaris). 3. The privileges project was architected to provide for privileges being delivered from unbundled products. 4. The TX project team says it cannot deliver privileges unbundled from the Solaris WOS. Thus, if delivered bundled, all TX privileges are visible to all users and administrators. One might consider a precedent for this in that the arcitecture for delivering Solaris audit events does not cleanly lead to Solaris unbundled produces delivering audit independently of the Solaris WOS. 5. I interpret my correspondence with the 2002/188 privileges project team to say that the TX project can and should deliver privileges unbundled. The TX project team says that it started down the path of delivering privileges unbundled and found it didn't work. The privileges project team implies it should work. It's unclear to me and the privileges project team why it cannot work -- perhaps bugs or architectural deficiencies that the TX project team needs to ensure are fixed. A few possible resolutions are: 1. The TX project delivers privileges unbundled. 2. The TX project team, privileges project team, and PSARC agree that TX is special and cannot deliver privileges unbundled. And, this sets no precedence. 3. PSARC agrees that this project sets a precedence that allows any unbundled project (including 3rd party projects) to deliver privileges bundled with the Solaris WOS. I believe 2, 3 and perhaps other possible resolutions require materials, a vote and a more complete opinion than a summary. I've marked this case as waiting need spec. If other's believe this is not an architectural issue that needs to be address, I'll move on to closing this case as "closed approved summary" with a short opinion that summarizes the sub-cases, lists the packages and privileges. Thankx, Gary.. From sacadmin Wed Mar 15 19:20:29 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2G3KTIQ022970 for ; Wed, 15 Mar 2006 19:20:29 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2G3KSEZ006147 for ; Wed, 15 Mar 2006 19:20:28 -0800 (PST) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2G3KS8u022938 for ; Wed, 15 Mar 2006 20:20:28 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IW700I01AFA5Y00@mail-amer.sun.com> (original mail from will.young@sun.com) for psarc@sac.sfbay.sun.com; Wed, 15 Mar 2006 20:20:28 -0700 (MST) Received: from [192.168.2.4] ([129.150.64.28]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IW7001NPAM24K32@mail-amer.sun.com>; Wed, 15 Mar 2006 20:20:27 -0700 (MST) Date: Wed, 15 Mar 2006 22:21:24 -0500 From: will young Subject: Re: Converging 2002/762 Layered Trusted Solaris In-reply-to: <200603160243.k2G2haGA017660@marduk.eng.sun.com> Sender: William.Young@sun.com To: Gary Winiger Cc: psarc@sac.sfbay.sun.com, simon.gordon@marduk.eng.sun.com, casper.dik@sun.com, john.plochersun.com@marduk.eng.sun.com Message-id: <4418D9B4.2000405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200603160243.k2G2haGA017660@marduk.eng.sun.com> User-Agent: Mail/News 1.5 (X11/20060217) Status: RO Content-Length: 1693 Gary Winiger wrote: ... > > A few possible resolutions are: > 1. The TX project delivers privileges unbundled. > 2. The TX project team, privileges project team, and PSARC agree > that TX is special and cannot deliver privileges unbundled. > And, this sets no precedence. > 3. PSARC agrees that this project sets a precedence that allows > any unbundled project (including 3rd party projects) to > deliver privileges bundled with the Solaris WOS. I would like to suggest a fourth alternative (or really an extension to (2)): I feel solaris should deliver an interface for products to reserve a set of privilege or audit numbers on a running system. The product can request the number it needs and will dynamically be allocated such a chunk and returned the first of the sequence or an error if the requested number of privilege/events exceeds availability. In the case of auditing the system will need to record the identifier supplied by the requestor of the audit event numbers and the relative offset rather than simply the audit event number. In the interim, I suggest TX should be allowed to assume a space above current solaris privilege/event numbers as in (2) until such an API is available. Thanks, -Will > > I believe 2, 3 and perhaps other possible resolutions require materials, > a vote and a more complete opinion than a summary. > > I've marked this case as waiting need spec. If other's believe this is > not an architectural issue that needs to be address, I'll move on to > closing this case as "closed approved summary" with a short opinion that > summarizes the sub-cases, lists the packages and privileges. > > Thankx, > Gary.. > From sacadmin Wed Mar 15 19:52:19 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2G3qJIQ023277 for ; Wed, 15 Mar 2006 19:52:19 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2G3qGJv014824; Wed, 15 Mar 2006 19:52:16 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2G3pO8A017827; Wed, 15 Mar 2006 19:51:24 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2G3pObO017826; Wed, 15 Mar 2006 19:51:24 -0800 (PST) Date: Wed, 15 Mar 2006 19:51:24 -0800 (PST) From: Gary Winiger Message-Id: <200603160351.k2G3pObO017826@marduk.eng.sun.com> To: gww@eng.sun.com, will.young@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris Cc: psarc@sac.sfbay.sun.com, simon.gordon@sun.com, casper.dik@sun.com, john.plocher@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 2511 Reply was to miss-addressed message, I've fixed the addresses, but am keeping all the message for context of those who didn't see it. > > A few possible resolutions are: > > 1. The TX project delivers privileges unbundled. > > 2. The TX project team, privileges project team, and PSARC agree > > that TX is special and cannot deliver privileges unbundled. > > And, this sets no precedence. > > 3. PSARC agrees that this project sets a precedence that allows > > any unbundled project (including 3rd party projects) to > > deliver privileges bundled with the Solaris WOS. > I would like to suggest a fourth alternative (or really an extension to > (2)): > I feel solaris should deliver an interface for products to reserve a > set of privilege or audit numbers on a running system. Actually the privileges case has indeed done that. The crux of this thread is that for some reasons that it doesn't seem Glenn and Casper agree about, TX can't use that. The privileges case was architected to allow dynamic addition of privileges to Solaris. The audit project has a reserved name space for unbundled and 3rd parties. > The product can > request the number it needs and will dynamically be allocated such a > chunk and returned the first of the sequence or an error if the > requested number of privilege/events exceeds availability. I believe both privileges and audit work that way. > In the case of auditing the system will need to record the identifier > supplied by the requestor of the audit event numbers and the relative > offset rather than simply the audit event number. The name space is reserved as I said above. However, there is neither a registry or current way to deliver into that name space except through ON or editing the various delivered audit database files. However, editing doesn't provide for a registry. In audit, it's not pretty. Making it worse is the lack of convenient audit generation interfaces for projects. Fortunately, that's not this project. > In the interim, I suggest TX should be allowed to assume a space above > current solaris privilege/event numbers as in (2) until such an API is > available. Audit isn't the TX issue. That was covered in 2006/009. Privileges seem to be the place lacking convergence. The point of this thread is to converge the case -- indeed 2 may be the right convergence. That still leave me to believe that materials, vote and more complete opinion are necessary. Gary.. From sacadmin Fri Mar 17 15:52:22 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2HNqLIQ005175 for ; Fri, 17 Mar 2006 15:52:22 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2HNqJEZ004847; Fri, 17 Mar 2006 15:52:19 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k2HNqI503830; Fri, 17 Mar 2006 15:52:18 -0800 (PST) Message-ID: <441B4BB2.8080603@sun.com> Date: Fri, 17 Mar 2006 15:52:18 -0800 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.eng.sun.com, simon.gordon@sun.com, casper.dik@sun.com, john.plocher@sun.com, glenn.faden@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> In-Reply-To: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4464 Gary Winiger wrote: > This with all addresses correct ;-) > > Sigh, seems things got out of order. I've again been out sick and only > working less than at full speed. I'd made Glenn and Simon aware of prior > drafts of this, so now here it is: > > As case owner of PSARC/2002/762, the Trusted eXtensions (TX) umbrella case, > I've been trying to converge it off line with the project team and have come > upon what appears to be an architectural impasse. When this case was > ``incepted'' on 17 December, 2003, it noted 8 sub-cases. A couple fast-tracks > and one sub-case have since been added. 7 of the original sub-cases, the > fast-tracks, and the added sub-case have been approved in ARC review. The > 8th case described as > "packaging, installation, and configuration changes: > New and updated packages. Integration with Greenline and inetd. > Configuring and booting labeled zones for TS10." > has not yet been incepted. It's within that case that I believe an > architectural issue would have surfaced. > > That issue is: > 1. The TX project delivers an unbundled product. > While this may be a marketing decision, it is still the > message being given. > 2. The TX project interprets privileges (PSARC/2002/188 Least > Privilege for Solaris). > 3. The privileges project was architected to provide for privileges > being delivered from unbundled products. > 4. The TX project team says it cannot deliver privileges unbundled > from the Solaris WOS. Thus, if delivered bundled, all TX > privileges are visible to all users and administrators. > One might consider a precedent for this in that the > arcitecture for delivering Solaris audit events does not cleanly > lead to Solaris unbundled produces delivering audit independently > of the Solaris WOS. > 5. I interpret my correspondence with the 2002/188 privileges > project team to say that the TX project can and should deliver > privileges unbundled. > > The TX project team says that it started down the path of delivering > privileges unbundled and found it didn't work. The privileges project team > implies it should work. It's unclear to me and the privileges project team > why it cannot work -- perhaps bugs or architectural deficiencies that the TX > project team needs to ensure are fixed. > > A few possible resolutions are: > 1. The TX project delivers privileges unbundled. > 2. The TX project team, privileges project team, and PSARC agree > that TX is special and cannot deliver privileges unbundled. > And, this sets no precedence. > 3. PSARC agrees that this project sets a precedence that allows > any unbundled project (including 3rd party projects) to > deliver privileges bundled with the Solaris WOS. > > I believe 2, 3 and perhaps other possible resolutions require materials, > a vote and a more complete opinion than a summary. > > I've marked this case as waiting need spec. If other's believe this is > not an architectural issue that needs to be address, I'll move on to > closing this case as "closed approved summary" with a short opinion that > summarizes the sub-cases, lists the packages and privileges. > > Thankx, > Gary.. I'm not a member of the Trusted Extensions project team, but I have a fairly detailed understanding of that project and also the Solaris privilege mechanism delivered by PSARC 2002/188. With that background, I have the following observation. My initial expectation was that Trusted Extensions would make use of the mechanism provided for unbundled components to add privileges dynamically rather than including them in the Solaris WOS. However, the actual design for Trusted Extensions approved by the ARC cases under this umbrella is such that the use of the additional privileges is not confined to the unbundled product. Instead, the enforcement code that references these privileges is included in Solaris itself but only executed when the unbundled product is installed and active. This situation is clearly quite different from the cleanly unbundled privileges that the Solaris privilege mechanism was designed to support. I suspect that it is not feasible for Trusted Extensions to avoid adding its privileges directly in the Solaris WOS, though that reasoning would not extend to privileges added by more typical unbundled products. I think that's pretty close to Gary's resolution #2 above. Scott From sacadmin Mon Mar 20 17:15:01 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2L1F1IQ028288 for ; Mon, 20 Mar 2006 17:15:01 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2L1EUYi010508; Tue, 21 Mar 2006 01:14:30 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2L1EUxr010507; Mon, 20 Mar 2006 20:14:30 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Converging 2002/762 Layered Trusted Solaris From: Bill Sommerfeld To: Scott Rotondo Cc: Gary Winiger , psarc@sac.eng.sun.com, Simon.Gordon@sun.com, Casper.Dik@sun.com, John.Plocher@sun.com, Glenn.Faden@sun.com In-Reply-To: <441B4BB2.8080603@sun.com> References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1142903670.10497.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Mon, 20 Mar 2006 20:14:30 -0500 Status: RO Content-Length: 830 On Fri, 2006-03-17 at 18:52, Scott Rotondo wrote: > This situation is clearly quite different from the cleanly unbundled > privileges that the Solaris privilege mechanism was designed to support. > I suspect that it is not feasible for Trusted Extensions to avoid adding > its privileges directly in the Solaris WOS, though that reasoning would > not extend to privileges added by more typical unbundled products. I > think that's pretty close to Gary's resolution #2 above. That sounds like a reasonable resolution. The precedent set here would be fairly narrow: when an unbundled component requires latent privilege-aware support bundled in the WOS, then it makes sense that those privileges can also be bundled as part of the WOS -- even if no actual use is made of them without the unbundled component. - Bill From sacadmin Tue Mar 21 07:15:20 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LFFJIQ017033 for ; Tue, 21 Mar 2006 07:15:20 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2LFF8CM017795; Tue, 21 Mar 2006 16:15:08 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2LFF7Dk020761; Tue, 21 Mar 2006 16:15:07 +0100 (MET) Message-Id: <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Scott Rotondo cc: Gary Winiger , psarc@sac.eng.sun.com, Simon.Gordon@Sun.COM, John.Plocher@Sun.COM, Glenn.Faden@Sun.COM Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <441B4BB2.8080603@sun.com> References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> Date: Tue, 21 Mar 2006 16:15:07 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 2071 >My initial expectation was that Trusted Extensions would make use of the >mechanism provided for unbundled components to add privileges >dynamically rather than including them in the Solaris WOS. However, the >actual design for Trusted Extensions approved by the ARC cases under >this umbrella is such that the use of the additional privileges is not >confined to the unbundled product. Instead, the enforcement code that >references these privileges is included in Solaris itself but only >executed when the unbundled product is installed and active. Is that a correct observation? If so, why is that? >This situation is clearly quite different from the cleanly unbundled >privileges that the Solaris privilege mechanism was designed to support. >I suspect that it is not feasible for Trusted Extensions to avoid adding >its privileges directly in the Solaris WOS, though that reasoning would >not extend to privileges added by more typical unbundled products. I >think that's pretty close to Gary's resolution #2 above. While the original privilege case should perhaps have delivered a more complete mechanism for unbundled privileges, it is hard to see how to develop such a mechanism without knowing all the requirements of the future consumers. Integrating a component without such clear consumers is also difficult. I still prefer the TX privileges to be unbundled; even if that means that the Layered TX project needs to make changes to Solaris to more cleanly support this. Some of the issues: - it seems logical that unbundled products use their own include files e.g., file. - the priv_names text file requires some thought and edit scripts - there is a failure mode: there may not be sufficien privilege slots; this is something which can be determined at product install time. Having the trusted privileges present in ordinary Solaris is bad for two reasons: - it is confusing to users and administrators - it may lead to customers usurping the "unused" privileges for other purposes. Casper From sacadmin Tue Mar 21 10:31:17 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LIVHIQ028718 for ; Tue, 21 Mar 2006 10:31:17 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2LIVEEZ007593; Tue, 21 Mar 2006 10:31:14 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k2LIVE526038; Tue, 21 Mar 2006 10:31:14 -0800 (PST) Message-ID: <44204671.7040906@sun.com> Date: Tue, 21 Mar 2006 10:31:13 -0800 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Gary Winiger , psarc@sac.eng.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Glenn.Faden@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> In-Reply-To: <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3172 Casper.Dik@Sun.COM wrote: >>My initial expectation was that Trusted Extensions would make use of the >>mechanism provided for unbundled components to add privileges >>dynamically rather than including them in the Solaris WOS. However, the >>actual design for Trusted Extensions approved by the ARC cases under >>this umbrella is such that the use of the additional privileges is not >>confined to the unbundled product. Instead, the enforcement code that >>references these privileges is included in Solaris itself but only >>executed when the unbundled product is installed and active. > > > Is that a correct observation? If so, why is that? The Trusted Extensions team would have to answer the "why" question, but yes it does work that way. > > >>This situation is clearly quite different from the cleanly unbundled >>privileges that the Solaris privilege mechanism was designed to support. >>I suspect that it is not feasible for Trusted Extensions to avoid adding >>its privileges directly in the Solaris WOS, though that reasoning would >>not extend to privileges added by more typical unbundled products. I >>think that's pretty close to Gary's resolution #2 above. > > > While the original privilege case should perhaps have delivered a > more complete mechanism for unbundled privileges, it is hard to see > how to develop such a mechanism without knowing all the requirements > of the future consumers. Integrating a component without such clear > consumers is also difficult. > > I still prefer the TX privileges to be unbundled; even if that means > that the Layered TX project needs to make changes to Solaris to more > cleanly support this. > > Some of the issues: > > - it seems logical that unbundled products use their > own include files e.g., file. > > - the priv_names text file requires some thought and edit > scripts > > - there is a failure mode: there may not be sufficien privilege > slots; this is something which can be determined at product > install time. > > Having the trusted privileges present in ordinary Solaris is bad > for two reasons: > > - it is confusing to users and administrators > - it may lead to customers usurping the "unused" privileges > for other purposes. I basically agree with you. I would prefer that the Trusted Extensions privileges were unbundled, and I believe it could have been designed to work that way. Furthermore, this would have been an excellent opportunity to verify the completeness of the mechanism for unbundled privileges and correct any shortcomings. However, it didn't happen that way. Trusted Extensions was designed, implemented, and ARC reviewed without that requirement. It's abundantly clear that the business need to ship Trusted Extensions won't permit a fundamental redesign at this late stage in the project. So given where we are today, I'm suggesting that the best way to meet both the technical and business requirements is to allow Trusted Extensions to bundle its privileges but make it clear that this does not set a precedent allowing more conventional unbundled products to do the same. Scott From sacadmin Tue Mar 21 10:44:15 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LIiEIQ005110 for ; Tue, 21 Mar 2006 10:44:15 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2LIi5CM003900; Tue, 21 Mar 2006 19:44:05 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2LIi4Dk001563; Tue, 21 Mar 2006 19:44:04 +0100 (MET) Message-Id: <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Scott Rotondo cc: Gary Winiger , psarc@sac.eng.sun.com, Simon.Gordon@Sun.COM, John.Plocher@Sun.COM, Glenn.Faden@Sun.COM Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <44204671.7040906@sun.com> References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> Date: Tue, 21 Mar 2006 19:44:04 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 927 >However, it didn't happen that way. Trusted Extensions was designed, >implemented, and ARC reviewed without that requirement. It's abundantly >clear that the business need to ship Trusted Extensions won't permit a >fundamental redesign at this late stage in the project. >So given where we are today, I'm suggesting that the best way to meet >both the technical and business requirements is to allow Trusted >Extensions to bundle its privileges but make it clear that this does not >set a precedent allowing more conventional unbundled products to do the >same. So why is there no TCA or TCR for the next release? We should fix this for Nevada; in future this will only become more and more problematic. I was under the impression that this was still fixable for the initial layered TX release; but apparently not so. The risks of having them as ineffective privileges in Solaris proper is just to great. Casper From sacadmin Tue Mar 21 11:01:44 2006 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJ1iIQ025316 for ; Tue, 21 Mar 2006 11:01:44 -0800 (PST) Received: from [129.146.11.190] (sr1-umpk-14.SFBay.Sun.COM [129.146.11.190]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k2LJ1h526809; Tue, 21 Mar 2006 11:01:43 -0800 (PST) Message-ID: <44204D96.5060101@sun.com> Date: Tue, 21 Mar 2006 11:01:42 -0800 From: Lokanath Das User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Scott Rotondo , Gary Winiger , psarc@sac.sfbay.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Glenn.Faden@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> In-Reply-To: <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1240 One of the compelling reason to leave these privileges in Solaris is to allow future sedimentation of Trusted Extensions features into Solaris, particularly in the area of X server policy enforcement to support a more secure JDS. -Lokanath Casper.Dik@sun.com wrote: >>However, it didn't happen that way. Trusted Extensions was designed, >>implemented, and ARC reviewed without that requirement. It's abundantly >>clear that the business need to ship Trusted Extensions won't permit a >>fundamental redesign at this late stage in the project. > > >>So given where we are today, I'm suggesting that the best way to meet >>both the technical and business requirements is to allow Trusted >>Extensions to bundle its privileges but make it clear that this does not >>set a precedent allowing more conventional unbundled products to do the >>same. > > > So why is there no TCA or TCR for the next release? > > We should fix this for Nevada; in future this will only become more > and more problematic. > > I was under the impression that this was still fixable for the > initial layered TX release; but apparently not so. > > The risks of having them as ineffective privileges in Solaris proper > is just to great. > > Casper > From sacadmin Tue Mar 21 11:07:18 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJ7HIQ028344 for ; Tue, 21 Mar 2006 11:07:17 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2LJ72CM009771; Tue, 21 Mar 2006 20:07:02 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2LJ72Dk002174; Tue, 21 Mar 2006 20:07:02 +0100 (MET) Message-Id: <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Lokanath Das cc: Scott Rotondo , Gary Winiger , psarc@sac.sfbay.sun.com, Simon.Gordon@Sun.COM, John.Plocher@Sun.COM, Glenn.Faden@Sun.COM Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <44204D96.5060101@sun.com> References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> <44204D96.5060101@sun.com> Date: Tue, 21 Mar 2006 20:07:02 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 381 >One of the compelling reason to leave these privileges >in Solaris is to allow future sedimentation of Trusted >Extensions features into Solaris, particularly in the >area of X server policy enforcement to support a more >secure JDS. Just like Disksuite couldn't be bundled into Solaris because it was an unbundled product first? Doesn't strike me as a valid argument. Casper From sacadmin Tue Mar 21 11:17:00 2006 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJH0IQ028665 for ; Tue, 21 Mar 2006 11:17:00 -0800 (PST) Received: from [129.146.11.190] (sr1-umpk-14.SFBay.Sun.COM [129.146.11.190]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k2LJGw527130; Tue, 21 Mar 2006 11:16:58 -0800 (PST) Message-ID: <4420512A.4000303@sun.com> Date: Tue, 21 Mar 2006 11:16:58 -0800 From: Lokanath Das User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Scott Rotondo , Gary Winiger , psarc@sac.sfbay.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Glenn.Faden@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> <44204D96.5060101@sun.com> <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> In-Reply-To: <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 706 Casper.Dik@Sun.COM wrote: >>One of the compelling reason to leave these privileges >>in Solaris is to allow future sedimentation of Trusted >>Extensions features into Solaris, particularly in the >>area of X server policy enforcement to support a more >>secure JDS. > > > Just like Disksuite couldn't be bundled into Solaris because > it was an unbundled product first? > > Doesn't strike me as a valid argument. I did not suggest it can't be done. We need to spend more money (resources) first unbundling these privileges, then spend more money in puting it back. Doesn't sound like good use of company money (resources) when we are not making a whole lot of it these days. -Lokanath > > Casper From sacadmin Tue Mar 21 11:24:54 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJOrIQ028763 for ; Tue, 21 Mar 2006 11:24:54 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2LJOhCM013299; Tue, 21 Mar 2006 20:24:43 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2LJOhDk002801; Tue, 21 Mar 2006 20:24:43 +0100 (MET) Message-Id: <200603211924.k2LJOhDk002801@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Lokanath Das cc: Scott Rotondo , Gary Winiger , psarc@sac.sfbay.sun.com, Simon.Gordon@Sun.COM, John.Plocher@Sun.COM, Glenn.Faden@Sun.COM Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <4420512A.4000303@sun.com> References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> <44204D96.5060101@sun.com> <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> <4420512A.4000303@sun.com> Date: Tue, 21 Mar 2006 20:24:43 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 512 >I did not suggest it can't be done. We need to spend >more money (resources) first unbundling these >privileges, then spend more money in puting it back. > >Doesn't sound like good use of company money (resources) >when we are not making a whole lot of it these days. I'd rather spend that (little bit) of money than dealing with the escalations resulting from people misappropriating the privileges which were there but weren't used and the costs of answering support calls about unused privileges. Casper From sacadmin Tue Mar 21 11:27:46 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJRkIQ028966 for ; Tue, 21 Mar 2006 11:27:46 -0800 (PST) Received: from [192.168.0.6] (vpn-129-150-20-123.SFBay.Sun.COM [129.150.20.123]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with ESMTP id k2LJRhNM662779; Tue, 21 Mar 2006 11:27:44 -0800 (PST) Message-ID: <44205355.30803@sun.com> Date: Tue, 21 Mar 2006 11:26:13 -0800 From: Glenn Faden User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20051122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Lokanath Das , Scott Rotondo , Gary Winiger , psarc@sac.sfbay.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> <44204D96.5060101@sun.com> <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> In-Reply-To: <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1256 Casper, Some of the new privileges that are introduced in this project are checked by bundled kernel components but the tests are within logic that tests for is_system_labeled(). These clearly are not suitable for unbundling. The remaining X server-related privileges are used by code in the X, CDE and JDS gates. In addition they may appear in RBAC entries stored in LDAP databases. As these privileges apply to X clients running in non-global zone, they should be listed in the new configurable zone privilege sets maintainted in libzonecfg, so these privileges will be used in ON, as well. The notion that Rampart is an unbundled product is a bit of a marketing illusion. We are adding or modifying over 100,000 lines of code in the WOS. This is Solaris. Unbundling these privileges is not appropriate. --Glenn Casper.Dik@Sun.COM wrote: >>One of the compelling reason to leave these privileges >>in Solaris is to allow future sedimentation of Trusted >>Extensions features into Solaris, particularly in the >>area of X server policy enforcement to support a more >>secure JDS. >> >> > >Just like Disksuite couldn't be bundled into Solaris because >it was an unbundled product first? > >Doesn't strike me as a valid argument. > >Casper > > From sacadmin Tue Mar 21 11:46:11 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LJkBIQ029635 for ; Tue, 21 Mar 2006 11:46:11 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2LJk59p682551; Tue, 21 Mar 2006 11:46:10 -0800 (PST) Message-Id: <200603211946.k2LJk59p682551@jurassic.eng.sun.com> Date: Tue, 21 Mar 2006 09:44:34 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Converging 2002/762 Layered Trusted Solaris To: Scott.Rotondo@sun.com, Casper.Dik@sun.com Cc: gww@eng.sun.com, psarc@sac.eng.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Glenn.Faden@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xILUNCs8WZXaXLoV6ZMvXA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 185 > From: Casper.Dik@sun.com ... > So why is there no TCA or TCR for the next release? Nit: Because that would be a syntax error. So why is there no strongly worded Advisory? - jek3 From sacadmin Tue Mar 21 12:03:44 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LK3iIQ000980 for ; Tue, 21 Mar 2006 12:03:44 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2LK2iVr028999; Tue, 21 Mar 2006 12:02:44 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2LK2iZj028998; Tue, 21 Mar 2006 12:02:44 -0800 (PST) Date: Tue, 21 Mar 2006 12:02:44 -0800 (PST) From: Gary Winiger Message-Id: <200603212002.k2LK2iZj028998@marduk.eng.sun.com> To: Scott.Rotondo@sun.com, Casper.Dik@sun.com, Joseph.Kowalski@eng.sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris Cc: gww@eng.sun.com, psarc@sac.eng.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Glenn.Faden@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 367 > > From: Casper.Dik@sun.com > ... > > So why is there no TCA or TCR for the next release? > > Nit: Because that would be a syntax error. So why is there no strongly > worded Advisory? IMO realistically either there is a TCR now, or it will never happen. That's why I've been trying to get the TX team to talk with the Privileges team for a while now. Gary.. From sacadmin Tue Mar 21 12:16:20 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LKGJIQ001379 for ; Tue, 21 Mar 2006 12:16:20 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IWH00801UN7DF@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for psarc@sac.eng.sun.com; Tue, 21 Mar 2006 12:16:19 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-20-72.SFBay.Sun.COM [129.150.20.72]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IWH0062WUYWG6@mpk-mail1.sfbay.sun.com>; Tue, 21 Mar 2006 12:16:09 -0800 (PST) Date: Tue, 21 Mar 2006 12:16:08 -0800 From: Ed Gould Subject: Re: Converging 2002/762 Layered Trusted Solaris In-reply-to: <200603212002.k2LK2iZj028998@marduk.eng.sun.com> To: Gary Winiger Cc: psarc@sac.eng.sun.com, Casper.Dik@Sun.COM, Simon.Gordon@Sun.COM, John.Plocher@Sun.COM, Glenn.Faden@Sun.COM, Scott.Rotondo@Sun.COM, Joseph.Kowalski@Sun.COM Message-id: MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200603212002.k2LK2iZj028998@marduk.eng.sun.com> Status: RO Content-Length: 1102 On Mar 21, 2006, at 12:02, Gary Winiger wrote: >>> From: Casper.Dik@sun.com >> ... >>> So why is there no TCA or TCR for the next release? >> >> Nit: Because that would be a syntax error. So why is there no >> strongly >> worded Advisory? > > IMO realistically either there is a TCR now, or it will never > happen. That's why I've been trying to get the TX team to talk > with the Privileges team for a while now. It sounds to me, largely based on Glenn's comments, that the issue here is a misunderstanding about the degree to which TX is unbundled. If I understand Glenn correctly, the reason the privileges are bundled is (for most of them, at least) that the software that uses them is also bundled. Whether there are also privileges that are used only by unbundled software that should not be bundled is not clear to me. It looks like one if the issues muddying this is X. If I understand correctly, unbundling the permissions needed by the X server would require 3-way coordination, not just 2-way (between TX and ON). This seems like a train wreck worth avoiding. --Ed From sacadmin Tue Mar 21 12:34:36 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LKYZIQ001691 for ; Tue, 21 Mar 2006 12:34:36 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2LKY3jS011910; Tue, 21 Mar 2006 20:34:04 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2LKY3Hp011909; Tue, 21 Mar 2006 15:34:03 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Converging 2002/762 Layered Trusted Solaris From: Bill Sommerfeld To: Glenn Faden Cc: Casper.Dik@sun.com, Lokanath Das , Scott Rotondo , Gary Winiger , psarc@sac.sfbay.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com In-Reply-To: <44205355.30803@sun.com> References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> <44204D96.5060101@sun.com> <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> <44205355.30803@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1142973243.10497.1120.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Tue, 21 Mar 2006 15:34:03 -0500 Status: RO Content-Length: 681 On Tue, 2006-03-21 at 14:26, Glenn Faden wrote: > As these privileges apply to X clients running in non-global > zone, they should be listed in the new configurable zone > privilege sets maintainted in libzonecfg, so these privileges > will be used in ON, as well. I'd hope that configurable zone privileges support could handle privileges added by an unbundled component. If that's not a case, it's a serious limitation on configurable zone privileges... but that may be irrelevant to Rampart as I think the key issue is: > The notion that Rampart is an unbundled product is a > bit of a marketing illusion. We are adding or modifying > over 100,000 lines of code in the WOS. From sacadmin Tue Mar 21 12:41:01 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LKf1IQ001987 for ; Tue, 21 Mar 2006 12:41:01 -0800 (PST) Received: from [192.168.0.6] (vpn-129-150-20-123.SFBay.Sun.COM [129.150.20.123]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with ESMTP id k2LKewOv722534; Tue, 21 Mar 2006 12:41:00 -0800 (PST) Message-ID: <44206480.2040309@sun.com> Date: Tue, 21 Mar 2006 12:39:28 -0800 From: Glenn Faden User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20051122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Gould CC: Gary Winiger , psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com, Joseph.Kowalski@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603212002.k2LK2iZj028998@marduk.eng.sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1563 Ed Gould wrote: > > > It sounds to me, largely based on Glenn's comments, that the issue > here is a misunderstanding about the degree to which TX is unbundled. > If I understand Glenn correctly, the reason the privileges are bundled > is (for most of them, at least) that the software that uses them is > also bundled. Yes, all but the X windows privileges are used in bundled kernel modules. > > Whether there are also privileges that are used only by unbundled > software that should not be bundled is not clear to me. It looks like > one if the issues muddying this is X. If I understand correctly, > unbundling the permissions needed by the X server would require 3-way > coordination, not just 2-way (between TX and ON). This seems like a > train wreck worth avoiding. It may be more that 3-way coordination, since the privileges are currently used in Xsun, Xorg, CDE, and JDS. Also third party developers (ISVs) will surely be using them, too. They always did in previous versions of Trusted Solaris. Now that configurable zone privileges has integrated into Nevada, I'm inclined to add these X window privileges to the appropriate safe, required, and default privileges sets which are hard-coded in libzonecfg. Doing so would make ON both a consumer and supplier of these privileges and render the unbundling issue moot. Note that the configurable zone privileges case doesn't require that it knows about all possible privileges, but it attempts to help the user avoid mistakes by sorting privileges into these sets. --Glenn From sacadmin Tue Mar 21 16:38:14 2006 Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2M0cDIQ018519 for ; Tue, 21 Mar 2006 16:38:13 -0800 (PST) Received: from izimbra.SFBay.Sun.COM (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2M0cDrK102239; Tue, 21 Mar 2006 16:38:13 -0800 (PST) Received: (from comay@localhost) by izimbra.SFBay.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2M0cBfA102238; Tue, 21 Mar 2006 16:38:11 -0800 (PST) Date: Tue, 21 Mar 2006 16:38:11 -0800 (PST) From: David Comay Message-Id: <200603220038.k2M0cBfA102238@izimbra.SFBay.Sun.COM> To: Glenn.Faden@sun.com, sommerfeld@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris Cc: Casper.Dik@sun.com, John.Plocher@sun.com, Lokanath.Das@sun.com, Scott.Rotondo@sun.com, Simon.Gordon@sun.com, gww@eng.sun.com, psarc@sac.sfbay.sun.com Status: RO Content-Length: 573 > I'd hope that configurable zone privileges support could handle > privileges added by an unbundled component. If that's not a case, it's > a serious limitation on configurable zone privileges... Yes, the configurable zone privilege support does "understand" privileges added by an unbundled product in that it relies on priv_str_to_set(3C) and ultimately the kernel to determine if the privilege is valid or not. As long as that privilege name is understood by the underlying system, then it can be included in the "limitpriv" property maintained by zonecfg(1M). dsc From sacadmin Tue Mar 21 18:56:35 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2M2uYIQ022164 for ; Tue, 21 Mar 2006 18:56:35 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2M2uObB005234; Tue, 21 Mar 2006 21:56:24 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2M2uN96018758; Tue, 21 Mar 2006 21:56:23 -0500 (EST) Subject: Re: Converging 2002/762 Layered Trusted Solaris From: Bill Sommerfeld To: Glenn Faden Cc: Ed Gould , Gary Winiger , psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com, "Joseph E. Kowalski, III" In-Reply-To: <44206480.2040309@sun.com> References: <200603212002.k2LK2iZj028998@marduk.eng.sun.com> <44206480.2040309@sun.com> Content-Type: text/plain Message-Id: <1142996183.17801.112.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Tue, 21 Mar 2006 21:56:23 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 839 On Tue, 2006-03-21 at 15:39, Glenn Faden wrote: > Now that configurable zone privileges has integrated into Nevada, I'm > inclined to add these X window privileges to the appropriate safe, > required, and default privileges sets which are hard-coded in > libzonecfg. it appears that libzonecfg has hardcoded "required", "default", and "prohibited" lists; the "default" list is described as the privileges which are "safe" for use in a zone. "required" has a very narrow definition: "required in order to get a zone booted and init(1m) started". omission from the other two lists means that they won't appear by default but will be allowed if you ask for them. For full flexibility of unbundled privileges it seems we'd need a mechanism to allow unbundled privileges to be marked either default/safe or prohibited. - Bill From sacadmin Tue Mar 21 21:03:00 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2M530IQ024784 for ; Tue, 21 Mar 2006 21:03:00 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2M52qJv017504; Tue, 21 Mar 2006 21:02:52 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2M51r1L000475; Tue, 21 Mar 2006 21:01:53 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2M51rnv000474; Tue, 21 Mar 2006 21:01:53 -0800 (PST) Date: Tue, 21 Mar 2006 21:01:53 -0800 (PST) From: Gary Winiger Message-Id: <200603220501.k2M51rnv000474@marduk.eng.sun.com> To: ed.gould@sun.com, glenn.faden@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris Cc: Gary.Winiger@sun.com, psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com, Joseph.Kowalski@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 614 > > also bundled. > > Yes, all but the X windows privileges are used in bundled kernel modules. Bundling here is an illusion. Unless the unbundled (and still a loose end) lbl_edition kernel module is loaded none of the two (out of 17 TX privileges) kernel privileges is enforced. So in that sense no privilege is enforced without unbundled software. > Now that configurable zone privileges has integrated into Nevada, I'm > inclined to add these X window privileges to the appropriate safe, That looks like a new ARC case to modify the previous case that defined configurable zone privileges. Gary.. From sacadmin Tue Mar 21 21:27:16 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2M5RGIQ025084 for ; Tue, 21 Mar 2006 21:27:16 -0800 (PST) Received: from [192.168.0.6] (vpn-129-150-20-123.SFBay.Sun.COM [129.150.20.123]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with ESMTP id k2M5RD1G331916; Tue, 21 Mar 2006 21:27:14 -0800 (PST) Message-ID: <4420DFD7.2000507@sun.com> Date: Tue, 21 Mar 2006 21:25:43 -0800 From: Glenn Faden User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20051122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Winiger CC: ed.gould@sun.com, Gary.Winiger@sun.com, psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com, Joseph.Kowalski@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603220501.k2M51rnv000474@marduk.eng.sun.com> In-Reply-To: <200603220501.k2M51rnv000474@marduk.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1396 It should be apparent to everybody by now that we don't really have an architecture for dynamically defined privileges that allows a project like Trusted Extensions to be successful. I think the issue about whether the privileges are enabled is misleading. Even when these privileges are not being used to enforce policy, they still need to be defined for compilation as in libzonecfg.c and for processesing of configurable databases like RBAC exec_attr which are shared via name services. There can be other ARC cases to deal with dynamic privileges but the Trusted Extensions project has already done the best it could with the existing architecture. We plan to putback into Nevada tomorrow. --Glenn Gary Winiger wrote: >>>also bundled. >>> >>> >>Yes, all but the X windows privileges are used in bundled kernel modules. >> >> > > Bundling here is an illusion. Unless the unbundled (and still > a loose end) lbl_edition kernel module is loaded none of the > two (out of 17 TX privileges) kernel privileges is enforced. > So in that sense no privilege is enforced without unbundled > software. > > > >>Now that configurable zone privileges has integrated into Nevada, I'm >>inclined to add these X window privileges to the appropriate safe, >> >> > > That looks like a new ARC case to modify the previous case > that defined configurable zone privileges. > >Gary.. > > From sacadmin Wed Mar 22 01:48:45 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2M9miIQ029539 for ; Wed, 22 Mar 2006 01:48:44 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2M9mWCM021251; Wed, 22 Mar 2006 10:48:32 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2M9mVDk011852; Wed, 22 Mar 2006 10:48:32 +0100 (MET) Message-Id: <200603220948.k2M9mVDk011852@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: David Comay cc: Glenn.Faden@Sun.COM, sommerfeld@Sun.COM, John.Plocher@Sun.COM, Lokanath.Das@Sun.COM, Scott.Rotondo@Sun.COM, Simon.Gordon@Sun.COM, gww@eng.sun.com, psarc@sac.sfbay.sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <200603220038.k2M0cBfA102238@izimbra.SFBay.Sun.COM> References: <200603220038.k2M0cBfA102238@izimbra.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Mar 2006 10:48:31 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 736 >> I'd hope that configurable zone privileges support could handle >> privileges added by an unbundled component. If that's not a case, it's >> a serious limitation on configurable zone privileges... > >Yes, the configurable zone privilege support does "understand" >privileges added by an unbundled product in that it relies on >priv_str_to_set(3C) and ultimately the kernel to determine if the >privilege is valid or not. As long as that privilege name is >understood by the underlying system, then it can be included in the >"limitpriv" property maintained by zonecfg(1M). Is there a way to configure a "default set" for all zones? I can imagine that a unbundled privileges wants to be present in all zones by default? Casper From sacadmin Wed Mar 22 02:12:09 2006 Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MAC9IQ001568 for ; Wed, 22 Mar 2006 02:12:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2MAC9eq103748; Wed, 22 Mar 2006 02:12:09 -0800 (PST) Date: Wed, 22 Mar 2006 02:12:08 -0800 (PST) From: David.Comay@Sun.COM Sender: comay@izimbra.sfbay.sun.com To: Casper.Dik@Sun.COM cc: David Comay , Glenn.Faden@Sun.COM, sommerfeld@Sun.COM, John.Plocher@Sun.COM, Lokanath.Das@Sun.COM, Scott.Rotondo@Sun.COM, Simon.Gordon@Sun.COM, gww@eng.sun.com, psarc@sac.sfbay.sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <200603220948.k2M9mVDk011852@vaticaan.Holland.Sun.COM> Message-ID: References: <200603220038.k2M0cBfA102238@izimbra.SFBay.Sun.COM> <200603220948.k2M9mVDk011852@vaticaan.Holland.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 1001 > Is there a way to configure a "default set" for all zones? I believe this is the same functionality that Kais asked about in 2006/124. The answer is that such functionality doesn't currently exist today. A rough workaround would be to use the "create -t" functionality of zonecfg(1M) using a template that defines a specialized "default set" or otherwise provisions the zone where the "limitpriv" property is always set to a particular value (particularly one containing the special privile(s) in question). I don't know if that makes sense for the Trusted Extensions case - certainly the containers they're using are rather different than the typical ones used for server consolidation and in many cases are more "uniform", for lack of a better word. But I believe they also have privilege differences between each of the zones as well. > I can imagine that a unbundled privileges wants to be present in all > zones by default? Agreed - having a way of specifying that would be useful. dsc From sacadmin Wed Mar 22 02:12:13 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MACDIQ001572 for ; Wed, 22 Mar 2006 02:12:13 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2MABwCM003569; Wed, 22 Mar 2006 11:11:58 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2MABwDk014151; Wed, 22 Mar 2006 11:11:58 +0100 (MET) Message-Id: <200603221011.k2MABwDk014151@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Glenn Faden cc: Ed.Gould@Sun.COM, Gary.Winiger@Sun.COM, psarc@sac.sfbay.sun.com, Simon.Gordon@Sun.COM, John.Plocher@Sun.COM, Scott.Rotondo@Sun.COM, Joseph.Kowalski@Sun.COM Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <4420DFD7.2000507@sun.com> References: <200603220501.k2M51rnv000474@marduk.eng.sun.com> <4420DFD7.2000507@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Mar 2006 11:11:58 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1146 >It should be apparent to everybody by now that we don't >really have an architecture for dynamically defined privileges >that allows a project like Trusted Extensions to be successful. > >I think the issue about whether the privileges are enabled >is misleading. Even when these privileges are not being >used to enforce policy, they still need to be defined for compilation >as in libzonecfg.c and for processesing of configurable databases like >RBAC exec_attr which are shared via name services. We do not need the privileges for RBAC; it ignores unknown privileges now (well, for some, we'll probably need to fix the rest) >There can be other ARC cases to deal with dynamic privileges >but the Trusted Extensions project has already done the best >it could with the existing architecture. We plan to putback into >Nevada tomorrow. No, that was not the best it could have done; projects which find the current architecture lacking should extend the current architecture, not inflict adhocery. (But the statement that TX changed 100,000 lines of course in Nevada proper concerns me actually much more than this privileges thing) Casper From sacadmin Wed Mar 22 06:36:09 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MEa8IQ011237 for ; Wed, 22 Mar 2006 06:36:09 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2MEZYs9012478; Wed, 22 Mar 2006 14:35:34 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2MEZYKG012477; Wed, 22 Mar 2006 09:35:34 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Converging 2002/762 Layered Trusted Solaris From: Bill Sommerfeld To: Glenn Faden Cc: Gary Winiger , Ed.Gould@sun.com, Gary.Winiger@sun.com, psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com, Joseph.Kowalski@sun.com In-Reply-To: <4420DFD7.2000507@sun.com> References: <200603220501.k2M51rnv000474@marduk.eng.sun.com> <4420DFD7.2000507@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1143038133.12467.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Wed, 22 Mar 2006 09:35:33 -0500 Status: RO Content-Length: 1008 On Wed, 2006-03-22 at 00:25, Glenn Faden wrote: > It should be apparent to everybody by now that we don't > really have an architecture for dynamically defined privileges > that allows a project like Trusted Extensions to be successful. PSARC will often insist that projects fill in small gaps in the infrastructure they're built on -- in many ways that's the only way to get this sort of infrastructure work done. It is unfortunate that this surfaced so late but the fact that it surfaced late does not mean it can be ignored. > Even when these privileges are not being > used to enforce policy, they still need to be defined for compilation > as in libzonecfg.c That's a small missing piece of the design which should be fixed, not by hard-coding privileges into libzonecfg but by making this state configurable. > and for processing of configurable databases like > RBAC exec_attr which are shared via name services. If true, (and someone else has disputed this) that's also a bug. - Bill From sacadmin Wed Mar 22 07:06:45 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MF6iIQ012336 for ; Wed, 22 Mar 2006 07:06:44 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2MF6iPN018047; Wed, 22 Mar 2006 10:06:44 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2MF6iVB018044; Wed, 22 Mar 2006 10:06:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17441.26628.37079.563293@gargle.gargle.HOWL> Date: Wed, 22 Mar 2006 10:06:44 -0500 From: James Carlson To: Bill Sommerfeld Cc: Glenn Faden , psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: Bill Sommerfeld's message of 22 March 2006 09:35:33 References: <200603220501.k2M51rnv000474@marduk.eng.sun.com> <4420DFD7.2000507@sun.com> <1143038133.12467.11.camel@localhost> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3145 Bill Sommerfeld writes: > On Wed, 2006-03-22 at 00:25, Glenn Faden wrote: > > It should be apparent to everybody by now that we don't > > really have an architecture for dynamically defined privileges > > that allows a project like Trusted Extensions to be successful. > > PSARC will often insist that projects fill in small gaps in the > infrastructure they're built on -- in many ways that's the only way to > get this sort of infrastructure work done. I'd like to understand in more detail exactly what we're asking of the project team here. I'll start with one concrete example. Rampart added a new "net_bindmlp" privilege for controlling access to multi-level ports (MLPs). This privilege does nothing on an unlabeled system, because unlabeled systems don't (and _perhaps_ can't) have any multi-level ports. (I say only "perhaps," because the same concept could possibly come up in the future with other extensions to Zones.) In the kernel, this privilege is enforced in the places where an MLP could be bound -- i.e., in sctp_bindi, tcp_bind, and udp_bind; the transports with ports. Of course, it's only possible to reach that code if the user is attempting to bind to an MLP, and that only happens when the system is labeled. The privilege is present but a no-op on an unlabeled system. The ARC request to the project team seems to be to take these "Rampart-only" privileges out of the base system and place them in unbundled packages alone. How does that work for things that must be checked either in the kernel itself or that must be checked in utilities delivered by the base OS? Are we asking the project team to design a set of loadable hooks for their private use as well? If so, why? Wouldn't the stability of those hooks be an important consideration? One of the key goals of the Rampart project, as I understood it, was to avoid the unmaintainable spaghetti that necessarily results from a "bag on the side" approach. Embedding a key subset of the code means that it will be better maintained over time. (In fact, other projects that use hooks do so only in controlled and narrow ways. Both CGTP and Sun Cluster have dormant functionality embedded into the OS itself and use hooks only for nicely severable. Are we saying that even this approach is incorrect? Or is it just specifically wrong when privileges are involved, and not with other extensions to OS functionality?) Or do the unbundling comments apply "only" to the privileges that are used by non-ON consolidations, such as X? If that's the case, why is that so? Is it merely an ON distinction? Or do the comments apply just to the privileges that are used only in the unbundled deliverables themselves and not in any base deliverable? If so, what is that subset? (Is it a significant enough set of dead weight privileges to worry about?) I'd like to know what the boundaries are here, but I don't quite see them yet. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Mar 22 07:15:58 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MFFvIQ013885 for ; Wed, 22 Mar 2006 07:15:57 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2MFFhCM019799; Wed, 22 Mar 2006 16:15:44 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2MFFhDk015703; Wed, 22 Mar 2006 16:15:43 +0100 (MET) Message-Id: <200603221515.k2MFFhDk015703@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Glenn Faden , Gary Winiger , Ed.Gould@sun.com, Gary.Winiger@sun.com, psarc@sac.sfbay.sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com, Joseph.Kowalski@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <1143038133.12467.11.camel@localhost> References: <200603220501.k2M51rnv000474@marduk.eng.sun.com> <4420DFD7.2000507@sun.com> <1143038133.12467.11.camel@localhost> Date: Wed, 22 Mar 2006 16:15:43 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 518 >That's a small missing piece of the design which should be fixed, not by >hard-coding privileges into libzonecfg but by making this state >configurable. The hardcoding of privileges in libzonecfg was always a bug and never a feature. >> and for processing of configurable databases like >> RBAC exec_attr which are shared via name services. > >If true, (and someone else has disputed this) that's also a bug. It's still a problem for exec_attr, not any more for user_attr. But that's also a bug, indeed. Casper From sacadmin Wed Mar 22 07:37:02 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MFb1IQ017384 for ; Wed, 22 Mar 2006 07:37:01 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2MFaT8s012505; Wed, 22 Mar 2006 15:36:30 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2MFaT4g012504; Wed, 22 Mar 2006 10:36:29 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Converging 2002/762 Layered Trusted Solaris From: Bill Sommerfeld To: James Carlson Cc: Glenn Faden , psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com In-Reply-To: <17441.26628.37079.563293@gargle.gargle.HOWL> References: <200603220501.k2M51rnv000474@marduk.eng.sun.com> <4420DFD7.2000507@sun.com> <1143038133.12467.11.camel@localhost> <17441.26628.37079.563293@gargle.gargle.HOWL> Content-Type: text/plain; charset=ASCII Content-Transfer-Encoding: 7bit Message-Id: <1143041788.12467.37.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Wed, 22 Mar 2006 10:36:28 -0500 Status: RO Content-Length: 1076 On Wed, 2006-03-22 at 10:06, James Carlson wrote: > I'd like to understand in more detail exactly what we're asking of the > project team here. .. and I'd like to understand in more detail exactly how and where this project is checking these additional privileges. > Or do the unbundling comments apply "only" to the privileges that are > used by non-ON consolidations, such as X? If that's the case, why is > that so? Is it merely an ON distinction? I don't think that's the case. > Or do the comments apply just to the privileges that are used only in > the unbundled deliverables themselves and not in any base deliverable? > If so, what is that subset? (Is it a significant enough set of dead > weight privileges to worry about?) >From my point of view the argument for unbundling the privileges is strong for the set of privileges which are never checked/enforced in the base system, and weak for the privileges which are checked in code which is part of the base system. But I'd like to hear what Casper (as a subject matter expert) has to say. - Bill From sacadmin Wed Mar 22 07:43:14 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MFhEIQ017487 for ; Wed, 22 Mar 2006 07:43:14 -0800 (PST) Received: from [192.168.0.6] (vpn-129-150-20-123.SFBay.Sun.COM [129.150.20.123]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with ESMTP id k2MFhB3K743546; Wed, 22 Mar 2006 07:43:13 -0800 (PST) Message-ID: <44217033.8070300@sun.com> Date: Wed, 22 Mar 2006 07:41:39 -0800 From: Glenn Faden User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20051122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: Gary Winiger , Ed.Gould@sun.com, Gary.Winiger@sun.com, psarc@sac.sfbay.sun.com, Casper.Dik@sun.com, Simon.Gordon@sun.com, John.Plocher@sun.com, Scott.Rotondo@sun.com, Joseph.Kowalski@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris References: <200603220501.k2M51rnv000474@marduk.eng.sun.com> <4420DFD7.2000507@sun.com> <1143038133.12467.11.camel@localhost> In-Reply-To: <1143038133.12467.11.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1922 Bill Sommerfeld wrote: >On Wed, 2006-03-22 at 00:25, Glenn Faden wrote: > > >>It should be apparent to everybody by now that we don't >>really have an architecture for dynamically defined privileges >>that allows a project like Trusted Extensions to be successful. >> >> > >PSARC will often insist that projects fill in small gaps in the >infrastructure they're built on -- in many ways that's the only way to >get this sort of infrastructure work done. > > Trusted Extensions has extended the infrastructure of many existing Solaris components but we also tried not to make unnecessary changes. This issue fell in the latter category. >It is unfortunate that this surfaced so late but the fact that it >surfaced late does not mean it can be ignored. > > It wasn't ignored. See below: >> Even when these privileges are not being >>used to enforce policy, they still need to be defined for compilation >>as in libzonecfg.c >> >> > >That's a small missing piece of the design which should be fixed, not by >hard-coding privileges into libzonecfg but by making this state >configurable. > > This code was just integrated last Sunday by the Zones team. > > >>and for processing of configurable databases like >>RBAC exec_attr which are shared via name services. >> >> > >If true, (and someone else has disputed this) that's also a bug. > > What is disuputed is how to fix this, not that it is broken. A partial fix for PAM was just putback to Nevada: 6395043 having extra privileges prevents logins in zones but the code in pfexec still fails if unknown privileges are specified in exec_attr. In fact the problem originally reported by me in the bug was not addressed, and the synopsis was changed to describe a different bug related to PAM. Read the original description. I recently filed a new RFE on this topic. 6399150 Need a stable interface for adding privileges dynamically --Glenn From sacadmin Wed Mar 22 08:28:52 2006 Received: from phys-dfw04-1 (phys-dfw04-1.Central.Sun.COM [129.152.1.139]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MGSqIQ019082 for ; Wed, 22 Mar 2006 08:28:52 -0800 (PST) Received: from conversion-daemon.dfw04-mail1.central.sun.com by dfw04-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IWJ00801EDOPY@dfw04-mail1.central.sun.com> (original mail from mark.thacker@sun.com) for psarc@sac.sfbay.sun.com; Wed, 22 Mar 2006 10:28:51 -0600 (CST) Received: from [129.150.48.90] (vpn-129-150-48-90.Central.Sun.COM [129.150.48.90]) by dfw04-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IWJ00A1TF41AQ@dfw04-mail1.central.sun.com>; Wed, 22 Mar 2006 10:28:51 -0600 (CST) Date: Wed, 22 Mar 2006 10:28:47 -0600 From: Mark Thacker - Product Line Manager Subject: Re: Converging 2002/762 Layered Trusted Solaris In-reply-to: <44205355.30803@sun.com> To: Glenn Faden Cc: Casper.Dik@Sun.COM, Lokanath Das , Scott Rotondo , Gary Winiger , psarc@sac.sfbay.sun.com, Simon.Gordon@Sun.COM, John.Plocher@Sun.COM Message-id: <44217B3F.4010108@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060113) References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> <441B4BB2.8080603@sun.com> <200603211515.k2LFF7Dk020761@vaticaan.Holland.Sun.COM> <44204671.7040906@sun.com> <200603211844.k2LIi4Dk001563@vaticaan.Holland.Sun.COM> <44204D96.5060101@sun.com> <200603211907.k2LJ72Dk002174@vaticaan.Holland.Sun.COM> <44205355.30803@sun.com> Status: RO Content-Length: 2177 I'm keeping out of the loop here regarding this discussion other than to say that the concept of 'unbundled' is indeed just a bit of an illusion. We will be marketing Trusted Extensions as a 'part' of Solaris, noting that it it utilizing the same kernel, the same privilege model and other components from standard Solaris. It's also very very very possible that TX will be delivered in the future as a part of the standard Solaris install. At least, that's one of the many goals that many of us believe is reasonable. Thus, the definition of 'unbundled' doesn't really apply much to TX. Glenn Faden wrote: > Casper, > > Some of the new privileges that are introduced in this > project are checked by bundled kernel components > but the tests are within logic that tests for is_system_labeled(). > These clearly are not suitable for unbundling. > > The remaining X server-related privileges are used by > code in the X, CDE and JDS gates. In addition they may > appear in RBAC entries stored in LDAP databases. > > As these privileges apply to X clients running in non-global > zone, they should be listed in the new configurable zone > privilege sets maintainted in libzonecfg, so these privileges > will be used in ON, as well. > > The notion that Rampart is an unbundled product is a > bit of a marketing illusion. We are adding or modifying > over 100,000 lines of code in the WOS. This is Solaris. > Unbundling these privileges is not appropriate. > > --Glenn > > Casper.Dik@Sun.COM wrote: > >>> One of the compelling reason to leave these privileges >>> in Solaris is to allow future sedimentation of Trusted >>> Extensions features into Solaris, particularly in the >>> area of X server policy enforcement to support a more >>> secure JDS. >>> >> >> Just like Disksuite couldn't be bundled into Solaris because >> it was an unbundled product first? >> >> Doesn't strike me as a valid argument. >> >> Casper >> >> > > -- Mark Thacker Product Line Manager, Solaris Security and Trusted Solaris Phone : 972-992-3178 (internal x66755) AOL IM : mthacker75034 Email : mark.thacker@sun.com 16000 N. Dallas. Pkwy, Suite 700 Dallas, Texas 75248 USA From sacadmin Wed Mar 22 11:55:30 2006 Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MJtUIQ029713 for ; Wed, 22 Mar 2006 11:55:30 -0800 (PST) Received: from izimbra.SFBay.Sun.COM (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2MJtTGS104702; Wed, 22 Mar 2006 11:55:29 -0800 (PST) Received: (from comay@localhost) by izimbra.SFBay.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2MJtSo9104701; Wed, 22 Mar 2006 11:55:28 -0800 (PST) Date: Wed, 22 Mar 2006 11:55:28 -0800 (PST) From: David Comay Message-Id: <200603221955.k2MJtSo9104701@izimbra.SFBay.Sun.COM> To: Casper.Dik@sun.com, glenn.faden@sun.com, sommerfeld@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris Cc: Ed.Gould@sun.com, Gary.Winiger@sun.com, John.Plocher@sun.com, Joseph.Kowalski@sun.com, Scott.Rotondo@sun.com, Simon.Gordon@sun.com, gww@eng.sun.com, psarc@sac.sfbay.sun.com Status: RO Content-Length: 1074 Glenn>> Even when these privileges are not being Glenn>> used to enforce policy, they still need to be defined for compilation Glenn>> as in libzonecfg.c Bill> That's a small missing piece of the design which should be fixed, not by Bill> hard-coding privileges into libzonecfg but by making this state Bill> configurable. Glenn> This code was just integrated last Sunday by the Zones team. Indeed and I wish that I had realized or was aware myself of the controversy regarding unbundled privileges surrounding this project. Yes, it's a bug that libzonecfg (or any other parts of the system) has any hard-coded lists of privileges. Perhaps what's needed is is some sort of mechanism to extend/read the private /etc/security/extra_privs database to include some sort of metadata that consumers like libzonecfg can reference to determine what sort of privilege this is. privadm(1M) anyone? Casper, for kernel components which aren't drivers is there a mechanism to deliver unbundled privileges? Or does a driver always need to accompany the other functionality? dsc From sacadmin Wed Mar 22 12:01:26 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MK1PIQ029768 for ; Wed, 22 Mar 2006 12:01:25 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2MK1ACM014313; Wed, 22 Mar 2006 21:01:10 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2MK1ADk012360; Wed, 22 Mar 2006 21:01:10 +0100 (MET) Message-Id: <200603222001.k2MK1ADk012360@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: David Comay cc: Glenn.Faden@Sun.COM, sommerfeld@Sun.COM, Ed.Gould@Sun.COM, Gary.Winiger@Sun.COM, John.Plocher@Sun.COM, Joseph.Kowalski@Sun.COM, Scott.Rotondo@Sun.COM, Simon.Gordon@Sun.COM, gww@eng.sun.com, psarc@sac.sfbay.sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <200603221955.k2MJtSo9104701@izimbra.SFBay.Sun.COM> References: <200603221955.k2MJtSo9104701@izimbra.SFBay.Sun.COM> Date: Wed, 22 Mar 2006 21:01:10 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 317 >Casper, for kernel components which aren't drivers is there a mechanism >to deliver unbundled privileges? Or does a driver always need to >accompany the other functionality? Well, kernel components can start off and call the functions which allocate privileges they need when their subsystem gets loaded. Casper From sacadmin Wed Mar 22 12:02:32 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MK2VIQ029815 for ; Wed, 22 Mar 2006 12:02:31 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2MK2ICM014606; Wed, 22 Mar 2006 21:02:18 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2MK2IDk012471; Wed, 22 Mar 2006 21:02:18 +0100 (MET) Message-Id: <200603222002.k2MK2IDk012471@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: David Comay cc: Glenn.Faden@Sun.COM, sommerfeld@Sun.COM, Ed.Gould@Sun.COM, Gary.Winiger@Sun.COM, John.Plocher@Sun.COM, Joseph.Kowalski@Sun.COM, Scott.Rotondo@Sun.COM, Simon.Gordon@Sun.COM, gww@eng.sun.com, psarc@sac.sfbay.sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <200603221955.k2MJtSo9104701@izimbra.SFBay.Sun.COM> References: <200603221955.k2MJtSo9104701@izimbra.SFBay.Sun.COM> Date: Wed, 22 Mar 2006 21:02:18 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 413 >Yes, it's a bug that libzonecfg (or any other parts of the system) has >any hard-coded lists of privileges. Perhaps what's needed is is some >sort of mechanism to extend/read the private /etc/security/extra_privs >database to include some sort of metadata that consumers like >libzonecfg can reference to determine what sort of privilege this is. Like the keywords used in priv_defs? (basic, unsafe) Casper From sacadmin Wed Mar 22 12:22:10 2006 Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MKMAIQ000340 for ; Wed, 22 Mar 2006 12:22:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2MKM1BP104742; Wed, 22 Mar 2006 12:22:01 -0800 (PST) Date: Wed, 22 Mar 2006 12:22:01 -0800 (PST) From: David.Comay@Sun.COM Sender: comay@izimbra.sfbay.sun.com To: Casper.Dik@Sun.COM cc: Glenn.Faden@Sun.COM, sommerfeld@Sun.COM, Ed.Gould@Sun.COM, Gary.Winiger@Sun.COM, John.Plocher@Sun.COM, Joseph.Kowalski@Sun.COM, Scott.Rotondo@Sun.COM, Simon.Gordon@Sun.COM, gww@eng.sun.com, psarc@sac.sfbay.sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris In-Reply-To: <200603222002.k2MK2IDk012471@vaticaan.Holland.Sun.COM> Message-ID: References: <200603221955.k2MJtSo9104701@izimbra.SFBay.Sun.COM> <200603222002.k2MK2IDk012471@vaticaan.Holland.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 1211 >> Yes, it's a bug that libzonecfg (or any other parts of the system) has >> any hard-coded lists of privileges. Perhaps what's needed is is some >> sort of mechanism to extend/read the private /etc/security/extra_privs >> database to include some sort of metadata that consumers like >> libzonecfg can reference to determine what sort of privilege this is. > > Like the keywords used in priv_defs? (basic, unsafe) Yes, something along those lines. See also 6400501 libzonecfg's privilege lists should be generated dynamically One thing I wanted to note earlier about libzonecfg is there are two notions of "default" I think we're talking about. One is the default set of privileges that Sun has tested and believes to be safe to hand out to zones and which provides the isolation that is the core tenet of the project. The other notion is the one that Kais originally brought up and which could be used by unbundled products like TX - this new privilege, priv_something, should be made available in all zones by default. The zones team has discussed extending the existing, inadequate template mechanism in zonecfg(1M) to allow for this sort of thing and it's on our roadmap for the future. dsc From sacadmin Wed Mar 22 13:14:39 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MLEbIQ001634 for ; Wed, 22 Mar 2006 13:14:39 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2MLEWWa027765; Wed, 22 Mar 2006 16:14:32 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2MLEW7d022864; Wed, 22 Mar 2006 16:14:32 -0500 (EST) Subject: Re: Converging 2002/762 Layered Trusted Solaris From: Bill Sommerfeld To: Gary Winiger Cc: psarc@sac.eng.sun.com, Simon.Gordon@sun.com, Casper.Dik@sun.com, John.Plocher@sun.com In-Reply-To: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> References: <200603160246.k2G2k5Ex017681@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1143062072.21056.366.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Wed, 22 Mar 2006 16:14:32 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2264 This was discussed during ARC business today as a last-minute agenda item. This case remains in "waiting need spec" state but we appear to have a tentative resolution which the bulk of the members can live with. Two distinct issues were raised: 1) the loose end you noted relating to the lbl_edition kernel module. 2) the question of bundled vs unbundled privileges. These were resolved differently. #1 was spun off to a fast-track to be named later which the TX team is expected to file (most likely with short timeout) prior to putback. Specifically, the TX project team will document the interface between the bulk of the kernel and the separately delivered lbl_edition module. Based on the oblique references to this interface in existing case material this is an exercise in ensuring the specification is archived. 2002/762 (and thus the integration of the TX project into ON), has a case dependency on this as-yet-unfiled fasttrack. #2 was resolved via a straw vote, and I expect that we'll need an opinion to follow this up. The question voted on was: Is trusted extensions entitled to bundle privileges it needs? Approximate result of the straw vote: yes 3 (Glenn, Ed, Jim) no 0 abstain 1.5 (Bill + 0.5*Joe) NP 1.5 (Shudong + 0.5*Joe) (actually, Joe said both NP and abstain and I didn't catch where he settled). As I understand it, the plurality assert that it is a mistake to think of TX as unbundled; the fact that it is, at present, largely disabled without the addition of a (as yet, incompletely reviewed) unbundled component is outweighed by the fact that the bulk of the mechanism is physically present in and maintained as part of Solaris. Members present at the meeting who were not entirely satisified by this resolution are still generally disinclined to block integration of this project -- TX is a very large and complex project; given human fallability and the impossibility of constructing a truly comprehensive test suite projects of such scale simply cannot be perfect at time of integration. Today's tentative resolution should not preclude efforts to build a true consensus on the privilege delivery issue. If anyone present in the meeting believes I've misrepresented their position, please speak up soon. From sacadmin Wed Mar 22 13:57:14 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MLvEIQ002729 for ; Wed, 22 Mar 2006 13:57:14 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k2MLv7Zw179587; Wed, 22 Mar 2006 13:57:12 -0800 (PST) Message-Id: <200603222157.k2MLv7Zw179587@jurassic.eng.sun.com> Date: Wed, 22 Mar 2006 11:55:36 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Converging 2002/762 Layered Trusted Solaris To: gww@eng.sun.com, sommerfeld@sun.com Cc: psarc@sac.eng.sun.com, Simon.Gordon@sun.com, Casper.Dik@sun.com, John.Plocher@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Fko/vd3cqGLnkMecTgsy3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 550 > From: Bill Sommerfeld ... > Approximate result of the straw vote: > yes 3 (Glenn, Ed, Jim) > no 0 > abstain 1.5 (Bill + 0.5*Joe) > NP 1.5 (Shudong + 0.5*Joe) > (actually, Joe said both NP and abstain and I didn't catch where he > settled). Well, since this is a straw vote, the best way to characterize my position would be in the fast-track mode of "more time". I don't believe the issue has been fully discussed or investigated. I believe that once this happens, I'd be a Yes or a No and not on the fence. - jek3 From sacadmin Wed Mar 22 14:11:03 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MMB2IQ003090 for ; Wed, 22 Mar 2006 14:11:03 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2MMAvWa020619; Wed, 22 Mar 2006 17:10:57 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2MMAvwg022992; Wed, 22 Mar 2006 17:10:57 -0500 (EST) Subject: Re: Converging 2002/762 Layered Trusted Solaris From: Bill Sommerfeld To: Joseph Kowalski Cc: gww@eng.sun.com, psarc@sac.eng.sun.com, Simon.Gordon@sun.com, Casper.Dik@sun.com, John.Plocher@sun.com In-Reply-To: <200603222157.k2MLv7Zw179587@jurassic.eng.sun.com> References: <200603222157.k2MLv7Zw179587@jurassic.eng.sun.com> Content-Type: text/plain Message-Id: <1143065456.21056.552.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Wed, 22 Mar 2006 17:10:57 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 503 On Wed, 2006-03-22 at 16:55, Joseph Kowalski wrote: > Well, since this is a straw vote, the best way to characterize my > position would be in the fast-track mode of "more time". I don't believe > the issue has been fully discussed or investigated. I believe that > once this happens, I'd be a Yes or a No and not on the fence. That's actually a fair way to characterize my position as well. So we have: yes 3 (Glenn, Ed, Jim) no 0 more time 2 (Bill + Joe) NP 1 (Shudong) - Bill From sacadmin Wed Mar 22 14:29:55 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MMTtIQ003616 for ; Wed, 22 Mar 2006 14:29:55 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2MMTpbB020857; Wed, 22 Mar 2006 17:29:51 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2MMToCY023564; Wed, 22 Mar 2006 17:29:50 -0500 (EST) Subject: Tentative resolution to open issues of 2002/762 Layered Trusted Solaris. From: Bill Sommerfeld To: onnv-cteam@sun.com Cc: psarc@sac.eng.sun.com, Simon.Gordon@sun.com, Casper.Dik@sun.com, John.Plocher@sun.com, Glenn Faden Content-Type: text/plain Message-Id: <1143066590.21056.630.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Wed, 22 Mar 2006 17:29:50 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1229 I have been informed that the Layered Trusted Solaris project wishes to integrate in the very near future. You may be familiar with the case history of 2002/762 already, but to summarize, we started today with two open issues. First, PSARC is still waiting for one remaining component of the TX project to be presented for fast-track review: specifically, the interface between the base system and the to-be-delivered-as-unbundled "lbl_edition" module which enables the new TX functionality. I expect that this will qualify for a short-timeout fast-track but that will depend on exactly what this interface contains. Second, there was a fairly heated discussion regarding the bundling of TX's new privileges. The best that can be said is that we have a tentative resolution to this issue. My personal hope is that discussion can continue offline and that we can find a real consensus resolution, but that will take time, and, in the absence of other stoppers, it does not make sense to block integration of the project to wait for that resolution -- I expect that the difference, if any, between the tentative resolution and the final result can be handled with a relatively contained followup integration. - Bill From sacadmin Wed Mar 22 21:48:36 2006 Received: from engmail2sun.Eng.Sun.COM (engmail2sun.SFBay.Sun.COM [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2N5maIQ013559 for ; Wed, 22 Mar 2006 21:48:36 -0800 (PST) Received: from jotunheim.eng.sun.com (jotunheim.SFBay.Sun.COM [129.146.104.159]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2N5mXDb014715; Wed, 22 Mar 2006 21:48:33 -0800 (PST) Received: from jotunheim (jotunheim [129.146.104.159]) by jotunheim.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA22529; Wed, 22 Mar 2006 21:46:17 -0800 (PST) Message-Id: <200603230546.VAA22529@jotunheim.eng.sun.com> Date: Wed, 22 Mar 2006 21:46:17 -0800 (PST) From: Simon Gordon Reply-To: Simon Gordon Subject: Re: Tentative resolution to open issues of 2002/762 Layered Trusted Solaris. To: sommerfeld@Sun.COM Cc: psarc@sac.sfbay.sun.com, onnv-cteam@Sun.COM, Casper.Dik@Sun.COM, John.Plocher@Sun.COM, Glenn.Faden@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gc3ROJx6+3B9F0ASRvkddg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Status: RO Content-Length: 2231 Bill, I want to thank you for your quick turn around today and allowing time at PSARC this morning for these issues to be resolved. Raising these issues to PSARC was the right thing to do, whatever the outcome. Keeping you up-to-date on our ONNV putback: Our plan was to putback to ONNV tonight. However, plans change and our putback is rescheduled for tomorrow evening. Thanks, Simon ~> Date: Wed, 22 Mar 2006 17:29:50 -0500 ~> From: Bill Sommerfeld ~> Subject: Tentative resolution to open issues of 2002/762 Layered Trusted Solaris. ~> To: onnv-cteam@sun.com ~> Cc: psarc@sac.sfbay.sun.com, Simon.Gordon@sun.com, Casper.Dik@sun.com, John.Plocher@sun.com, Glenn Faden ~> x_sac_archived: PSARC/2002/762 ~> x_sac_loop: lsarc-members@sun.com rampart-dev-team@sun.com ~> x_sac_info: auto-forwarded by the SAC mail system ~> X-PMX-Version: 5.1.2.240295 ~> ~> I have been informed that the Layered Trusted Solaris project wishes to ~> integrate in the very near future. ~> ~> You may be familiar with the case history of 2002/762 already, but to ~> summarize, we started today with two open issues. ~> ~> First, PSARC is still waiting for one remaining component of the TX ~> project to be presented for fast-track review: specifically, the ~> interface between the base system and the to-be-delivered-as-unbundled ~> "lbl_edition" module which enables the new TX functionality. I expect ~> that this will qualify for a short-timeout fast-track but that will ~> depend on exactly what this interface contains. ~> ~> Second, there was a fairly heated discussion regarding the bundling of ~> TX's new privileges. The best that can be said is that we have a ~> tentative resolution to this issue. My personal hope is that discussion ~> can continue offline and that we can find a real consensus resolution, ~> but that will take time, and, in the absence of other stoppers, it does ~> not make sense to block integration of the project to wait for that ~> resolution -- I expect that the difference, if any, between the ~> tentative resolution and the final result can be handled with a ~> relatively contained followup integration. ~> ~> - Bill ~> ~> ~> From sacadmin Wed Mar 22 22:47:53 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2N6lrIQ014666 for ; Wed, 22 Mar 2006 22:47:53 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2N6kmYr002913; Wed, 22 Mar 2006 22:46:48 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2N6km2U002912; Wed, 22 Mar 2006 22:46:48 -0800 (PST) Date: Wed, 22 Mar 2006 22:46:48 -0800 (PST) From: Gary Winiger Message-Id: <200603230646.k2N6km2U002912@marduk.eng.sun.com> To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Subject: Re: Converging 2002/762 Layered Trusted Solaris Cc: gww@eng.sun.com, psarc@sac.eng.sun.com, Simon.Gordon@sun.com, Casper.Dik@sun.com, John.Plocher@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 771 > That's actually a fair way to characterize my position as well. I'd like to express my thanks to the committee for stepping in in my absence. This has been a planned holiday since my son left for college last fall. It's his break between quarters and the family is with him and his girlfriend on holiday. I'd been trying behind the scenes to have the TX team realize that there was the open privileges issue for some time. IMO this and the is_system_labeled ... all would have come out if the project had ARCed the "how does all this install" case noted in the umbrella summary. Sigh, not enough arc early, arc often..... Any how, my thanks. And to Bill as I just see 2006/191 is_system_labeled. Which I'll include in the Umbrella opinion. Gary.. From sacadmin Fri Apr 27 17:34:10 2007 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3S0YAqg010198 for ; Fri, 27 Apr 2007 17:34:10 -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 l3S0YfOZ014742; Fri, 27 Apr 2007 17:34:41 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l3S0YfbR014741; Fri, 27 Apr 2007 17:34:41 -0700 (PDT) Date: Fri, 27 Apr 2007 17:34:41 -0700 (PDT) From: Gary Winiger Message-Id: <200704280034.l3S0YfbR014741@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com Subject: Call for formal vote on 2002/762 Layered Trusted Solaris. Status: RO Content-Length: 9515 As members present at the 22 March 2006 meeting may recall, I was on vacation. As the project team was out of time to make their deliver schedule the case was discussed during ARC business and a straw vote held. The results as recorded in the minutes were Jim, Ed, Glenn to approve, Bill abstain and Shudong and Joe NP. The discussion centered around two points: The bundling of privileges defined in various subcases. A missing interface, is_system_labeled. The discussion in the mail log presented and during ARC business presented the various points of view on the bundling of privileges. As one of the privilege subject matter experts (along with Casper and Glenn Faden), I felt is was important to have the discussion which was concluded at this meeting. I happen to agree with the majority and have added myself to the approvers. The is_system_labeled issue was dealt with as another subcase (2006/155). In talking with the TX gatekeeper today, he didn't recall if the package names had been ARCed. I've include them in the interface table. To formally conclude this case, I'd like to call for a formal vote of the members wishing to participating in this case. Since Ed has moved on, unless someone objects, I'll take the case owner's prerogative and include him as an approver. My review of the minutes give me the impression that he would vote to approve. Please find a draft of the opinion below. Please either vote by email, or during ARC business on 2 May. I'll then fix the typos anyone points out and send the opinion out for PSARC review. (Glenn I think I've actually gotten the "which"s and "that"s correct. I'm sure you'll comment if I'm mistaken ;-) Thanks all and thanks again Bill for handling the discussion, Gary.. ======= sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Layered Trusted Solaris Submitted by: Glenn Faden File: PSARC/2002/762/opinion.ms Date: March 22nd 2006 Committee: Gary Winiger, James Carlson, Ed Gould, Glenn Skinner. Abstain: Bill Sommerfeld Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project is the Umbrella for adding Multi-Level Security to Solaris in a layered manor. It is a follow on to the previous releases of Trusted Solaris which were complete independent redeliveries of the underlying Solaris base with multi-level security integrated into them. The layered com- ponent is a set of packages which when added to Solaris con- vert it into a multi-level system. The combination of Solaris and the layered packages is intended to meet the Common Criteria Labeled Security Protection Profile. 2. Decision & Precedence Information This project is approved as specified in references [1] and [2]. This project may be delivered in a patch release of Solaris. This project depends on the following projects and may not be delivered before them. LSARC/2004/109 Trusted Solaris X Server Extension PSARC/2005/060 TSNET: Trusted Networking with Security Labels LSARC/2005/075 Trusted Solaris CDE PSARC/2005/259 Layered Trusted Solaris Label Inter- faces PSARC/2005/573 Solaris Trusted Extensions for Printing PSARC/2002/762 Copyright 2006 Sun Microsystems - 2 - PSARC/2005/691 Trusted Extensions for Device Alloca- tion PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling UIRB/2006/006 Trusted Extensions for Solaris Manage- ment Console LSARC/2006/007 Trusted Extensions for Solaris Manage- ment Console PSARC/2006/009 Labeled Auditing PSARC/2006/155 Trusted Extensions RBAC Changes PSARC/2006/191 is_system_labeled 3. Interfaces The project exports the following interfaces. __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions | | | | Privileges | | |__________________|_________________|___________________________| |net_bindmlp | Stable | TNET kernel interpreted| | | | privileges PSARC/2005/060| |net_mac_aware | Stable | | | | | | |sys_trans_label | Stable | svc:/system/labeld inter-| | | | preted privilege| | | | PSARC/2005/259 | | | | | |win_colormap | Stable | X Server interpreted| | | | privileges LSARC/2004/109| |win_config | Stable | | |win_dac_read | Stable | | |win_dac_write | Stable | | |win_devices | Stable | | |win_dga | Stable | | |win_downgrade_sl | Stable | | |win_fontpath | Stable | | |win_mac_read | Stable | | |win_mac_write | Stable | | |win_selection | Stable | | |win_upgrade_sl | Stable | | |__________________|_________________|___________________________| | | | | |__________________|_________________|___________________________| PSARC/2002/762 Copyright 2006 Sun Microsystems - 3 - __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions Package| | | | Names | | |__________________|_________________|___________________________| |SUNWtsr | Stable | Core consolidation | |SUNWtsu | Stable | | |SUNWtsc | Stable | | |SUNWtsmc | Stable | | |SUNWtsman | Stable | | | | | | |SUNWwxwts | Stable | X Windows consolidation | |SUNWxw-tsol-module| Stable | | | | | | |SUNWdttsu | Stable | CDE consolidation | |SUNWdttsr | Stable | | |SUNWdttshelp | Stable | | | | | | |SUNWmgts | Stable | Admin (SMC) consolidation| |__________________|_________________|___________________________| 4. Opinion The "Layered Trusted Solaris" project started out as an Umbrella for what was to be a unbundleded separately priced layer on top of Solaris. During the life of the project, it was decided to bundle it with Solaris and to rename the pro- duct to Solaris Trusted Extensions. The subprojects define a number of privileges. "Least Privilege for Solaris" (PSARC/2002/118) defines a mechanism for adding unbundled privileges to the default privilege set. The project team asserted not only that were there bugs in the unbundled privileges support which were not being addressed by the responsible engineer, but also that by the nature of the project it was de facto bundled and it was only prior marketing requirements which had lead to the perspective of an unbundled delivery. Upon review of the various points [2], the committee, agreed with the pro- ject team and approved bundling the privileges within Solaris. 5. Minority Opinion(s) None. 6. Advisory Information None. PSARC/2002/762 Copyright 2006 Sun Microsystems - 4 - 7. Appendices 7.1. Appendix A: Technical Changes Required None. 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/2002/762. 1. Umbrella Materials File: inception.materials/* 3. Email discussion File: mail PSARC/2002/762 Copyright 2006 Sun Microsystems From sacadmin Wed May 2 11:46:35 2007 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l42IkZVf029081 for ; Wed, 2 May 2007 11:46:35 -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 l42IlA9N020528; Wed, 2 May 2007 11:47:10 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l42IlA43020527; Wed, 2 May 2007 11:47:10 -0700 (PDT) Date: Wed, 2 May 2007 11:47:10 -0700 (PDT) From: Gary Winiger Message-Id: <200705021847.l42IlA43020527@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com Cc: glenn.faden@sun.com Subject: Opinion for review: PSARC/2002/762 - Layered Trusted Solaris Status: RO Content-Length: 7947 Please review the attachec opinion by 9 May, 2007. For your viewing pleasure, a pdf is in the case directory. Thanks, Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Layered Trusted Solaris Submitted by: Glenn Faden File: PSARC/2002/762/opinion.ms Date: March 22nd 2006 Committee: Gary Winiger, James Carlson, Ed Gould, Glenn Skinner, Bill Sommerfeld. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project is the Umbrella for adding Multi-Level Security to Solaris in a layered manor. It is a follow on to the previous releases of Trusted Solaris which were complete independent redeliveries of the underlying Solaris base with multi-level security integrated into them. The layered com- ponent is a set of packages which when added to Solaris con- vert it into a multi-level system. The combination of Solaris and the layered packages is intended to meet the Common Criteria Labeled Security Protection Profile. 2. Decision & Precedence Information This project is approved as specified in references [1] and [2]. This project may be delivered in a patch release of Solaris. This project depends on the following projects and may not be delivered before them. LSARC/2004/109 Trusted Solaris X Server Extension PSARC/2005/060 TSNET: Trusted Networking with Security Labels LSARC/2005/075 Trusted Solaris CDE PSARC/2005/259 Layered Trusted Solaris Label Inter- faces PSARC/2005/573 Solaris Trusted Extensions for Printing PSARC/2002/762 Copyright 2006 Sun Microsystems - 2 - PSARC/2005/691 Trusted Extensions for Device Alloca- tion PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling UIRB/2006/006 Trusted Extensions for Solaris Manage- ment Console LSARC/2006/007 Trusted Extensions for Solaris Manage- ment Console PSARC/2006/009 Labeled Auditing PSARC/2006/155 Trusted Extensions RBAC Changes PSARC/2006/191 is_system_labeled 3. Interfaces The project exports the following interfaces. __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions | | | | Privileges | | |__________________|_________________|___________________________| |net_bindmlp | Stable | TNET kernel interpreted| | | | privileges PSARC/2005/060| |net_mac_aware | Stable | | | | | | |sys_trans_label | Stable | svc:/system/labeld inter-| | | | preted privilege| | | | PSARC/2005/259 | | | | | |win_colormap | Stable | X Server interpreted| | | | privileges LSARC/2004/109| |win_config | Stable | | |win_dac_read | Stable | | |win_dac_write | Stable | | |win_devices | Stable | | |win_dga | Stable | | |win_downgrade_sl | Stable | | |win_fontpath | Stable | | |win_mac_read | Stable | | |win_mac_write | Stable | | |win_selection | Stable | | |win_upgrade_sl | Stable | | |__________________|_________________|___________________________| | | | | |__________________|_________________|___________________________| PSARC/2002/762 Copyright 2006 Sun Microsystems - 3 - __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions Package| | | | Names | | |__________________|_________________|___________________________| |SUNWtsr | Stable | Core consolidation | |SUNWtsu | Stable | | |SUNWtsc | Stable | | |SUNWtsmc | Stable | | |SUNWtsman | Stable | | | | | | |SUNWwxwts | Stable | X Windows consolidation | |SUNWxw-tsol-module| Stable | | | | | | |SUNWdttsu | Stable | CDE consolidation | |SUNWdttsr | Stable | | |SUNWdttshelp | Stable | | | | | | |SUNWmgts | Stable | Admin (SMC) consolidation| |__________________|_________________|___________________________| 4. Opinion The "Layered Trusted Solaris" project started out as an Umbrella for what was to be a unbundleded separately priced layer on top of Solaris. During the life of the project, it was decided to bundle it with Solaris and to rename the pro- duct to Solaris Trusted Extensions. The subprojects define a number of privileges. "Least Privilege for Solaris" (PSARC/2002/118) defines a mechanism for adding unbundled privileges to the default privilege set. The project team asserted not only that were there bugs in the unbundled privileges support which were not being addressed by the responsible engineer, but also that by the nature of the project it was de facto bundled and it was only prior marketing requirements which had lead to the perspective of an unbundled delivery. Upon review of the various points [2], the committee, agreed with the pro- ject team and approved bundling the privileges within Solaris. 5. Minority Opinion(s) None. 6. Advisory Information None. PSARC/2002/762 Copyright 2006 Sun Microsystems - 4 - 7. Appendices 7.1. Appendix A: Technical Changes Required None. 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/2002/762. 1. Umbrella Materials File: inception.materials/* 3. Email discussion File: mail PSARC/2002/762 Copyright 2006 Sun Microsystems From sac-owner Wed May 9 16:19:31 2007 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l49NJVYB008052 for ; Wed, 9 May 2007 16:19: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 l49NKAGV000283; Wed, 9 May 2007 16:20:10 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l49NKAiI000282; Wed, 9 May 2007 16:20:10 -0700 (PDT) Date: Wed, 9 May 2007 16:20:10 -0700 (PDT) From: Gary Winiger Message-Id: <200705092320.l49NKAiI000282@marduk.eng.sun.com> To: sac-review@sac.sfbay.sun.com Cc: glenn.faden@sun.com Subject: Opinion for SAC review: PSARC/2002/762 - Layered Trusted Solaris Status: RO Content-Length: 7937 Please review the attached opinion by 05/16/2007. For your viewing pleasure, a pdf is in the case directory. Thanks, Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Layered Trusted Solaris Submitted by: Glenn Faden File: PSARC/2002/762/opinion.ms Date: March 22nd 2006 Committee: Gary Winiger, James Carlson, Ed Gould, Glenn Skinner, Bill Sommerfeld. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project is the Umbrella for adding Multi-Level Security to Solaris in a layered manor. It is a follow on to the previous releases of Trusted Solaris which were complete independent redeliveries of the underlying Solaris base with multi-level security integrated into them. The layered com- ponent is a set of packages which when added to Solaris con- vert it into a multi-level system. The combination of Solaris and the layered packages is intended to meet the Common Criteria Labeled Security Protection Profile. 2. Decision & Precedence Information This project is approved as specified in references [1] and [2]. This project may be delivered in a patch release of Solaris. This project depends on the following projects and may not be delivered before them. LSARC/2004/109 Trusted Solaris X Server Extension PSARC/2005/060 TSNET: Trusted Networking with Security Labels LSARC/2005/075 Trusted Solaris CDE PSARC/2005/259 Layered Trusted Solaris Label Inter- faces PSARC/2005/573 Solaris Trusted Extensions for Printing PSARC/2002/762 Copyright 2006 Sun Microsystems - 2 - PSARC/2005/691 Trusted Extensions for Device Alloca- tion PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling UIRB/2006/006 Trusted Extensions for Solaris Manage- ment Console LSARC/2006/007 Trusted Extensions for Solaris Manage- ment Console PSARC/2006/009 Labeled Auditing PSARC/2006/155 Trusted Extensions RBAC Changes PSARC/2006/191 is_system_labeled 3. Interfaces The project exports the following interfaces. __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions | | | | Privileges | | |__________________|_________________|___________________________| |net_bindmlp | Stable | TNET kernel interpreted| | | | privileges PSARC/2005/060| |net_mac_aware | Stable | | | | | | |sys_trans_label | Stable | svc:/system/labeld inter-| | | | preted privilege| | | | PSARC/2005/259 | | | | | |win_colormap | Stable | X Server interpreted| | | | privileges LSARC/2004/109| |win_config | Stable | | |win_dac_read | Stable | | |win_dac_write | Stable | | |win_devices | Stable | | |win_dga | Stable | | |win_downgrade_sl | Stable | | |win_fontpath | Stable | | |win_mac_read | Stable | | |win_mac_write | Stable | | |win_selection | Stable | | |win_upgrade_sl | Stable | | |__________________|_________________|___________________________| | | | | |__________________|_________________|___________________________| PSARC/2002/762 Copyright 2006 Sun Microsystems - 3 - __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions Package| | | | Names | | |__________________|_________________|___________________________| |SUNWtsr | Stable | Core consolidation | |SUNWtsu | Stable | | |SUNWtsc | Stable | | |SUNWtsmc | Stable | | |SUNWtsman | Stable | | | | | | |SUNWwxwts | Stable | X Windows consolidation | |SUNWxw-tsol-module| Stable | | | | | | |SUNWdttsu | Stable | CDE consolidation | |SUNWdttsr | Stable | | |SUNWdttshelp | Stable | | | | | | |SUNWmgts | Stable | Admin (SMC) consolidation| |__________________|_________________|___________________________| 4. Opinion The "Layered Trusted Solaris" project started out as an Umbrella for what was to be a unbundleded separately priced layer on top of Solaris. During the life of the project, it was decided to bundle it with Solaris and to rename the pro- duct to Solaris Trusted Extensions. The subprojects define a number of privileges. "Least Privilege for Solaris" (PSARC/2002/118) defines a mechanism for adding unbundled privileges to the default privilege set. The project team asserted not only that were there bugs in the unbundled privileges support which were not being addressed by the responsible engineer, but also that by the nature of the project it was de facto bundled and it was only prior marketing requirements which had lead to the perspective of an unbundled delivery. Upon review of the various points [2], the committee, agreed with the pro- ject team and approved bundling the privileges within Solaris. 5. Minority Opinion(s) None. 6. Advisory Information None. PSARC/2002/762 Copyright 2006 Sun Microsystems - 4 - 7. Appendices 7.1. Appendix A: Technical Changes Required None. 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/2002/762. 1. Umbrella Materials File: inception.materials/* 3. Email discussion File: mail PSARC/2002/762 Copyright 2006 Sun Microsystems From sac-owner Wed May 16 17:50:50 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4H0onOu023765 for ; Wed, 16 May 2007 17:50:49 -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 l4H0nfmr005543; Wed, 16 May 2007 17:49:41 -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 l4H0pYHu009230; Wed, 16 May 2007 17:51:34 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l4H0pYtq009229; Wed, 16 May 2007 17:51:34 -0700 (PDT) Date: Wed, 16 May 2007 17:51:34 -0700 (PDT) From: Gary Winiger Message-Id: <200705170051.l4H0pYtq009229@marduk.eng.sun.com> To: sac-opinion@sac.sfbay.sun.com, solaris-pac-opinion@sun.com Cc: glenn.faden@sun.com Subject: Opinion for archiving: PSARC/2002/762 - Layered Trusted Solaris Status: RO Content-Length: 7741 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Layered Trusted Solaris Submitted by: Glenn Faden File: PSARC/2002/762/opinion.ms Date: March 22nd 2006 Committee: Gary Winiger, James Carlson, Ed Gould, Glenn Skinner, Bill Sommerfeld. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project is the Umbrella for adding Multi-Level Security to Solaris in a layered manner. It is a follow on to the previous releases of Trusted Solaris which were complete independent redeliveries of the underlying Solaris base with multi-level security integrated into them. The layered com- ponent is a set of packages which when added to Solaris con- vert it into a multi-level system. The combination of Solaris and the layered packages is intended to meet the Common Criteria Labeled Security Protection Profile. 2. Decision & Precedence Information This project is approved as specified in references [1] and [2]. This project may be delivered in a patch release of Solaris. This project depends on the following projects and may not be delivered before them. LSARC/2004/109 Trusted Solaris X Server Extension PSARC/2005/060 TSNET: Trusted Networking with Security Labels LSARC/2005/075 Trusted Solaris CDE PSARC/2005/259 Layered Trusted Solaris Label Inter- faces PSARC/2005/573 Solaris Trusted Extensions for Printing PSARC/2002/762 Copyright 2006 Sun Microsystems - 2 - PSARC/2005/691 Trusted Extensions for Device Alloca- tion PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling UIRB/2006/006 Trusted Extensions for Solaris Manage- ment Console LSARC/2006/007 Trusted Extensions for Solaris Manage- ment Console PSARC/2006/009 Labeled Auditing PSARC/2006/155 Trusted Extensions RBAC Changes PSARC/2006/191 is_system_labeled 3. Interfaces The project exports the following interfaces. __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions | | | | Privileges | | |__________________|_________________|___________________________| |net_bindmlp | Stable | TNET kernel interpreted| | | | privileges PSARC/2005/060| |net_mac_aware | Stable | | | | | | |sys_trans_label | Stable | svc:/system/labeld inter-| | | | preted privilege| | | | PSARC/2005/259 | | | | | |win_colormap | Stable | X Server interpreted| | | | privileges LSARC/2004/109| |win_config | Stable | | |win_dac_read | Stable | | |win_dac_write | Stable | | |win_devices | Stable | | |win_dga | Stable | | |win_downgrade_sl | Stable | | |win_fontpath | Stable | | |win_mac_read | Stable | | |win_mac_write | Stable | | |win_selection | Stable | | |win_upgrade_sl | Stable | | |__________________|_________________|___________________________| | | | | |__________________|_________________|___________________________| PSARC/2002/762 Copyright 2006 Sun Microsystems - 3 - __________________________________________________________________ | Interfaces Exported | |__________________|_________________|___________________________| |Interface | Classification | Comments | |__________________|_________________|___________________________| | | Trusted Exten-| | | | sions Package| | | | Names | | |__________________|_________________|___________________________| |SUNWtsr | Stable | Core consolidation | |SUNWtsu | Stable | | |SUNWtsc | Stable | | |SUNWtsmc | Stable | | |SUNWtsman | Stable | | | | | | |SUNWwxwts | Stable | X Windows consolidation | |SUNWxw-tsol-module| Stable | | | | | | |SUNWdttsu | Stable | CDE consolidation | |SUNWdttsr | Stable | | |SUNWdttshelp | Stable | | | | | | |SUNWmgts | Stable | Admin (SMC) consolidation| |__________________|_________________|___________________________| 4. Opinion The "Layered Trusted Solaris" project started out as an Umbrella for what was to be an unbundleded separately priced layer on top of Solaris. During the life of the project, it was decided to bundle it with Solaris and to rename the pro- duct to Solaris Trusted Extensions. The subprojects define a number of privileges. "Least Privilege for Solaris" (PSARC/2002/118) defines a mechanism for adding unbundled privileges to the default privilege set. The project team asserted not only that there were bugs in the unbundled privileges support which were not being addressed by the responsible engineer, but also that by the nature of the project it was de facto bun- dled and it was only prior marketing requirements which had lead to the perspective of an unbundled delivery. Upon review of the various points [2], the committee, agreed with the project team and approved bundling the privileges within Solaris. 5. Minority Opinion(s) None. 6. Advisory Information None. PSARC/2002/762 Copyright 2006 Sun Microsystems - 4 - 7. Appendices 7.1. Appendix A: Technical Changes Required None. 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/2002/762. 1. Umbrella Materials File: inception.materials/* 2. Email discussion File: mail PSARC/2002/762 Copyright 2006 Sun Microsystems