From gww@sac.sfbay.sun.com Wed May 2 20:43:46 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l433hjnk022571 for ; Wed, 2 May 2007 20:43:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l433gjPF001231 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 3 May 2007 11:42:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHG00H034ZBA800@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 May 2007 20:42:47 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHG004CC4ZAK880@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 May 2007 20:42:47 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l433gkGD013272; Wed, 02 May 2007 20:42:46 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l433hhjG022566; Wed, 02 May 2007 20:43:43 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l433hhLB022565; Wed, 02 May 2007 20:43:43 -0700 (PDT) Date: Wed, 02 May 2007 20:43:43 -0700 (PDT) From: Gary Winiger Subject: 2007/254 - Enabling method for Trusted Extensions To: psarc-ext@sun.com Cc: ric.aleshire@sun.com Message-id: <200705030343.l433hhLB022565@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5178 I'm sponsoring this fast track for Ric Aleshire and the TX project team. This is an OpenSolaris case. It updates the TX label translation service, svc:/system/labeld, defined in Layered Trusted Solaris Label Interfaces (PSARC/2005/259) to enable and disable Solaris Trusted Extensions. The previous Unstable interface taxonomy is modified to Uncommitted and a Patch release binding are requested. The timer is set for 10 May, 2007. Gary.. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Background ========== Trusted Extensions (TX) today is an unbundled product delivered via add-on packages in the ExtraValue directory. The source code is in several WOS consolidation: CDE, X, JDS, Admin. There is an additional Trusted Layered Component (TLC) consolidation and significant code is the ON consolidation. Virtually all of this code uses run-time checks so that it is only effective when TX is enabled. Currently, installation of TX packages also serves to enable TX. In particular, TX kernel module lbl_edition maintains a variable that is queried to determined whether TX is enabled (this is needed early in boot code). If this module is installed and loaded then TX is effectively enabled. This was described in is_system_labeled (PSARC/2006/191): Early in boot, the kernel startup() function attempts to load a "sys"-type module named "lbl_edition"; load failures are silently ignored as the module is not expected to be present on an unlabeled system. Shortly thereafter, a single check is made via modgetsymvalue() for the value of the global integer variable "label_services"; if this variable is present and nonzero, the system is assumed to be labeled; if it is either not present (for instance, if the "lbl_edition" module fails to load or fails to define the variable), or zero, the system is assumed to be unlabeled. At that point, the sys_labeling global integer variable, previously initialized to a negative value (indicating an indeterminate state), is set to 0 on an unlabeled system and to a value greater than zero on a labeled system. The lbl_edition module may not be unloaded, and exports no interfaces other than the "label_services" global variable. The lbl_edition module is packaged with other layered Trusted Extensions deliverable files. ... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |kernel/sys/lbl_edition, | (Contracted) | Layered module name| |kernel/sys/amd64/lbl_edition, | Project Private | | |kernel/sys/sparcv9/lbl_edition | | | |label_services | | global variable | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem ======= It is planned to get rid of the ExtraValue directory and deliver all the TX packages in the WOS to be installed with Solaris. As part of work, source from the TLC consolidation will be moved into the ON gate and corresponding packages will be delivered with Solaris. As a result, a new mechanism to enable and disable TX must be created, so that packages may be installed without forcing the system to be labeled. Proposal ======= 1) The svc:/system/labeld service is only shipped in the global zone, is shipped disabled and not enabled by any SMF profile (it was enabled as part of the TX post installation process). Enabling this service will result in the Trusted Extensions feature being enabled. To accomplish this, if TX is not already enabled, the start method for this service will set the following kernel variable in /etc/system: set sys_labeling=1 In addition, it will enable auditing, enable other previously defined TX services (such as svc:/network/tnd and svc:/system/tsol-zones) and perform the other tasks that had been part of the TX packages post installation process. Disabling svc:/system/labeld results in the disabling of Trusted Extensions, and the above variable setting will be removed from /etc/system. 2) The Project Private lbl_edition kernel module, its contents and usage as described in PSARC 2006/191 will no longer exist; it will be removed if found during upgrade. 3) N.B. Not changed by this proposal is the requirement to reboot to enable TX (thus the rationale to use /etc/system to just set the sys_labeling state). The reboot enforces security policies documented for Trusted Extensions. Due to the handling required for unlabeled and labeled data, zones must be deleted before enabling or disabling TX and a reboot is then used to populate kernel data structures with label-related data that must be present from very early in the boot sequence. The svc:/system/labeld service will enforce these zones restrictions; if zones exist during an attempt to enable or disable, appropriate error messages are logged and the service will enter maintenance state, and no other changes will be made. References ========== PSARC 2006/191 - is_system_labeled PSARC 2002/762 - Layered Trusted Solaris PSARC/2005/259 - Layered Trusted Solaris Label Interfaces From Darren.Moffat@sun.com Thu May 3 02:38:42 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l439cg4Z005011 for ; Thu, 3 May 2007 02:38:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l439bgML055204; Thu, 3 May 2007 03:37:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHG00K0RLEVEV00@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 02:37:43 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHG00GNOLETKB50@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 02:37:42 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l439bfIE004339; Thu, 03 May 2007 09:37:41 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHG00B01L9AVZ00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 03 May 2007 10:37:41 +0100 (BST) Received: from [129.150.120.43] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHG002UILEGAD00@d1-emea-09.sun.com>; Thu, 03 May 2007 10:37:34 +0100 (BST) Date: Thu, 03 May 2007 10:37:28 +0100 From: Darren J Moffat Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705030343.l433hhLB022565@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <4639AD58.3080100@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 673 I assume the taxonomy of sys_labeling is either Project Private or Consolidation Private. Other than that minor clarification this looks sufficient to me. I don't have any issue with the reboot requirement since switching between labeled and unlabeled mode is not something we expect to be needed. One thing I would have liked to have seen was sysid support for doing the enabling of TX label services during the install so that we can jumpstart a TX system without requiring postinstall scripts or extra reboots - like we could in previous releases. I don't think this case needs to do that but it would be nice to consider for the future. -- Darren J Moffat From gww@eng.sun.com Thu May 3 08:06:44 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l43F6hHF015339 for ; Thu, 3 May 2007 08:06:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l43F5GLN005052 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Thu, 3 May 2007 23:05:44 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHH0020Z0LKW300@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 May 2007 09:05:44 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHH001NQ0LHV410@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 May 2007 09:05:42 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l43F5eIO026784; Thu, 03 May 2007 08:05:40 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l43F7Dbu021998; Thu, 03 May 2007 08:07:13 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l43F7DNF021997; Thu, 03 May 2007 08:07:13 -0700 (PDT) Date: Thu, 03 May 2007 08:07:13 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: Darren.Moffat@sun.com, gww@sac.sfbay.sun.com Cc: psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <200705031507.l43F7DNF021997@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1694 > I assume the taxonomy of sys_labeling is either Project Private or > Consolidation Private. I thought Ric had captured the essence of the interface table from 2006/191 is_system_labeled. Any how from 2006/291 and unchanged: Interfaces ---------- The following new interfaces are exported as part of the Trusted Extensions project: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |NAME | Classification | Comment | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |is_system_labeled(3c) | Stable | Function in libc | |is_system_labeled(9) | Consolidation | Macro | | | Private | | |sys_labeling | Consolidation | global variable | | | Private | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |SYS_labelsys | Project Private | syscall | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > One thing I would have liked to have seen was sysid support for doing > the enabling of TX label services during the install so that we can > jumpstart a TX system without requiring postinstall scripts or extra > reboots - like we could in previous releases. I don't think this case > needs to do that but it would be nice to consider for the future. Yup, not this case. Please file an RFE. At least for now use the trusted_extensions product. Gary.. From carlsonj@phorcys.east.sun.com Thu May 3 10:58:47 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l43Hwlgi023205 for ; Thu, 3 May 2007 10:58:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l43Hvnua028449; Thu, 3 May 2007 10:57:49 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHH00J038KCKU00@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 10:57:48 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHH00ICR8KBCF20@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 10:57:47 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l43Hvk4F026630; Thu, 03 May 2007 13:57:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l43HvkJI026625; Thu, 03 May 2007 13:57:46 -0400 (EDT) Date: Thu, 03 May 2007 13:57:31 -0400 From: James Carlson Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705030343.l433hhLB022565@sac.sfbay.sun.com> To: Gary Winiger Cc: psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <17978.8843.359971.283646@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> Status: RO Content-Length: 1716 Gary Winiger writes: > 1) The svc:/system/labeld service is only shipped in the global zone, > is shipped disabled and not enabled by any SMF profile (it was enabled > as part of the TX post installation process). > Enabling this service will result in the Trusted Extensions feature > being enabled. To accomplish this, if TX is not already enabled, > the start method for this service will set the following kernel > variable in /etc/system: > set sys_labeling=1 I don't particularly like this answer for several reasons. First, touching /etc/system causes the x86 boot archive to be rebuilt for no good reason, and for those who have "accidents," it causes the system to get into ugly states. Second, it provides a good opportunity for a fat-fingered administrator to end up with TX "half enabled" -- with either the kernel flag enabled or labeld but not both. (The above boot archive issue is one good way to get there, but there are clearly others.) Finally, I had thought that we were going to find a "better way" to enable TX. Can /etc/system, the home of wayward administrative hacks, really be that "better way?" I assume that this is being done because you want to see the kernel labeling flag set very early in boot, but I'd encourage looking for another answer. (No, I'm not going to derail over this, especially as I don't have a replacement waiting in my hip pocket. But I do think this sounds like a good opportunity to look for a cleaner answer.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sommerfeld@sun.com Thu May 3 11:37:38 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l43IbcuE025289 for ; Thu, 3 May 2007 11:37:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l43IadGl009358; Thu, 3 May 2007 11:36:40 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHH00L2BAD33T00@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 11:36:39 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHH00IEKAD1CL40@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 11:36:38 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l43IaV7e028275; Thu, 03 May 2007 14:36:31 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l43IaSRh022263; Thu, 03 May 2007 14:36:28 -0400 (EDT) Date: Thu, 03 May 2007 14:36:27 -0400 From: Bill Sommerfeld Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <17978.8843.359971.283646@gargle.gargle.HOWL> To: James Carlson Cc: Gary Winiger , psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <1178217387.21685.17.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> <17978.8843.359971.283646@gargle.gargle.HOWL> Status: RO Content-Length: 859 On Thu, 2007-05-03 at 13:57 -0400, James Carlson wrote: > I assume that this is being done because you want to see the kernel > labeling flag set very early in boot, but I'd encourage looking for > another answer. It's not just the labelling flag; at present, the DOI must also be known early (see 2007/255). fixing that would require revisiting the representation of sensitivity labels and the handling of DOIs (so that admin_low/admin_high labels would appropriately bracket all other sensitivity labels). > (No, I'm not going to derail over this, especially as I don't have a > replacement waiting in my hip pocket. But I do think this sounds like > a good opportunity to look for a cleaner answer.) my understanding is that a bunch of other artifacts which need to be rearchitected to permit the system to go labelled later in boot. - Bill From carlsonj@phorcys.east.sun.com Thu May 3 11:43:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l43IhclZ025692 for ; Thu, 3 May 2007 11:43:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l43IgYmZ020250; Thu, 3 May 2007 19:42:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHH00I93AN1QG00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 May 2007 11:42:37 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHH00HAMAMYDOB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 May 2007 11:42:35 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l43IgXrL026932; Thu, 03 May 2007 14:42:33 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l43IgX38026929; Thu, 03 May 2007 14:42:33 -0400 (EDT) Date: Thu, 03 May 2007 14:42:33 -0400 From: James Carlson Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <1178217387.21685.17.camel@thunk> To: Bill Sommerfeld Cc: Gary Winiger , psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <17978.11545.708672.732900@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> <17978.8843.359971.283646@gargle.gargle.HOWL> <1178217387.21685.17.camel@thunk> Status: RO Content-Length: 1391 Bill Sommerfeld writes: > On Thu, 2007-05-03 at 13:57 -0400, James Carlson wrote: > > I assume that this is being done because you want to see the kernel > > labeling flag set very early in boot, but I'd encourage looking for > > another answer. > > It's not just the labelling flag; at present, the DOI must also be known > early (see 2007/255). > > fixing that would require revisiting the representation of sensitivity > labels and the handling of DOIs (so that admin_low/admin_high labels > would appropriately bracket all other sensitivity labels). Sure. But that's not what I'm asking about here. > > (No, I'm not going to derail over this, especially as I don't have a > > replacement waiting in my hip pocket. But I do think this sounds like > > a good opportunity to look for a cleaner answer.) > > my understanding is that a bunch of other artifacts which need to be > rearchitected to permit the system to go labelled later in boot. To clarify: I wasn't asking to have the point at which the system "goes labeled" in the boot sequence to be moved around, but rather to look for ways other than /etc/system to do the enabling. It seems a bit ugly. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@Sun.COM Thu May 3 11:58:07 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l43Iw7Ei026663 for ; Thu, 3 May 2007 11:58:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l43Iv7JN028495; Thu, 3 May 2007 11:57:08 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHH00J07BB8QF00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 May 2007 11:57:08 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHH00JGFBB7DU20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 May 2007 11:57:07 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l43ItwW2004107; Thu, 03 May 2007 13:55:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l43ItwI2004106; Thu, 03 May 2007 13:55:58 -0500 (CDT) Date: Thu, 03 May 2007 13:55:58 -0500 From: Nicolas Williams Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <17978.11545.708672.732900@gargle.gargle.HOWL> To: James Carlson Cc: Bill Sommerfeld , Gary Winiger , PSARC-EXT@Sun.COM, ric.aleshire@Sun.COM Message-id: <20070503185557.GI3924@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> <17978.8843.359971.283646@gargle.gargle.HOWL> <1178217387.21685.17.camel@thunk> <17978.11545.708672.732900@gargle.gargle.HOWL> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 686 On Thu, May 03, 2007 at 02:42:33PM -0400, James Carlson wrote: > Bill Sommerfeld writes: > > my understanding is that a bunch of other artifacts which need to be > > rearchitected to permit the system to go labelled later in boot. > > To clarify: I wasn't asking to have the point at which the system > "goes labeled" in the boot sequence to be moved around, but rather to > look for ways other than /etc/system to do the enabling. It seems a > bit ugly. As long as it has to happen early enough in the boot cycle that the enabling has to be present in the boot archive /etc/system seems like as good a solution as we could get... At least sysadmins won't have to edit /etc/system. From gww@eng.sun.com Thu May 3 20:30:30 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l443UTpE014022 for ; Thu, 3 May 2007 20:30:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l443TGIi029715 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 4 May 2007 11:29:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHH00701Z13U200@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 May 2007 21:29:27 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHH00JF8Z12AA90@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 May 2007 21:29:27 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l443TPmF014493; Thu, 03 May 2007 20:29:25 -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 l443Ux5P023136; Thu, 03 May 2007 20:30:59 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l443UxMa023135; Thu, 03 May 2007 20:30:59 -0700 (PDT) Date: Thu, 03 May 2007 20:30:59 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: gww@sac.sfbay.sun.com, james.d.carlson@Sun.COM Cc: psarc-ext@Sun.COM, ric.aleshire@Sun.COM Message-id: <200705040330.l443UxMa023135@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3133 Jim writes: > Gary Winiger writes: > > 1) The svc:/system/labeld service is only shipped in the global zone, > > is shipped disabled and not enabled by any SMF profile (it was enabled > > as part of the TX post installation process). > > Enabling this service will result in the Trusted Extensions feature > > being enabled. To accomplish this, if TX is not already enabled, > > the start method for this service will set the following kernel > > variable in /etc/system: > > set sys_labeling=1 > > I don't particularly like this answer for several reasons. I'm not excited about it either. It seemed to be the least of the various evils that were available. Others suggested moving and removing a kernel module into /kernel/sys and rebooting. I suggested a driver.conf file. What do you suggest? > First, touching /etc/system causes the x86 boot archive to be rebuilt > for no good reason, and for those who have "accidents," it causes the > system to get into ugly states. Hummm, doesn't the present adding a kernel module do the same thing? I judged this as no worse than the current situation. > Second, it provides a good opportunity for a fat-fingered > administrator to end up with TX "half enabled" -- with either the > kernel flag enabled or labeld but not both. (The above boot archive > issue is one good way to get there, but there are clearly others.) Well I guess you could vi /etc/system and mess things up in lots of ways. The admin interface is svcadm enable svc:/system/labeld > Finally, I had thought that we were going to find a "better way" to > enable TX. Can /etc/system, the home of wayward administrative hacks, > really be that "better way?" The project team is happy investigate any suggestions that area experts (and the ARC ;-) is willing to give. I for one hate fiddiling with /etc/system, and didn't find a cleaner solution than to put an administrative front end on it. I challenged the Rampart project team to do things without a reboot, but there just didn't seem to be any way to get the right stuff to happen in the kernel to swap the networking over from an unlabeled state to a labeled state. I suspect the project team is happy to make the Consolidation Private sys_labeling taxonomy Obsolete. > I assume that this is being done because you want to see the kernel > labeling flag set very early in boot, but I'd encourage looking for > another answer. The project team would be happy to have a different answer. Some day it may. That's why the enabling/disabling interface is svcadm of an existing service. A new transient service could be used. It just didn't seem worthwhile when labeld was already there. > (No, I'm not going to derail over this, especially as I don't have a > replacement waiting in my hip pocket. But I do think this sounds like > a good opportunity to look for a cleaner answer.) Sure anything better as the implementation would be gladly accepted. At least for now, I don't believe this case makes things worse. I believe it makes thing better by setting the way to get rid of ExtraValue. Gary.. From Nicolas.Williams@sun.com Thu May 3 20:52:12 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l443qBqv014474 for ; Thu, 3 May 2007 20:52:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l443p5fO000135; Fri, 4 May 2007 04:51:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHI0010B016OP00@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 20:51:06 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHI00L7B016KK30@nwk-avmta-2.sfbay.sun.com>; Thu, 03 May 2007 20:51:06 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l443nvda004830; Thu, 03 May 2007 22:49:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l443nvMh004829; Thu, 03 May 2007 22:49:57 -0500 (CDT) Date: Thu, 03 May 2007 22:49:57 -0500 From: Nicolas Williams Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705040330.l443UxMa023135@marduk.eng.sun.com> To: Gary Winiger Cc: gww@sac.sfbay.sun.com, James.D.Carlson@sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <20070504034956.GD4743@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1197 On Thu, May 03, 2007 at 08:30:59PM -0700, Gary Winiger wrote: > Jim writes: > > I don't particularly like this answer for several reasons. > > I'm not excited about it either. It seemed to be the least of > the various evils that were available. Others suggested moving > and removing a kernel module into /kernel/sys and rebooting. > I suggested a driver.conf file. What do you suggest? Another equally unsatisfying solution: use eeprom/boot args to set the TX enable flag. > > I assume that this is being done because you want to see the kernel > > labeling flag set very early in boot, but I'd encourage looking for > > another answer. > > The project team would be happy to have a different answer. > Some day it may. That's why the enabling/disabling interface > is svcadm of an existing service. A new transient service could > be used. It just didn't seem worthwhile when labeld was already > there. Well, it'd be nice if there was a way to make sure that the service's enabled/disabled state and the kernel variable were in sync. The service can detect the variable being unset and carp, but the reverse cannot be done by the service (since it'd never run). Nico -- From sharon.read@sun.com Fri May 4 09:17:29 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44GHSU1007438 for ; Fri, 4 May 2007 09:17:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44GGFam026706 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Sat, 5 May 2007 00:16:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHI00K09YJG7B00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 09:16:28 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHI00BOGYJF3GC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 09:16:27 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l44GGR3r003494; Fri, 04 May 2007 09:16:27 -0700 (PDT) Received: from [129.146.68.172] (thought.SFBay.Sun.COM [129.146.68.172]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l44GGQT02087; Fri, 04 May 2007 09:16:26 -0700 (PDT) Date: Fri, 04 May 2007 09:07:54 -0700 From: Sharon Veach Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705040330.l443UxMa023135@marduk.eng.sun.com> Cc: gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463B5A5A.3080600@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4pre (X11/20070502) Status: RO Content-Length: 4391 Team: I have questions outside the /etc/system issue. My question is what exactly does the customer see before TX is enabled. Perhaps these questions are appropriate for subcases of this case: 1. TX packages add windowing software, extend the SMC, and add CDE actions. TX adds 2 new desktop prompts to the login window, Solaris Trusted Extensions (CDE) and Solaris Trusted Extensions (JDS). *Are the login prompts going to be visible before the labeling daemon is turned on? Or are they only visible after reboot? *The Trusted_Extensions folder in CDE - is it visible before reboot? *Is TX-specific CDE online help available before reboot? *TX extends the SMC - are TX extensions visible before reboot? 2. Where is the impact on the man pages stated? TX has around 60 TX-specific man pages. None of them state that "This is supported if the system is configured with Trusted Extensions". There is a much larger impact on docs.sun.com documentation, such as the TX User Guide and TX Install & Config. -- Sharon Gary Winiger wrote: > Jim writes: > >> Gary Winiger writes: >> >>> 1) The svc:/system/labeld service is only shipped in the global zone, >>> is shipped disabled and not enabled by any SMF profile (it was enabled >>> as part of the TX post installation process). >>> Enabling this service will result in the Trusted Extensions feature >>> being enabled. To accomplish this, if TX is not already enabled, >>> the start method for this service will set the following kernel >>> variable in /etc/system: >>> set sys_labeling=1 >>> >> I don't particularly like this answer for several reasons. >> > > I'm not excited about it either. It seemed to be the least of > the various evils that were available. Others suggested moving > and removing a kernel module into /kernel/sys and rebooting. > I suggested a driver.conf file. What do you suggest? > > >> First, touching /etc/system causes the x86 boot archive to be rebuilt >> for no good reason, and for those who have "accidents," it causes the >> system to get into ugly states. >> > > Hummm, doesn't the present adding a kernel module do the same thing? > I judged this as no worse than the current situation. > > >> Second, it provides a good opportunity for a fat-fingered >> administrator to end up with TX "half enabled" -- with either the >> kernel flag enabled or labeld but not both. (The above boot archive >> issue is one good way to get there, but there are clearly others.) >> > > Well I guess you could vi /etc/system and mess things up > in lots of ways. The admin interface is > svcadm enable svc:/system/labeld > > >> Finally, I had thought that we were going to find a "better way" to >> enable TX. Can /etc/system, the home of wayward administrative hacks, >> really be that "better way?" >> > > The project team is happy investigate any suggestions that > area experts (and the ARC ;-) is willing to give. I for one > hate fiddiling with /etc/system, and didn't find a cleaner > solution than to put an administrative front end on it. > I challenged the Rampart project team to do things without > a reboot, but there just didn't seem to be any way to get > the right stuff to happen in the kernel to swap the networking > over from an unlabeled state to a labeled state. > I suspect the project team is happy to make the Consolidation Private > sys_labeling taxonomy Obsolete. > > >> I assume that this is being done because you want to see the kernel >> labeling flag set very early in boot, but I'd encourage looking for >> another answer. >> > > The project team would be happy to have a different answer. > Some day it may. That's why the enabling/disabling interface > is svcadm of an existing service. A new transient service could > be used. It just didn't seem worthwhile when labeld was already > there. > > >> (No, I'm not going to derail over this, especially as I don't have a >> replacement waiting in my hip pocket. But I do think this sounds like >> a good opportunity to look for a cleaner answer.) >> > > Sure anything better as the implementation would be gladly > accepted. At least for now, I don't believe this case > makes things worse. I believe it makes thing better by > setting the way to get rid of ExtraValue. > > Gary.. > > From Glenn.Faden@sun.com Fri May 4 09:29:31 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44GTUGa007867 for ; Fri, 4 May 2007 09:29:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44GSR04029985; Sat, 5 May 2007 00:28:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHI00601Z3GR400@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 09:28:28 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHI00I34Z3F2TA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 09:28:27 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44GSRlK025420; Fri, 04 May 2007 09:28:27 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHI00A01Z0ZI800@d1-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Fri, 04 May 2007 09:28:27 -0700 (PDT) Received: from [129.150.17.100] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHI0041JZ3EJMUD@d1-sfbay-09.sun.com>; Fri, 04 May 2007 09:28:27 -0700 (PDT) Date: Fri, 04 May 2007 09:28:17 -0700 From: Glenn Faden Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B5A5A.3080600@sun.com> Sender: Glenn.Faden@sun.com To: Sharon Veach Cc: gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463B5F21.3040404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <463B5A5A.3080600@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Status: RO Content-Length: 1736 Sharon Veach wrote: > Team: > > I have questions outside the /etc/system issue. My question is what > exactly does the customer see > before TX is enabled. Good point! I don't think we have this quite figured out yet. > Perhaps these questions are appropriate for subcases of this case: > > 1. TX packages add windowing software, extend the SMC, and add CDE > actions. > TX adds 2 new desktop prompts to the login window, > Solaris Trusted Extensions (CDE) and Solaris Trusted Extensions (JDS). > *Are the login prompts going to be visible before the labeling daemon > is turned on? Much of the window system behavior depends on whether the X server believes TSOL is enabled. So the extra login prompts won't show up. > Or are they only visible after reboot? *The Trusted_Extensions > folder in CDE - is it visible before reboot? I assume that the TX folder in CDE will show up even if TX is disabled. > *Is TX-specific CDE online help available before reboot? Again, I expect it would be there. Just like man pages. > *TX extends the SMC - are TX extensions visible before reboot? No, these won't show up unless you select a TX toolbox. But, the choice for a TX toolbox would be there. > > 2. Where is the impact on the man pages stated? TX has around 60 > TX-specific man pages. None of them > state that "This is supported if the system is configured with > Trusted Extensions". There > is a much larger impact on docs.sun.com documentation, such as the TX > User Guide and TX Install & Config. I assume the man pages would be there, too. Obviously he docs need to state how to enable and disable TX. The issue of mapping TS packages to metaclusters also needs to be resolved. --Glenn From alan.coopersmith@sun.com Fri May 4 09:58:06 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44Gw6Sh009083 for ; Fri, 4 May 2007 09:58:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44Gv6rs023948 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 4 May 2007 09:57:08 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ00L130F7M600@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 10:57:07 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ006G10F78J90@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 10:57:07 -0600 (MDT) Received: from [192.168.0.101] (vpn-129-150-20-40.SFBay.Sun.COM [129.150.20.40]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l44Gv2x0010364; Fri, 04 May 2007 09:57:05 -0700 (PDT) Date: Fri, 04 May 2007 09:55:55 -0700 From: Alan Coopersmith Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B5F21.3040404@sun.com> To: Glenn Faden Cc: Sharon Veach , gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463B659B.8070301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <463B5A5A.3080600@sun.com> <463B5F21.3040404@sun.com> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Status: RO Content-Length: 954 Glenn Faden wrote: > Sharon Veach wrote: >> 1. TX packages add windowing software, extend the SMC, and add CDE >> actions. >> TX adds 2 new desktop prompts to the login window, >> Solaris Trusted Extensions (CDE) and Solaris Trusted Extensions (JDS). >> *Are the login prompts going to be visible before the labeling daemon >> is turned on? > > Much of the window system behavior depends on whether the X server > believes TSOL is enabled. So the extra login prompts won't show up. So you'll be modifying dtlogin & gdm to not display those when the xtsol extension is not present? (Right now, I believe they are shown as soon as the files are installed - it's just that the session files are only installed with the TX package set that keeps them hidden today.) I expect this will be covered in a follow-on case to LSARC, right? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From will.young@sun.com Fri May 4 10:53:10 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44HrAsc010945 for ; Fri, 4 May 2007 10:53:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44HqAL2026173; Fri, 4 May 2007 11:52:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ001072YZGZ00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 10:52:11 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00LKE2YZJW50@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 10:52:11 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44HqASx023546; Fri, 04 May 2007 17:52:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHJ00E012ST2P00@mail-amer.sun.com> (original mail from will.young@sun.com); Fri, 04 May 2007 11:52:10 -0600 (MDT) Received: from [129.150.64.253] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHJ004SS2XN6RY8@mail-amer.sun.com>; Fri, 04 May 2007 11:51:56 -0600 (MDT) Date: Fri, 04 May 2007 13:48:24 -0400 From: will young Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <20070504034956.GD4743@Sun.COM> Sender: William.Young@sun.com To: Nicolas Williams Cc: Gary Winiger , gww@sac.sfbay.sun.com, james.d.carlson@sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463B71E8.8060504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> User-Agent: Thunderbird 1.5.0.9 (X11/20061227) Status: RO Content-Length: 1541 Nicolas Williams wrote: > > Well, it'd be nice if there was a way to make sure that the service's > enabled/disabled state and the kernel variable were in sync. The > service can detect the variable being unset and carp, but the reverse > cannot be done by the service (since it'd never run). Perhaps this is correct though. The kernel is in no way dependent on this service, and a labeled ON should function without it. (I.e. an open solaris project could provide its own labeld or one could rely exclusively on hex labels.) But labeld has no place on an unlabeled system. The real bootstrap contradiction is kernel labeling state and kernel SYSTEM_DOI must exist before processes but need help from the tnr database that is updated by processes that typically run only when the system is labeled and need help from naming. The most appropriate way to find out if the system is labeled and its SYSTEM_DOI is to resolve its primary IP from its node name and look it up in tnrhdb to get it's tnrhtp. Any other interfaces are then invalid if their DOI differs. I would therefore prefer to see tnctl always runnable, and this lookup occur on shutdown to update a persistent DOI (or lack of a DOI for unlabeled systems) to determine the state for the next system reboot. This would require a labeled system admin to add a tnrhtp and tnrhdb entry and restart tnctl to enable labeling on reboot. A future case would then be to add dhcp tags, and modify native ldap to be able to work with zero host configuration. -Will From rica@domus.sfbay.sun.com Fri May 4 11:02:58 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44I2vF7011805 for ; Fri, 4 May 2007 11:02:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44I1qTt012774 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 May 2007 19:01:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ00E033F6HR00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 11:01:54 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00EH83F65P00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 11:01:54 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l44I1rED006222; Fri, 04 May 2007 11:01:53 -0700 (PDT) Received: (from rica@localhost) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) id l44I1qQ03910; Fri, 04 May 2007 11:01:52 -0700 (PDT) Date: Fri, 04 May 2007 11:01:52 -0700 (PDT) From: Ric Aleshire Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: Sharon Veach Cc: gww@sac.sfbay.sun.com, psarc-ext@sun.com, Glenn.Faden@sun.com, Alan.Coopersmith@sun.com Message-id: <200705041801.l44I1qQ03910@domus.sfbay.sun.com> MIME-version: 1.0 Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2491 I should clarify that this case doesn't address Sharon's issues; it's limited (re)defining the enable/disable mechanism as the first step to migrating TX from ExtraValue to the WOS. The questions related to windowing will be resolved before the X/CDE/JDS packages are "moved", and I assume Alan is correct about potential additional ARC cases... FYI some man page changes (relating to TLC packages) are addressed in open bug 6541853. I'll update to note the issue about adding "valid if TX enabled" tags. And changes to TX install docs will also be needed but no work has started there yet. -Ric Glenn Faden wrote: > Sharon Veach wrote: > > > Team: > > > > I have questions outside the /etc/system issue. My question is what > > exactly does the customer see > > before TX is enabled. > > > Good point! I don't think we have this quite figured out yet. > > > Perhaps these questions are appropriate for subcases of this case: > > > > 1. TX packages add windowing software, extend the SMC, and add CDE > > actions. > > TX adds 2 new desktop prompts to the login window, > > Solaris Trusted Extensions (CDE) and Solaris Trusted Extensions (JDS). > > *Are the login prompts going to be visible before the labeling daemon > > is turned on? > > Much of the window system behavior depends on whether the X server > believes TSOL is enabled. So the extra login prompts won't show up. > > > Or are they only visible after reboot? *The Trusted_Extensions > > folder in CDE - is it visible before reboot? > > I assume that the TX folder in CDE will show up even if TX is disabled. > > > *Is TX-specific CDE online help available before reboot? > > Again, I expect it would be there. Just like man pages. > > > *TX extends the SMC - are TX extensions visible before reboot? > > No, these won't show up unless you select a TX toolbox. But, the choice > for a TX toolbox would be there. > > > > > 2. Where is the impact on the man pages stated? TX has around 60 > > TX-specific man pages. None of them > > state that "This is supported if the system is configured with > > Trusted Extensions". There > > is a much larger impact on docs.sun.com documentation, such as the TX > > User Guide and TX Install & Config. > > I assume the man pages would be there, too. Obviously he docs need to > state how to enable and disable TX. > > The issue of mapping TS packages to metaclusters also needs to be resolved. > > > > --Glenn From Glenn.Faden@sun.com Fri May 4 11:11:49 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44IBn5u012050 for ; Fri, 4 May 2007 11:11:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44IAmM1014166; Fri, 4 May 2007 11:10:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ00F1W3U0HU00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 11:10:48 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00EXO3TZ5N00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 11:10:47 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44IAlxO010645; Fri, 04 May 2007 11:10:47 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHJ00H013CYZ900@d1-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Fri, 04 May 2007 11:10:47 -0700 (PDT) Received: from [129.150.17.100] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHJ006Y83TPRCYL@d1-sfbay-09.sun.com>; Fri, 04 May 2007 11:10:38 -0700 (PDT) Date: Fri, 04 May 2007 11:10:27 -0700 From: Glenn Faden Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B659B.8070301@sun.com> Sender: Glenn.Faden@sun.com To: Alan Coopersmith Cc: Sharon Veach , gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463B7713.60208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <463B5A5A.3080600@sun.com> <463B5F21.3040404@sun.com> <463B659B.8070301@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Status: RO Content-Length: 1562 I think the current implementation already handles this correctly. The code to load the extra TSOL session config files is conditional based on whether the Xserver has the SUN_TSOL module loaded. The loading of that module is conditional based on the "is_system_labeled" setting. This behavior can be verified by creating a custom xorg.conf file and not including the "Load xtsol" setting in Module section. So the real question is how to handle the presense of the xtsol module in user-customized xorg.conf files. Is it better to edit the user's file, or to ignore the setting, and just do the right thing. I think the latter is preferable. --Glenn Alan Coopersmith wrote: > Glenn Faden wrote: > >> Sharon Veach wrote: >> >>> 1. TX packages add windowing software, extend the SMC, and add CDE >>> actions. >>> TX adds 2 new desktop prompts to the login window, >>> Solaris Trusted Extensions (CDE) and Solaris Trusted Extensions >>> (JDS). *Are the login prompts going to be visible before the >>> labeling daemon is turned on? >> >> >> Much of the window system behavior depends on whether the X server >> believes TSOL is enabled. So the extra login prompts won't show up. > > > So you'll be modifying dtlogin & gdm to not display those when the xtsol > extension is not present? (Right now, I believe they are shown as soon > as the files are installed - it's just that the session files are only > installed with the TX package set that keeps them hidden today.) > > I expect this will be covered in a follow-on case to LSARC, right? > From alan.coopersmith@sun.com Fri May 4 11:37:18 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44IbGL1012768 for ; Fri, 4 May 2007 11:37:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44IaBH5014176 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Sat, 5 May 2007 02:36:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ0030150FU600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 11:36:15 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00LOC50EK090@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 May 2007 11:36:14 -0700 (PDT) Received: from [192.168.0.101] (vpn-129-150-20-40.SFBay.Sun.COM [129.150.20.40]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l44IaA9J003862; Fri, 04 May 2007 11:36:13 -0700 (PDT) Date: Fri, 04 May 2007 11:35:03 -0700 From: Alan Coopersmith Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B7713.60208@sun.com> To: Glenn Faden Cc: Sharon Veach , gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463B7CD7.9050205@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <463B5A5A.3080600@sun.com> <463B5F21.3040404@sun.com> <463B659B.8070301@sun.com> <463B7713.60208@sun.com> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Status: RO Content-Length: 1092 Glenn Faden wrote: > I think the current implementation already handles this correctly. The code to load the extra TSOL session config files is conditional based on whether the Xserver has the SUN_TSOL module loaded. The only tsol code I saw in dtlogin was to start tsoldtlabel first when the system is labeled. I don't see any that checks for TSOL before determining which sessions to list as options on the login screen. > So the real question is how to handle the presense of the xtsol module > in user-customized xorg.conf files. Is it better to edit the user's > file, or to ignore the setting, and just do the right thing. I think the > latter is preferable. I forgot to cc you (though I did cc Lok) on the mail I sent last night about the change going into Xorg 7.3 that will solve this problem. (The xorg.conf file will specify modules to add or remove from the default list, instead of containing the complete list of modules replacing the default list.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From carlsonj@phorcys.east.sun.com Fri May 4 11:44:57 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44IivrW012971 for ; Fri, 4 May 2007 11:44:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44IhwFx022142; Fri, 4 May 2007 11:43:58 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ004035DA3W00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 11:43:58 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00LEA5D9K0A0@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 11:43:57 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l44IhtuC001493; Fri, 04 May 2007 14:43:55 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l44Iht23001490; Fri, 04 May 2007 14:43:55 -0400 (EDT) Date: Fri, 04 May 2007 14:43:55 -0400 From: James Carlson Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B71E8.8060504@sun.com> To: will young Cc: Nicolas Williams , Gary Winiger , gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <17979.32491.345648.420971@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> Status: RO Content-Length: 887 will young writes: > A future case would then be to add dhcp tags, and modify native ldap to > be able to work with zero host configuration. Given zero-configuration as a direction (and I agree it's a good one), this means that you really do not want to have the default system DOI or enable-labeling flag tucked away in /etc/system or in any kernel module. Instead, I think it needs to be either an eeprom property or a kernel(1M) flag. The big benefit from doing that is that it integrates with OBP and GRUB nicely. Users can set up menu entries that'll boot with and without TX, as desired, as well as jumpstart in a (I hope) fairly straightforward way. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Fri May 4 12:17:53 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44JHq6v014296 for ; Fri, 4 May 2007 12:17:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44JGl1j027375; Sat, 5 May 2007 03:16:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ006036W04E00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 12:16:48 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00LI76VZJUE0@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 12:16:47 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l44JFbOU006021; Fri, 04 May 2007 14:15:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l44JFaPK006020; Fri, 04 May 2007 14:15:36 -0500 (CDT) Date: Fri, 04 May 2007 14:15:36 -0500 From: Nicolas Williams Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <17979.32491.345648.420971@gargle.gargle.HOWL> To: James Carlson Cc: will young , Gary Winiger , gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <20070504191536.GB6007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 812 On Fri, May 04, 2007 at 02:43:55PM -0400, James Carlson wrote: > Instead, I think it needs to be either an eeprom property or a > kernel(1M) flag. The big benefit from doing that is that it > integrates with OBP and GRUB nicely. Users can set up menu entries > that'll boot with and without TX, as desired, as well as jumpstart in > a (I hope) fairly straightforward way. So why did I think that was as bad as /etc/system? Perhaps because on SPARC it's too easy to override kernel options when at the OBP ok prompt and to miss that this host requires the TX enable flag? But it's just an eeprom setting then that problem goes away. And the labeld service can detect the inconsistency early enough to stop booting (maybe it should be a milestone?). For x86/64 I think I'd prefer a kernel option. Nico -- From Mark.Thacker@sun.com Fri May 4 12:42:43 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44JggDB014870 for ; Fri, 4 May 2007 12:42:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44JfcvZ007392; Sat, 5 May 2007 03:41:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ0070581H7M00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 12:41:41 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00LUG81GJWE0@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 12:41:40 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44Jfe3V024271; Fri, 04 May 2007 19:41:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHJ00C017EQWQ00@mail-amer.sun.com> (original mail from Mark.Thacker@Sun.COM); Fri, 04 May 2007 13:41:40 -0600 (MDT) Received: from [192.168.123.168] ([76.184.250.100]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHJ000SP81FDBS2@mail-amer.sun.com>; Fri, 04 May 2007 13:41:40 -0600 (MDT) Date: Fri, 04 May 2007 14:41:37 -0500 From: Mark Thacker Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <20070504191536.GB6007@Sun.COM> Sender: Mark.Thacker@sun.com To: Nicolas Williams Cc: James Carlson , will young , Gary Winiger , gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463B8C71.5060208@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_r49rXUKzRBN/cx/+GF/W2A)" X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> <20070504191536.GB6007@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) Status: RO Content-Length: 3207 This is a multi-part message in MIME format. --Boundary_(ID_r49rXUKzRBN/cx/+GF/W2A) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT This may or may not help, but for Update 5, there is still a plan of record to integrate Newboot for SPARC systems into the OS. This should allow for consistency between SPARC and x86/x64 systems for configuring boot-time parameters. Since the integrated TX is targeting no earlier than Update 5, it might make sense to utilize Newboot for SPARC and x86/x64. Nicolas Williams wrote: > On Fri, May 04, 2007 at 02:43:55PM -0400, James Carlson wrote: > >> Instead, I think it needs to be either an eeprom property or a >> kernel(1M) flag. The big benefit from doing that is that it >> integrates with OBP and GRUB nicely. Users can set up menu entries >> that'll boot with and without TX, as desired, as well as jumpstart in >> a (I hope) fairly straightforward way. >> > > So why did I think that was as bad as /etc/system? > > Perhaps because on SPARC it's too easy to override kernel options when > at the OBP ok prompt and to miss that this host requires the TX enable > flag? But it's just an eeprom setting then that problem goes away. And > the labeld service can detect the inconsistency early enough to stop > booting (maybe it should be a milestone?). > > For x86/64 I think I'd prefer a kernel option. > > Nico > --Boundary_(ID_r49rXUKzRBN/cx/+GF/W2A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT This may or may not help, but for Update 5, there is still a plan of record to integrate Newboot for SPARC systems into the OS.  This should allow for consistency between SPARC and x86/x64 systems for configuring boot-time parameters.

Since the integrated TX is targeting no earlier than Update 5, it might make sense to utilize Newboot for SPARC and x86/x64.

Nicolas Williams wrote: 
On Fri, May 04, 2007 at 02:43:55PM -0400, James Carlson wrote:
  
Instead, I think it needs to be either an eeprom property or a
kernel(1M) flag.  The big benefit from doing that is that it
integrates with OBP and GRUB nicely.  Users can set up menu entries
that'll boot with and without TX, as desired, as well as jumpstart in
a (I hope) fairly straightforward way.
    

So why did I think that was as bad as /etc/system?

Perhaps because on SPARC it's too easy to override kernel options when
at the OBP ok prompt and to miss that this host requires the TX enable
flag?  But it's just an eeprom setting then that problem goes away.  And
the labeld service can detect the inconsistency early enough to stop
booting (maybe it should be a milestone?).

For x86/64 I think I'd prefer a kernel option.

Nico
--Boundary_(ID_r49rXUKzRBN/cx/+GF/W2A)-- From Glenn.Faden@sun.com Fri May 4 13:02:28 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44K2RBm015746 for ; Fri, 4 May 2007 13:02:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44K1ITi014402; Sat, 5 May 2007 04:01:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ0080D8YB7600@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 13:01:23 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ007JC8YAII20@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 13:01:22 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44K1M4P023736; Fri, 04 May 2007 13:01:22 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHJ00M018VHXR00@d1-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Fri, 04 May 2007 13:01:22 -0700 (PDT) Received: from [129.150.17.100] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHJ004LG8Y8JM0G@d1-sfbay-09.sun.com>; Fri, 04 May 2007 13:01:21 -0700 (PDT) Date: Fri, 04 May 2007 13:01:10 -0700 From: Glenn Faden Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B7CD7.9050205@sun.com> Sender: Glenn.Faden@sun.com To: Alan Coopersmith Cc: Sharon Veach , gww@sac.sfbay.sun.com, PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <463B9106.2080606@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <463B5A5A.3080600@sun.com> <463B5F21.3040404@sun.com> <463B659B.8070301@sun.com> <463B7713.60208@sun.com> <463B7CD7.9050205@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Status: RO Content-Length: 1319 Alan Coopersmith wrote: > Glenn Faden wrote: > >> I think the current implementation already handles this correctly. >> The code to load the extra TSOL session config files is conditional >> based on whether the Xserver has the SUN_TSOL module loaded. > > > The only tsol code I saw in dtlogin was to start tsoldtlabel first when > the system is labeled. I don't see any that checks for TSOL before > determining which sessions to list as options on the login screen. That's correct. In general, dtlogin is unaware of TX. The logic I am referring to is in the modified Xresources file: #if EXT_SUN_TSOL #include "Xtsolresources" #endif The value of EXT_SUN_TSOL is true when the Xserver has the xtsol module loaded. > > >> So the real question is how to handle the presense of the xtsol >> module in user-customized xorg.conf files. Is it better to edit the >> user's file, or to ignore the setting, and just do the right thing. I >> think the latter is preferable. > > > I forgot to cc you (though I did cc Lok) on the mail I sent last night > about the change going into Xorg 7.3 that will solve this problem. > (The xorg.conf file will specify modules to add or remove from the > default list, instead of containing the complete list of modules > replacing the default list.) Good to know. --Glenn From will.young@sun.com Fri May 4 13:06:42 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44K6gkt015967 for ; Fri, 4 May 2007 13:06:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44K5iMa000500; Fri, 4 May 2007 13:05:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ0003495JEL00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 13:05:43 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00EZ395F5MC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 13:05:39 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44K5duh013608; Fri, 04 May 2007 20:05:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHJ00A019495V00@mail-amer.sun.com> (original mail from will.young@sun.com); Fri, 04 May 2007 14:05:39 -0600 (MDT) Received: from [129.150.64.253] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHJ00LRE95DJ6R1@mail-amer.sun.com>; Fri, 04 May 2007 14:05:39 -0600 (MDT) Date: Fri, 04 May 2007 16:02:38 -0400 From: will young Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <17979.32491.345648.420971@gargle.gargle.HOWL> Sender: William.Young@sun.com To: James Carlson Cc: Nicolas Williams , Gary Winiger , gww@sac.sfbay.sun.com, PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <463B915E.7000206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.9 (X11/20061227) Status: RO Content-Length: 1902 James Carlson wrote: > will young writes: >> A future case would then be to add dhcp tags, and modify native ldap to >> be able to work with zero host configuration. > > Given zero-configuration as a direction (and I agree it's a good one), > this means that you really do not want to have the default system DOI > or enable-labeling flag tucked away in /etc/system or in any kernel > module. > > Instead, I think it needs to be either an eeprom property or a > kernel(1M) flag. The big benefit from doing that is that it > integrates with OBP and GRUB nicely. Users can set up menu entries > that'll boot with and without TX, as desired, as well as jumpstart in > a (I hope) fairly straightforward way. Except in very simple configurations, an IP's label status and DOI is in fact a network property, not a system property. A system that has the user dynamically toggle whether it is labeled or its doi separately from its ip is primarily adding the ability to have misconfigured systems on the network. I think OBP/GRUB variables may be appropriate but more to control the systems interaction with the network and reaction to the properties the network assigns it. This is really in order to avoid real zero-configuration by explicitly disabling some configuration results. I think the stages that need to occur are: Boot with a previous label status/DOI configuration Find IP address and ldap data passing dhcp current label status/doi if present Contact ldap server with supplied data If the results differ from current label status/DOI update the data and reboot. Of course a new MAC exemption would need to exist for ldap to be allowed in this fashion. The only places I see for configuration is in having the option to override the "previous label status/DOI" and a setting for how to react to a network that disagrees (instead of updating and rebooting.) -Will From sommerfeld@sun.com Fri May 4 13:13:37 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44KDbnt016405 for ; Fri, 4 May 2007 13:13:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44KCaRQ064877; Fri, 4 May 2007 14:12:38 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ0001D9H2WR00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 13:12:38 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00E669GZ5PD0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 13:12:36 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l44KCWWw005312; Fri, 04 May 2007 16:12:32 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44KCWX1001102; Fri, 04 May 2007 16:12:32 -0400 (EDT) Date: Fri, 04 May 2007 16:12:31 -0400 From: Bill Sommerfeld Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B915E.7000206@sun.com> To: will young Cc: James Carlson , ric.aleshire@sun.com, PSARC-EXT@sun.com, gww@sac.sfbay.sun.com, Gary Winiger Message-id: <1178309551.1054.5.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> <463B915E.7000206@sun.com> Status: RO Content-Length: 1409 On Fri, 2007-05-04 at 16:02 -0400, will young wrote: > Except in very simple configurations, an IP's label status and DOI is > in fact a network property, not a system property. A system that has > the user dynamically toggle whether it is labeled or its doi separately > from its ip is primarily adding the ability to have misconfigured > systems on the network. what this says to me is that we need to get the DOI *out* of local labels (or at least out of the binary representation of admin_low/admin_high labels), with the DOI inserted at the time a particular packet labelling method is chosen rather than being present in every on-system label. > I think OBP/GRUB variables may be appropriate > but more to control the systems interaction with the network and > reaction to the properties the network assigns it. This is really in > order to avoid real zero-configuration by explicitly disabling some > configuration results. > > I think the stages that need to occur are: > Boot with a previous label status/DOI configuration > Find IP address and ldap data passing dhcp current label status/doi if > present > Contact ldap server with supplied data > If the results differ from current label status/DOI update the data and > reboot. so, this should happen before any non-admin_low/admin_high processes instantiated, which would mean you wouldn't need to reboot.. - Bill From casper@holland.sun.com Fri May 4 13:17:05 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44KH5fM016591 for ; Fri, 4 May 2007 13:17:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44KG4Dm015863; Fri, 4 May 2007 13:16:05 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ00J0D9MTB800@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 14:16:05 -0600 (MDT) Received: from sr1-eaft06-01.holland.sun.com ([129.159.237.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00B7O9MRSY60@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 14:16:04 -0600 (MDT) Received: from holland (room101 [129.159.248.23]) by sr1-eaft06-01.holland.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l44KFxdg020986; Fri, 04 May 2007 22:16:00 +0200 (MEST) Date: Fri, 04 May 2007 22:15:59 +0200 From: Casper.Dik@Sun.COM Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463B8C71.5060208@sun.com> Sender: casper@holland.sun.com To: Mark Thacker Cc: Nicolas Williams , James Carlson , will young , Gary Winiger , gww@sac.sfbay.sun.com, PSARC-EXT@Sun.COM, ric.aleshire@Sun.COM Message-id: <200705042016.l44KFxdg020986@sr1-eaft06-01.holland.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> <20070504191536.GB6007@Sun.COM> <463B8C71.5060208@sun.com> Status: RO Content-Length: 474 >This may or may not help, but for Update 5, there is still a plan of >record to integrate Newboot for SPARC systems into the OS. This should >allow for consistency between SPARC and x86/x64 systems for configuring >boot-time parameters. > >Since the integrated TX is targeting no earlier than Update 5, it might >make sense to utilize Newboot for SPARC and x86/x64. AFAIK, "Newboot for SPARC" will not utilize grub (fortunately) so differences will remain. Casper From will.young@sun.com Fri May 4 14:19:06 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44LJ5Gt019050 for ; Fri, 4 May 2007 14:19:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44LHvea007893; Sat, 5 May 2007 05:18:05 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ00205CI41600@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 15:18:04 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00B0ACI3T2B0@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 15:18:04 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l44LI3hv008283; Fri, 04 May 2007 21:18:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHJ00801C0P9X00@mail-amer.sun.com> (original mail from will.young@sun.com); Fri, 04 May 2007 15:18:03 -0600 (MDT) Received: from [129.150.64.253] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHJ001D7CI1CQG0@mail-amer.sun.com>; Fri, 04 May 2007 15:18:03 -0600 (MDT) Date: Fri, 04 May 2007 17:15:02 -0400 From: will young Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <1178309551.1054.5.camel@thunk> Sender: William.Young@sun.com To: Bill Sommerfeld Cc: James Carlson , ric.aleshire@sun.com, PSARC-EXT@sun.com, gww@sac.sfbay.sun.com, Gary Winiger Message-id: <463BA256.8030108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> <463B915E.7000206@sun.com> <1178309551.1054.5.camel@thunk> User-Agent: Thunderbird 1.5.0.9 (X11/20061227) Status: RO Content-Length: 2585 Bill Sommerfeld wrote: > On Fri, 2007-05-04 at 16:02 -0400, will young wrote: >> Except in very simple configurations, an IP's label status and DOI is >> in fact a network property, not a system property. A system that has >> the user dynamically toggle whether it is labeled or its doi separately >> from its ip is primarily adding the ability to have misconfigured >> systems on the network. > > what this says to me is that we need to get the DOI *out* of local > labels (or at least out of the binary representation of > admin_low/admin_high labels), with the DOI inserted at the time a > particular packet labelling method is chosen rather than being present > in every on-system label. This is a possible choice, but I was saying: "an IP's label status and DOI is in fact a network property" while this is more consistent with just: "DOI is in fact a network property" If we remove DOI from admin_low/admin_high this makes us able/willing to handle communications from systems with different DOIs. For CIPSO this is a bit of a no-no, for later drafts DOI seems to be less of a concrete wall and more of a specifier for compartment interpretation. > >> I think OBP/GRUB variables may be appropriate >> but more to control the systems interaction with the network and >> reaction to the properties the network assigns it. This is really in >> order to avoid real zero-configuration by explicitly disabling some >> configuration results. >> >> I think the stages that need to occur are: >> Boot with a previous label status/DOI configuration >> Find IP address and ldap data passing dhcp current label status/doi if >> present >> Contact ldap server with supplied data >> If the results differ from current label status/DOI update the data and >> reboot. > > so, this should happen before any non-admin_low/admin_high processes > instantiated, which would mean you wouldn't need to reboot.. This requires the global zone to be setup (which has an admin_low label) and a number of process to have run so in the current setup it is too late. We don't really need all the aspects of a full reboot though we need the global zone stopped, changed and restarted. I would suspect that is hard to do correctly. I would like to see solaris move toward using the global zone as a secured specialized kernel/resource maintenance zone as I think this is necessary for security in general and to support multiple DOIs correctly I think TX really needs a secure global zone and to be using a separate admin_low zone per DOI. -Will > > - Bill > > From Nicolas.Williams@sun.com Fri May 4 14:24:25 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44LOOqr019186 for ; Fri, 4 May 2007 14:24:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44LNGXq025367; Fri, 4 May 2007 22:23:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ0020RCQVL100@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 15:23:19 -0600 (MDT) Received: from binky.central.sun.com ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00BSRCQUT070@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 15:23:19 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l44LMAiH006230; Fri, 04 May 2007 16:22:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l44LMAEJ006229; Fri, 04 May 2007 16:22:10 -0500 (CDT) Date: Fri, 04 May 2007 16:22:10 -0500 From: Nicolas Williams Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463BA256.8030108@sun.com> To: will young Cc: Bill Sommerfeld , PSARC-EXT@sun.com, Gary Winiger , ric.aleshire@sun.com, James Carlson , gww@sac.sfbay.sun.com Message-id: <20070504212209.GL6007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> <463B915E.7000206@sun.com> <1178309551.1054.5.camel@thunk> <463BA256.8030108@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 666 On Fri, May 04, 2007 at 05:15:02PM -0400, will young wrote: > >so, this should happen before any non-admin_low/admin_high processes > >instantiated, which would mean you wouldn't need to reboot.. > This requires the global zone to be setup (which has an admin_low > label) and a number of process to have run so in the current setup it is > too late. > > We don't really need all the aspects of a full reboot though we need > the global zone stopped, changed and restarted. I would suspect that is > hard to do correctly. Can't init(1M)/svc.startd(1M) kill all procs in its zone that aren't labelled if it is restarted and the system is labelled? Nico -- From carlsonj@phorcys.east.sun.com Fri May 4 14:51:42 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44LpfDv020282 for ; Fri, 4 May 2007 14:51:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l44LoKkT021089; Sat, 5 May 2007 05:50:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ00D01E09MS00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 14:50:33 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00B0ME093B70@nwk-avmta-2.sfbay.sun.com>; Fri, 04 May 2007 14:50:33 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l44LoVYU002632; Fri, 04 May 2007 17:50:31 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l44LoVLO002629; Fri, 04 May 2007 17:50:31 -0400 (EDT) Date: Fri, 04 May 2007 17:50:30 -0400 From: James Carlson Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <20070504212209.GL6007@Sun.COM> To: Nicolas Williams Cc: will young , gww@sac.sfbay.sun.com, Gary Winiger , PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <17979.43686.923758.794438@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> <463B915E.7000206@sun.com> <1178309551.1054.5.camel@thunk> <463BA256.8030108@sun.com> <20070504212209.GL6007@Sun.COM> Status: RO Content-Length: 441 Nicolas Williams writes: > Can't init(1M)/svc.startd(1M) kill all procs in its zone that aren't > labelled if it is restarted and the system is labelled? Everything including the kcred needs a good lather and rinse. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Fri May 4 15:04:37 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l44M4aHs020900 for ; Fri, 4 May 2007 15:04:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l44M3X0e011049; Fri, 4 May 2007 23:03:34 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ0060JELWSB00@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 16:03:32 -0600 (MDT) Received: from binky.central.sun.com ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ00B20ELVSXD0@brm-avmta-1.central.sun.com>; Fri, 04 May 2007 16:03:32 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l44M2Nit006398; Fri, 04 May 2007 17:02:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l44M2Ndk006397; Fri, 04 May 2007 17:02:23 -0500 (CDT) Date: Fri, 04 May 2007 17:02:23 -0500 From: Nicolas Williams Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <17979.43686.923758.794438@gargle.gargle.HOWL> To: James Carlson Cc: will young , gww@sac.sfbay.sun.com, Gary Winiger , PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <20070504220222.GO6007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> <463B915E.7000206@sun.com> <1178309551.1054.5.camel@thunk> <463BA256.8030108@sun.com> <20070504212209.GL6007@Sun.COM> <17979.43686.923758.794438@gargle.gargle.HOWL> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 385 On Fri, May 04, 2007 at 05:50:30PM -0400, James Carlson wrote: > Nicolas Williams writes: > > Can't init(1M)/svc.startd(1M) kill all procs in its zone that aren't > > labelled if it is restarted and the system is labelled? > > Everything including the kcred needs a good lather and rinse. Ah. Yes, there could be lots of kernel threads that too would need to be restarted. Thanks. From roland.mainz@nrubsig.org Fri May 4 20:49:52 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l453nptC001491 for ; Fri, 4 May 2007 20:49:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l453mnKb017489; Sat, 5 May 2007 11:48:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHJ00D03ULDZG00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 20:48:49 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHJ009FGULCBR90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 May 2007 20:48:48 -0700 (PDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l453mmIT003597; Sat, 05 May 2007 03:48:48 +0000 (GMT) Received: from mms22es.sun.com ([150.143.232.34] [150.143.232.34]) by relay22.sun.com with ESMTP id BT-MMP-1939882; Sat, 05 May 2007 03:48:28 +0000 (Z) Received: from mms23bas.mms.us.syntegra.com (relay23.mms.us.syntegra.com [192.12.251.50]) by mms22es.sun.com with ESMTP id BT-MMP-960557; Sat, 05 May 2007 03:48:28 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay23.sun.com with ESMTP id BT-MMP-11067473; Sat, 05 May 2007 03:48:27 +0000 (Z) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 7D9D53030C3; Sat, 05 May 2007 05:48:27 +0200 (CEST) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id 589701B8E0A; Sat, 05 May 2007 05:48:27 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-002-154.pools.arcor-ip.net [84.59.2.154]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 297021BF385; Sat, 05 May 2007 05:48:27 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l453mOfm001599; Sat, 05 May 2007 05:48:25 +0200 (CEST) Date: Sat, 05 May 2007 05:48:24 +0200 From: Roland Mainz Subject: Re: 2007/254 - Enabling method for Trusted Extensions Sender: gisburn@jupiterb48.nrubsig.org To: Gary Winiger Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <463BFE88.72D44D76@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> Status: RO Content-Length: 2396 Gary Winiger wrote: > > I'm sponsoring this fast track for Ric Aleshire and the TX project team. > This is an OpenSolaris case. > > It updates the TX label translation service, svc:/system/labeld, defined > in Layered Trusted Solaris Label Interfaces (PSARC/2005/259) to enable > and disable Solaris Trusted Extensions. > > The previous Unstable interface taxonomy is modified to Uncommitted and > a Patch release binding are requested. > > The timer is set for 10 May, 2007. [snip] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > |kernel/sys/lbl_edition, | (Contracted) | Layered module name| > |kernel/sys/amd64/lbl_edition, | Project Private | | > |kernel/sys/sparcv9/lbl_edition | | | > |label_services | | global variable | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One small nit: Could you change "label_services" to "tx_label_services" to make sure that the variable lives in some kind of "tx_"-namespace (e.g. to avoid namespace collisions with other modules) ? > Problem > ======= > > It is planned to get rid of the ExtraValue directory and deliver all > the TX packages in the WOS to be installed with Solaris. As part of work, > source from the TLC consolidation will be moved into the ON gate and > corresponding packages will be delivered with Solaris. As a result, a > new mechanism to enable and disable TX must be created, so that > packages may be installed without forcing the system to be labeled. > > Proposal > ======= > > 1) The svc:/system/labeld service is only shipped in the global zone, > is shipped disabled and not enabled by any SMF profile (it was enabled > as part of the TX post installation process). > Enabling this service will result in the Trusted Extensions feature > being enabled. To accomplish this, if TX is not already enabled, > the start method for this service will set the following kernel > variable in /etc/system: > set sys_labeling=1 Same nit as above... wouldn't "tx_sys_labeling=1" be better in this case ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From scott.rotondo@sun.com Sun May 6 16:42:03 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l46Ng318013376 for ; Sun, 6 May 2007 16:42:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l46Nf1x6025631; Sun, 6 May 2007 17:41:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHN00E018GD5Q00@nwk-avmta-2.sfbay.sun.com>; Sun, 06 May 2007 16:41:01 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHN00A6O8GCKA60@nwk-avmta-2.sfbay.sun.com>; Sun, 06 May 2007 16:41:00 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l46NexGI000667; Sun, 06 May 2007 16:40:59 -0700 (PDT) Received: from [192.9.61.51] (punchin-rotondo.SFBay.Sun.COM [192.9.61.51]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l46NewT21707; Sun, 06 May 2007 16:40:58 -0700 (PDT) Date: Sun, 06 May 2007 16:40:52 -0700 From: Scott Rotondo Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <17979.32491.345648.420971@gargle.gargle.HOWL> To: James Carlson Cc: will young , Nicolas Williams , Gary Winiger , psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <463E6784.6000004@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705040330.l443UxMa023135@marduk.eng.sun.com> <20070504034956.GD4743@Sun.COM> <463B71E8.8060504@sun.com> <17979.32491.345648.420971@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 1226 James Carlson wrote: > will young writes: >> A future case would then be to add dhcp tags, and modify native ldap to >> be able to work with zero host configuration. > > Given zero-configuration as a direction (and I agree it's a good one), > this means that you really do not want to have the default system DOI > or enable-labeling flag tucked away in /etc/system or in any kernel > module. > > Instead, I think it needs to be either an eeprom property or a > kernel(1M) flag. The big benefit from doing that is that it > integrates with OBP and GRUB nicely. Users can set up menu entries > that'll boot with and without TX, as desired, as well as jumpstart in > a (I hope) fairly straightforward way. > Enabling labeling via a boot argument instead of a variable in /etc/system sounds like a huge improvement. Not only can the user select TX or non-TX behavior from the boot menu, but we also avoid the patching nightmare of trying to keep multiple boot archives in sync where the only (intentional) difference between them is the content of /etc/system. It also seems logical to make this a boot argument since the user is effectively running the system in a different mode when labeling is enabled. Scott From gww@eng.sun.com Mon May 7 15:55:51 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l47Mto1g005520 for ; Mon, 7 May 2007 15:55:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l47Msm3N027156 for <@newsunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Mon, 7 May 2007 23:54:49 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHP00I090ZBPK00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 07 May 2007 16:54:47 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHP00GCC0Z9BXD0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 07 May 2007 16:54:45 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l47MsiCE023567; Mon, 07 May 2007 15:54:44 -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 l47MuN5W027097; Mon, 07 May 2007 15:56:23 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l47MuNn4027096; Mon, 07 May 2007 15:56:23 -0700 (PDT) Date: Mon, 07 May 2007 15:56:23 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: gww@sac.sfbay.sun.com, roland.mainz@nrubsig.org Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <200705072256.l47MuNn4027096@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 297 > > variable in /etc/system: > > set sys_labeling=1 > > Same nit as above... wouldn't "tx_sys_labeling=1" be better in this case > ? Renaming interfaces ARCed in PSARC/2006/191 is_system_label is not part of this case. This kernel variable is Consolidation Private to ON. Gary.. From alan.coopersmith@sun.com Mon May 7 16:03:08 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l47N38a5005754 for ; Mon, 7 May 2007 16:03:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l47N26Bq006482 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 7 May 2007 16:02:08 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHP00I0D1BJDJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 07 May 2007 16:02:07 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHP0026T1BJP5B0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 07 May 2007 16:02:07 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l47N26go012968; Mon, 07 May 2007 16:02:06 -0700 (PDT) Date: Mon, 07 May 2007 16:02:06 -0700 From: Alan Coopersmith Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463BFE88.72D44D76@nrubsig.org> To: Roland Mainz Cc: Gary Winiger , PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <463FAFEE.6060008@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> <463BFE88.72D44D76@nrubsig.org> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 677 Roland Mainz wrote: > One small nit: Could you change "label_services" to "tx_label_services" > to make sure that the variable lives in some kind of "tx_"-namespace > (e.g. to avoid namespace collisions with other modules) ? Actually, "label" seems less likely to me to collide than "tx" after looking at some networking code last week that confused me until I realized that the "tx_" littered through it was transmit, not Trusted Extensions. ("tx_" also violates the general ARC advice of "Don't use marketing names in interfaces, they change too often".) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From roland.mainz@nrubsig.org Mon May 7 16:22:19 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l47NMIdI006215 for ; Mon, 7 May 2007 16:22:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l47NLExR004948; Tue, 8 May 2007 00:21:15 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHP00L0127EHK00@brm-avmta-1.central.sun.com>; Mon, 07 May 2007 17:21:14 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHP00GYN27DBWE0@brm-avmta-1.central.sun.com>; Mon, 07 May 2007 17:21:13 -0600 (MDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l47NLDiT027916; Mon, 07 May 2007 23:21:13 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay21.sun.com with ESMTP id BT-MMP-2089932; Mon, 07 May 2007 23:21:13 +0000 (Z) Received: from mms23bas.mms.us.syntegra.com (relay23.mms.us.syntegra.com [192.12.251.50]) by mms24es.sun.com with ESMTP id BT-MMP-640515; Mon, 07 May 2007 23:21:12 +0000 (Z) Received: from mail-in-08.arcor-online.net ([151.189.21.48] [151.189.21.48]) by relay23.sun.com with ESMTP id BT-MMP-13284171; Mon, 07 May 2007 23:21:12 +0000 (Z) Received: from mail-in-04-z2.arcor-online.net (mail-in-04-z2.arcor-online.net [151.189.8.16]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id E10F227AD65; Tue, 08 May 2007 01:21:11 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-04-z2.arcor-online.net (Postfix) with ESMTP id D647AABF5C; Tue, 08 May 2007 01:21:11 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-207-151.pools.arcor-ip.net [84.58.207.151]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 8B2908C464; Tue, 08 May 2007 01:21:11 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l47NL8x3002210; Tue, 08 May 2007 01:21:09 +0200 (CEST) Date: Tue, 08 May 2007 01:21:08 +0200 From: Roland Mainz Subject: Re: 2007/254 - Enabling method for Trusted Extensions Sender: gisburn@jupiterb48.nrubsig.org To: Gary Winiger Cc: gww@sac.sfbay.sun.com, PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <463FB464.EBFAB617@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <200705072256.l47MuNn4027096@marduk.eng.sun.com> Status: RO Content-Length: 730 Gary Winiger wrote: > > > variable in /etc/system: > > > set sys_labeling=1 > > > > Same nit as above... wouldn't "tx_sys_labeling=1" be better in this case > > ? > > Renaming interfaces ARCed in PSARC/2006/191 is_system_label >is not part of this case. Ouch... I didn't notice that this was already ARC'ed... sorry... ;-( > This kernel variable is Consolidation > Private to ON. Is there any naming scheme for public kernel variables ? Or can anyone pick his/her preferred name and "hope" that no collisions will occur ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz@nrubsig.org Mon May 7 16:22:33 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l47NMWBW006237 for ; Mon, 7 May 2007 16:22:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l47NLIL0019214; Tue, 8 May 2007 07:21:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHP00L0527QIT00@brm-avmta-1.central.sun.com>; Mon, 07 May 2007 17:21:26 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHP00GT127PBXE0@brm-avmta-1.central.sun.com>; Mon, 07 May 2007 17:21:25 -0600 (MDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l47N3U2t000264; Mon, 07 May 2007 23:21:24 +0000 (GMT) Received: from mms03es.sun.com ([150.143.104.54] [150.143.104.54]) by relay2.sun.com with ESMTP id BT-MMP-280781; Mon, 07 May 2007 23:21:19 +0000 (Z) Received: from relay01i.sun.com (ip70.net150143-60.block3.us.syntegra.com [150.143.60.70]) by mms03es.sun.com with ESMTP id BT-MMP-426505; Mon, 07 May 2007 23:21:19 +0000 (Z) Received: from mail-in-10.arcor-online.net ([151.189.21.50] [151.189.21.50]) by relay0i.sun.com with ESMTP id BT-MMP-6603830; Mon, 07 May 2007 23:21:18 +0000 (Z) Received: from mail-in-01-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id ED5EC1F5191; Tue, 08 May 2007 01:21:17 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id E160A345D60; Tue, 08 May 2007 01:21:17 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-207-151.pools.arcor-ip.net [84.58.207.151]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 7D86A8C464; Tue, 08 May 2007 01:21:17 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l47NLFNx002213; Tue, 08 May 2007 01:21:15 +0200 (CEST) Date: Tue, 08 May 2007 01:21:15 +0200 From: Roland Mainz Subject: Re: 2007/254 - Enabling method for Trusted Extensions Sender: gisburn@jupiterb48.nrubsig.org To: Alan Coopersmith Cc: Gary Winiger , PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <463FB46B.F79316C@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> <463BFE88.72D44D76@nrubsig.org> <463FAFEE.6060008@sun.com> Status: RO Content-Length: 1040 Alan Coopersmith wrote: > Roland Mainz wrote: > > One small nit: Could you change "label_services" to "tx_label_services" > > to make sure that the variable lives in some kind of "tx_"-namespace > > (e.g. to avoid namespace collisions with other modules) ? > > Actually, "label" seems less likely to me to collide than "tx" after > looking at some networking code last week that confused me until I > realized that the "tx_" littered through it was transmit, not Trusted > Extensions. ("tx_" also violates the general ARC advice of > "Don't use marketing names in interfaces, they change too often".) Somehow I wish this stuff would be named |net_tx_*| or |net::tx_*()| ... but it seems the kernel doesn't really support a concept similar to C++ namespaces (I just said similar, I don't dare to propose to write kernel stuff in C++ ... :-) ) ... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From carlsonj@phorcys.east.sun.com Tue May 8 05:47:30 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48ClUQe003095 for ; Tue, 8 May 2007 05:47:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48CkJwD022724; Tue, 8 May 2007 13:46:26 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ0030V3HD6X00@brm-avmta-1.central.sun.com>; Tue, 08 May 2007 06:46:25 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00BAO3HCYN80@brm-avmta-1.central.sun.com>; Tue, 08 May 2007 06:46:25 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l48CkO82011045; Tue, 08 May 2007 08:46:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l48CkOle011042; Tue, 08 May 2007 08:46:24 -0400 (EDT) Date: Tue, 08 May 2007 08:46:24 -0400 From: James Carlson Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <463FB46B.F79316C@nrubsig.org> To: Roland Mainz Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <17984.28960.251805.149937@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> <463BFE88.72D44D76@nrubsig.org> <463FAFEE.6060008@sun.com> <463FB46B.F79316C@nrubsig.org> Status: RO Content-Length: 702 Roland Mainz writes: > Somehow I wish this stuff would be named |net_tx_*| or |net::tx_*()| ... > but it seems the kernel doesn't really support a concept similar to C++ > namespaces (I just said similar, I don't dare to propose to write kernel > stuff in C++ ... :-) ) ... ;-( I don't wish that. Labeling is *not* just a networking issue. It also shows up in process credentials and file system interfaces, among other places. Classing it as "net_tx_*" would be a mistake. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@eng.sun.com Tue May 8 08:11:27 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48FBQjH007892 for ; Tue, 8 May 2007 08:11:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l48F9wMh010211 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Tue, 8 May 2007 23:10:23 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00H2JA5AHJ00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 May 2007 09:10:22 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00DSTA59L320@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 May 2007 09:10:21 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l48FAKYQ018023; Tue, 08 May 2007 08:10:20 -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 l48FC1f0027767; Tue, 08 May 2007 08:12:01 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l48FC1QE027766; Tue, 08 May 2007 08:12:01 -0700 (PDT) Date: Tue, 08 May 2007 08:12:01 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: gww@sac.sfbay.sun.com, psarc-ext@sun.com Cc: ric.aleshire@sun.com Message-id: <200705081512.l48FC1QE027766@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3564 To summarize the discussion up to this point, as I understand it: 0) The TX enabling interface is svcadm enable svc:/system/labeld 1) /etc/system is not an idea interface. Its use is deprecated. Alternate implementation proposals should considered. 2) Consider adding a new "PROM" parameter (e.g., labeled=true|false). Enabling labeld would imply having some way to set default boots that get this parameter. eeprom(1M) labeled=true could be used to set this new parameter. 2a) Considering adding a switch to kernel(1M). Enabling labeld would imply having some way that default boots will get this switch. eeprom(1M) boot-args= could be used to append the kernel switch to the existing boot-args 2b) Considering adding a switch to kernel(1M). Enabling labeld would imply having some way that default boots get this switch. eeprom(1M) boot-args= for SPARC and updating the Grub menu and default for x86/x64. 3) Consider adding a driver and driver.conf file. Enabling labeld would imply changing a value in the driver.conf file. 0 there seems to be no descention that svcadm enable is the administrative interface. Architecturally below that the discussion is about the most appropriate interface. 1, 2, 2a, 3 all require rebuilding the boot archive. 2 might seem feasible, however experimentation shows that while it works fine on x86/x64 emulated NVRAM, but, at least for some SPARC OBPs it fails: # eeprom labeled=true eeprom: OPROMSETOPT: Invalid argument labeled: invalid property. 2a and 2b can lead to administrative error that would violate the principle of least astonishment. VIZ. The admin converts the system to TX. At some point in the future, the admin wants to set boot-args and looses the labeled mode, or the admin needs to boot into single user mode (uttering boot -s). The admin finds the boot up is in "non-labeled" mode, not "labeled" mode. It can be argued that swapping back and forth between non-labeled and labeled mode would be more easily achieved with a kernel switch (2a or 2b) since maintaining two boot archives for different /etc/system values is not convenient. The project team argues that going from labeled mode to non-labeled mode is non trivial and should be treated at the same level as sys-unconfig(1M). That is, the system is being provisioned for some other use. All labeled zones need to be destroyed. All labeled data needs to be reclassified or destroyed. Swapping between labeled and unlabeled mode is something the project team believes is best done with great care and likely a reinstall. This project does not change the present process of changing from labeled to non-labeld mode. A driver.conf file would seem like a reasonable implementation. However, it appears that there is little long term value to adding a new driver just to read its driver.conf and set the sys_labeling value. The SMF project intends to provide for early kernel access to the repository. At that time, the enabling of labeld in the repository could be read in the kernel and the sys_labeling variable directly set. The project team proposes that the project, as originally speced, is the preferred current implementation approach. It is no worse than other parts of converting to TX today (audit is enabled in /etc/system) and, as with audit the Solaris Audit project, there is a plan to eliminate the use of /etc/system as an implementation in the future without change to the admin interface. In addition, it is simple and has low risk. Gary.. From Michael.Schuster@sun.com Tue May 8 08:25:18 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48FPHAv008346 for ; Tue, 8 May 2007 08:25:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l48FOA9C014777; Tue, 8 May 2007 23:24:13 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00I0JASBTM00@brm-avmta-1.central.sun.com>; Tue, 08 May 2007 09:24:11 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00DRMASAL330@brm-avmta-1.central.sun.com>; Tue, 08 May 2007 09:24:10 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l48FOAbY015427; Tue, 08 May 2007 08:24:10 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHQ00701AK4M800@d1-sfbay-09.sun.com> (original mail from Michael.Schuster@Sun.COM); Tue, 08 May 2007 08:24:10 -0700 (PDT) Received: from [129.146.106.37] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHQ006V3AS8RCY6@d1-sfbay-09.sun.com>; Tue, 08 May 2007 08:24:09 -0700 (PDT) Date: Tue, 08 May 2007 08:24:52 -0700 From: Michael Schuster Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <17984.28960.251805.149937@gargle.gargle.HOWL> Sender: Michael.Schuster@sun.com To: James Carlson Cc: Roland Mainz , PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <46409644.1060004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705030343.l433hhLB022565@sac.sfbay.sun.com> <463BFE88.72D44D76@nrubsig.org> <463FAFEE.6060008@sun.com> <463FB46B.F79316C@nrubsig.org> <17984.28960.251805.149937@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070411) Status: RO Content-Length: 776 James Carlson wrote: > Roland Mainz writes: >> Somehow I wish this stuff would be named |net_tx_*| or |net::tx_*()| ... >> but it seems the kernel doesn't really support a concept similar to C++ >> namespaces (I just said similar, I don't dare to propose to write kernel >> stuff in C++ ... :-) ) ... ;-( > > I don't wish that. Labeling is *not* just a networking issue. It > also shows up in process credentials and file system interfaces, among > other places. Classing it as "net_tx_*" would be a mistake. James, just from reading his email, my understanding was that Roland was referring to the *current* networking-related functions beginning the "tx_", and not to the proposed trusted extensions. HTH Michael -- Michael Schuster Recursion, n.: see 'Recursion' From Nicolas.Williams@Sun.COM Tue May 8 08:27:39 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48FRcDA008409 for ; Tue, 8 May 2007 08:27:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l48FQNwX015416; Tue, 8 May 2007 23:26:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00D03AW6UI00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 May 2007 08:26:30 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00AT7AW51B10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 May 2007 08:26:29 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l48FPIVS010606; Tue, 08 May 2007 10:25:18 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l48FPHLl010605; Tue, 08 May 2007 10:25:17 -0500 (CDT) Date: Tue, 08 May 2007 10:25:17 -0500 From: Nicolas Williams Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705081512.l48FC1QE027766@marduk.eng.sun.com> To: Gary Winiger Cc: gww@sac.sfbay.sun.com, psarc-ext@Sun.COM, ric.aleshire@Sun.COM Message-id: <20070508152517.GD10560@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705081512.l48FC1QE027766@marduk.eng.sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3250 On Tue, May 08, 2007 at 08:12:01AM -0700, Gary Winiger wrote: > To summarize the discussion up to this point, as I understand it: > > 0) The TX enabling interface is svcadm enable svc:/system/labeld Hmmm, there's no "enable method" -- only start/stop/refresh methods. So if one does "svcadm enable -t labeld, then what happens? Presumably on reboot labeld will warn and disable itself, or maybe it should just warn and ensure that the next boot will have TX properly setup. > 1) /etc/system is not an idea interface. Its use is deprecated. > Alternate implementation proposals should considered. > > 2) Consider adding a new "PROM" parameter (e.g., labeled=true|false). > Enabling labeld would imply having some way to set default > boots that get this parameter. eeprom(1M) labeled=true could > be used to set this new parameter. > > 2a) Considering adding a switch to kernel(1M). > Enabling labeld would imply having some way that default > boots will get this switch. eeprom(1M) boot-args= could be > used to append the kernel switch to the existing boot-args > > 2b) Considering adding a switch to kernel(1M). > Enabling labeld would imply having some way that default > boots get this switch. eeprom(1M) boot-args= for SPARC > and updating the Grub menu and default for x86/x64. (2b) seems the same as (2a). > 3) Consider adding a driver and driver.conf file. > Enabling labeld would imply changing a value in the driver.conf > file. There's no way to override a driver.conf file setting on boot (there's no kernel option like -a that allows it; perhaps with kmdb one might be able to). This might be seen as a plus or as a minus, depending on one's p.o.v. > 0 there seems to be no descention that svcadm enable is the administrative > interface. Architecturally below that the discussion is about the most > appropriate interface. > > 1, 2, 2a, 3 all require rebuilding the boot archive. I think that's a typo, since below you indicate that (2)/(2a) do not require rebuilding the boot archive (boot options and eepromp settings are not part of the boot archive). > It can be argued that swapping back and forth between non-labeled and > labeled mode would be more easily achieved with a kernel switch (2a or 2b) > since maintaining two boot archives for different /etc/system values > is not convenient. The project team argues that going from labeled > mode to non-labeled mode is non trivial and should be treated at the > same level as sys-unconfig(1M). That is, the system is being provisioned > for some other use. All labeled zones need to be destroyed. All labeled > data needs to be reclassified or destroyed. Swapping between labeled and > unlabeled mode is something the project team believes is best done with > great care and likely a reinstall. This project does not change the present > process of changing from labeled to non-labeld mode. If that's so then a driver.conf approach seems best (no way to disable from the OBP/GRUB prompts), with /etc/system still better than boot opts. For anyone who wants to play with TX on, say, a laptop, however, a way to switch back and forth would be nice -- but certainly not a requirement. Nico -- From Darren.Moffat@sun.com Tue May 8 08:33:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48FXLgN008659 for ; Tue, 8 May 2007 08:33:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l48FUmFM016018; Tue, 8 May 2007 23:32:16 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00J25B5QPI00@brm-avmta-1.central.sun.com>; Tue, 08 May 2007 09:32:14 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00DCCB5JL250@brm-avmta-1.central.sun.com>; Tue, 08 May 2007 09:32:08 -0600 (MDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l48FW7tJ022520; Tue, 08 May 2007 15:32:07 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHQ00B01AY1UY00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 08 May 2007 16:32:07 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHQ00BLMB5E1C30@d1-emea-09.sun.com>; Tue, 08 May 2007 16:32:02 +0100 (BST) Date: Tue, 08 May 2007 16:32:02 +0100 From: Darren J Moffat Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705081512.l48FC1QE027766@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <464097F2.8000906@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705081512.l48FC1QE027766@marduk.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 905 One of the lessons we have learned from bsmconv(1M) is that tying together Audit and Device Allocation was a poor choice (and in the past bsmconv did things that kbd(1M) now does), some people want one without the other (regardless of what any Common Criteria security target says). It seems that this project is effectively making a similar choice by having the enabling of the SMF labeling service turn on audit and device allocation. I would rather that we did not force auditing to be turned on just because labeling was turned on. Was any consideration given to this being the admin interface: ---- # netservices labeled ---- This means we don't have to have svc:/system/labled do the work of forcing audit and device allocation and any other TX recommended things to be enabled. Which allows an advanced/custom configuration where labeling is on but audit is not. -- Darren J Moffat From gww@eng.sun.com Tue May 8 08:38:02 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48Fc1DS008806 for ; Tue, 8 May 2007 08:38:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48Fafsj018267 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@Sun.COM>; Tue, 8 May 2007 16:36:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ0071DBDJ1N00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 08 May 2007 08:36:55 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ006FABDJV000@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 08 May 2007 08:36:55 -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 l48Fasuw020995; Tue, 08 May 2007 08:36:54 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l48FcZEk027863; Tue, 08 May 2007 08:38:35 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l48FcZTI027862; Tue, 08 May 2007 08:38:35 -0700 (PDT) Date: Tue, 08 May 2007 08:38:35 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: Nicolas.Williams@sun.com, gww@eng.sun.com Cc: gww@sac.sfbay.sun.com, psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <200705081538.l48FcZTI027862@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1373 > On Tue, May 08, 2007 at 08:12:01AM -0700, Gary Winiger wrote: > > To summarize the discussion up to this point, as I understand it: > > > > 0) The TX enabling interface is svcadm enable svc:/system/labeld > > Hmmm, there's no "enable method" -- only start/stop/refresh methods. So On one ever said enable method SYNOPSIS /usr/sbin/svcadm [-v] enable [-rst] {FMRI | pattern}... > if one does "svcadm enable -t labeld, then what happens? Presumably on > reboot labeld will warn and disable itself, or maybe it should just warn > and ensure that the next boot will have TX properly setup. Implementation details: The same as presently happens in the TX package installation scripts. Go RTM. This project is to ARC that svcadm eable labeld enables TX on a non-labeled system. See 2002/762 and friends. > > 2b) Considering adding a switch to kernel(1M). > > Enabling labeld would imply having some way that default > > boots get this switch. eeprom(1M) boot-args= for SPARC > > and updating the Grub menu and default for x86/x64. > > (2b) seems the same as (2a). No, it has different SPARC and x86/x64 implementations. Please read carefully before replying. > For anyone who wants to play with TX on, say, a laptop, however, a way > to switch back and forth would be nice -- but certainly not a > requirement. Dual boot. Gary.. From gww@eng.sun.com Tue May 8 08:42:06 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48Fg5ij008999 for ; Tue, 8 May 2007 08:42:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48FexaV019440 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 8 May 2007 16:41:03 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00709BKE7V00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 08:41:02 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ006OKBKDV000@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 08:41:01 -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 l48Fex3a022124; Tue, 08 May 2007 08:40:59 -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 l48Fgd5Y027888; Tue, 08 May 2007 08:42:39 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l48Fgdj2027887; Tue, 08 May 2007 08:42:39 -0700 (PDT) Date: Tue, 08 May 2007 08:42:39 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: Darren.Moffat@sun.com, gww@eng.sun.com Cc: psarc-ext@sun.com, ric.aleshire@sun.com Message-id: <200705081542.l48Fgdj2027887@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 496 > I would rather that we did not force auditing to be turned on just > because labeling was turned on. SunOS MLS, SunOS CMW, Trusted Solaris 1.x, Trusted Solaris 2.x, Trusted Solaris 7, 8 and TX have always enabled auditing and device allocation. This is a TX mode enabling project. > Was any consideration given to this being the admin interface: > ---- > # netservices labeled netservices is obsolete. And intended to be removed as soon as underlying SMF features permit it. Gary.. From Darren.Moffat@sun.com Tue May 8 09:28:50 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48GSnIP010557 for ; Tue, 8 May 2007 09:28:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l48GRUCr003122; Wed, 9 May 2007 00:27:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00809DQ7X500@nwk-avmta-2.sfbay.sun.com>; Tue, 08 May 2007 09:27:43 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ006E6DQ6UM40@nwk-avmta-2.sfbay.sun.com>; Tue, 08 May 2007 09:27:43 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l48GRfUc028661; Tue, 08 May 2007 16:27:41 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHQ00D01DP0J200@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 08 May 2007 17:27:41 +0100 (BST) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHQ00EO0DQ5K510@d1-emea-10.sun.com>; Tue, 08 May 2007 17:27:41 +0100 (BST) Date: Tue, 08 May 2007 17:27:41 +0100 From: Darren J Moffat Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705081542.l48Fgdj2027887@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <4640A4FD.5000900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705081542.l48Fgdj2027887@marduk.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 2804 Gary Winiger wrote: >> I would rather that we did not force auditing to be turned on just >> because labeling was turned on. > > SunOS MLS, SunOS CMW, Trusted Solaris 1.x, Trusted Solaris > 2.x, Trusted Solaris 7, 8 and TX have always enabled auditing > and device allocation. This is a TX mode enabling project. just because we always did it that way doesn't mean it is correct. Those other releases are all very different because they don't distinguish between installation and enabling of the labeled services - even TX. Given that this project is actually about the distinction between installation and enabling of labeled services I think now is the time to address the issue of labeling forcing auditing to be turned on. I quite strongly object to labeling forcing auditing to be turned on. Having labeling turn on device allocation I don't really object to because it needs to be there for labeling of removal media to work correctly. I don't believe we need to use Solaris Audit just because we are running labeld. It might be a recommendation or best practice but I don't believe labeling architecturally requires auditd to be running, right ? I'm particularly concerned about this given we are trying to move to an architecture (and implementation) where enable/disable of audit doesn't require a reboot - that will probably result in an EOF of bsmconv as we know it today. It would be nice if this audit work wasn't tied to ensuring that enabling labeling services still worked. BTW yes I'm making assumptions about how this would be implemented but since the case doesn't say how auditing is turned on thats all I can do. So what interface for turning on audit is this case proposing to use ? >> Was any consideration given to this being the admin interface: >> ---- >> # netservices labeled > > netservices is obsolete. And intended to be removed as soon > as underlying SMF features permit it. Those SMF features don't exist today as an approved architecture this case can depend on which is why I didn't suggest that. netservices exists in Nevada and in S10 updates. My big issue with this case is that turning on svc:/system/labeld turns on other things by means other than SMF dependencies. The reason for suggesting netservices(1M) was so that the enabling of labeled services wasn't tided into a single SMF service. What happens if this case: I have a system with no zones. I have auditing enabled and configure to my liking. I accidentally enable svc:/system/labled and then realise it wasn't what I thought it was. I svcadm disable labled. Is auditing still enabled ? While it might not be a case to concern ourselves much I'm using it to illustrate the possible problem of having labeling tied to auditing. -- Darren J Moffat From gww@eng.sun.com Tue May 8 10:34:59 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48HYxoH013040 for ; Tue, 8 May 2007 10:34:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48HXvsu051365 for <@newsunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Tue, 8 May 2007 11:33:57 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00705GSKV900@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 11:33:56 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00DIAGSJLBC0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 11:33:55 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l48HXrse005272; Tue, 08 May 2007 10:33:53 -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 l48HZYlx028052; Tue, 08 May 2007 10:35:34 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l48HZY1T028051; Tue, 08 May 2007 10:35:34 -0700 (PDT) Date: Tue, 08 May 2007 10:35:34 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <200705081735.l48HZY1T028051@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 7319 > Gary Winiger wrote: > >> I would rather that we did not force auditing to be turned on just > >> because labeling was turned on. > > > > SunOS MLS, SunOS CMW, Trusted Solaris 1.x, Trusted Solaris > > 2.x, Trusted Solaris 7, 8 and TX have always enabled auditing > > and device allocation. This is a TX mode enabling project. > > just because we always did it that way doesn't mean it is correct. Let's focus on what this case is and not something else. As stated in the proposal: TX delivers in the EV directory. The package installation does all the enabling of TX. The EV directory is going away. The EV components need to be integrated integrated into the various "parent" consolidations. Since package installation will no longer be used to enable TX a new mechanism is needed. Proposal ======= 1) The svc:/system/labeld service is only shipped in the global zone, is shipped disabled and not enabled by any SMF profile (it was enabled as part of the TX post installation process). Enabling this service will result in the Trusted Extensions feature being enabled. To accomplish this, if TX is not already enabled, the start method for this service will set the following kernel variable in /etc/system: set sys_labeling=1 In addition, it will enable auditing, enable other previously defined TX services (such as svc:/network/tnd and svc:/system/tsol-zones) and perform the other tasks that had been part of the TX packages post installation process. Disabling svc:/system/labeld results in the disabling of Trusted Extensions, and the above variable setting will be removed from /etc/system. 2) The Project Private lbl_edition kernel module, its contents and usage as described in PSARC 2006/191 will no longer exist; it will be removed if found during upgrade. 3) N.B. Not changed by this proposal is the requirement to reboot to enable TX (thus the rationale to use /etc/system to just set the sys_labeling state). The reboot enforces security policies documented for Trusted Extensions. Due to the handling required for unlabeled and labeled data, zones must be deleted before enabling or disabling TX and a reboot is then used to populate kernel data structures with label-related data that must be present from very early in the boot sequence. The svc:/system/labeld service will enforce these zones restrictions; if zones exist during an attempt to enable or disable, appropriate error messages are logged and the service will enter maintenance state, and no other changes will be made. > Given that this project is actually about the distinction between > installation and enabling of labeled services I think now is the time to > address the issue of labeling forcing auditing to be turned on. It is about an enabling method for TX. The project team originally proposed a new transient service svc:/system/labeled. During project team review it seemed redundant to add a new service with the name labeled when the labeld service was already present. It was also proposed to have a different service name such as svc:/system/tsol or TX or trusted. Perhaps tsol or TX or trusted would make the distinction more apparant. > I quite strongly object to labeling forcing auditing to be turned on. Then derail, call for a vote and write an opinion. If you're in the minority, this passes and we move on. If you're in the majority, get management to create a project to rearchitect TX or back away from the edict to integrate into the WOS gates and continue with the EV install. > Having labeling turn on device allocation I don't really object to > because it needs to be there for labeling of removal media to work > correctly. I don't believe we need to use Solaris Audit just because > we are running labeld. It might be a recommendation or best practice > but I don't believe labeling architecturally requires auditd to be > running, right ? > > I'm particularly concerned about this given we are trying to move to an > architecture (and implementation) where enable/disable of audit doesn't > require a reboot - that will probably result in an EOF of bsmconv as we > know it today. It would be nice if this audit work wasn't tied to > ensuring that enabling labeling services still worked. The case is about preserving TX as it is with a new method to enable it. It is not about Solaris Audit, bsmconv, device allocation or anything else. > BTW yes I'm making assumptions about how this would be implemented but > since the case doesn't say how auditing is turned on thats all I can do. > So what interface for turning on audit is this case proposing to use ? The same way as the approved Layered Trusted Solaris 2002/762 does it. No more, no less. > >> Was any consideration given to this being the admin interface: > >> ---- > >> # netservices labeled > > > > netservices is obsolete. And intended to be removed as soon > > as underlying SMF features permit it. > > Those SMF features don't exist today as an approved architecture this > case can depend on which is why I didn't suggest that. netservices > exists in Nevada and in S10 updates. And the SBD team is working with the SMF team to remove it from Nevada. A more appropriate CLI might be TXconv or tsolconv without a corresponding TXunconv. AAARGGGG, this would fall in line with bsmconv and bsmunconv which the Audit and Hardening projects are trying very hard to get rid of. > My big issue with this case is that turning on svc:/system/labeld turns > on other things by means other than SMF dependencies. The reason for > suggesting netservices(1M) was so that the enabling of labeled services > wasn't tided into a single SMF service. > > What happens if this case: > > I have a system with no zones. > I have auditing enabled and configure to my liking. > I accidentally enable svc:/system/labled and then realise it wasn't > what I thought it was. > I svcadm disable labled. > > Is auditing still enabled ? Not this case. The same things would happen if the EV packages were installed and pkgrm-ed. No change from the currently approved/implemented/shipping TX. Unfortunately, there was the statement made about disabling. Perhaps that should be restated from: Disabling svc:/system/labeld results in the disabling of Trusted Extensions, and the above variable setting will be removed from /etc/system. to: Disabling svc:/system/labeld results in the disabling of Trusted Extensions, and the above variable setting will be removed from /etc/system. Disabling this service is not recommended without consideration for manually returning the system to previous state. svcadm disable svc:/system/labeld will warn. Or even perhaps: Disabling svc:/system/labeld is not supported unless all labeled zones and information have been destroyed and reclassified. > While it might not be a case to concern ourselves much I'm using it to > illustrate the possible problem of having labeling tied to auditing. So you'd prefer a new transient service for doing all the dirty work rather than using an existing service. svc:/system/convert_to_TX_mode_now_and_I_know_what_I-m_doing_really_really Gary.. From William.Young@sun.com Tue May 8 10:37:18 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48HbHNX013102 for ; Tue, 8 May 2007 10:37:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l48Ha783025043; Wed, 9 May 2007 01:36:13 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00215GWA5E00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 May 2007 10:36:10 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00AX7GW91390@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 May 2007 10:36:09 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l48Ha9hE015067; Tue, 08 May 2007 17:36:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHQ00301GDPGY00@mail-amer.sun.com> (original mail from William.Young@Sun.COM); Tue, 08 May 2007 11:36:09 -0600 (MDT) Received: from [10.8.57.21] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHQ00L0NGW3JEZ2@mail-amer.sun.com>; Tue, 08 May 2007 11:36:09 -0600 (MDT) Date: Tue, 08 May 2007 13:36:03 -0400 From: William Young Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <4640A4FD.5000900@Sun.COM> Sender: William.Young@sun.com To: Darren J Moffat Cc: Gary Winiger , PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <4640B503.6000506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705081542.l48Fgdj2027887@marduk.eng.sun.com> <4640A4FD.5000900@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 1792 Darren J Moffat wrote: > Gary Winiger wrote: >>> I would rather that we did not force auditing to be turned on just >>> because labeling was turned on. >> >> SunOS MLS, SunOS CMW, Trusted Solaris 1.x, Trusted Solaris >> 2.x, Trusted Solaris 7, 8 and TX have always enabled auditing >> and device allocation. This is a TX mode enabling project. > > just because we always did it that way doesn't mean it is correct. > > Those other releases are all very different because they don't > distinguish between installation and enabling of the labeled services - > even TX. > > Given that this project is actually about the distinction between > installation and enabling of labeled services I think now is the time to > address the issue of labeling forcing auditing to be turned on. > > I quite strongly object to labeling forcing auditing to be turned on. > Having labeling turn on device allocation I don't really object to > because it needs to be there for labeling of removal media to work > correctly. I don't believe we need to use Solaris Audit just because > we are running labeld. It might be a recommendation or best practice > but I don't believe labeling architecturally requires auditd to be > running, right ? I don't think there is a technical dependency on auditing and I like to run labeled test systems without it, but to use a labeling protocol there is an expectation that the system is meeting the LSPP requirements. I also would not like to return to something like the old processes to get to C2 on solaris. If each of the components is made indpendently configurable, I think it is necessary to have a SMF milestone or service to represent whether the system is at each level which is dependent on the appropriate components. -Will From Darren.Moffat@sun.com Tue May 8 10:58:07 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48Hw7On014208 for ; Tue, 8 May 2007 10:58:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48Hv2L8006041; Tue, 8 May 2007 10:57:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00C0JHV3MR00@nwk-avmta-2.sfbay.sun.com>; Tue, 08 May 2007 10:57:03 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ006P0HV1UR80@nwk-avmta-2.sfbay.sun.com>; Tue, 08 May 2007 10:57:02 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l48Hv0Uk002448; Tue, 08 May 2007 17:57:00 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHQ00N01HU70U00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 08 May 2007 18:57:00 +0100 (BST) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHQ00ET4HV0K510@d1-emea-10.sun.com>; Tue, 08 May 2007 18:57:00 +0100 (BST) Date: Tue, 08 May 2007 18:57:00 +0100 From: Darren J Moffat Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705081735.l48HZY1T028051@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <4640B9EC.7070900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705081735.l48HZY1T028051@marduk.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 1333 I think I've worked out what the core of my problem is: > 1) The svc:/system/labeld service is only shipped in the global zone, > is shipped disabled and not enabled by any SMF profile (it was enabled > as part of the TX post installation process). > Enabling this service will result in the Trusted Extensions feature > being enabled. To accomplish this, if TX is not already enabled, > the start method for this service will set the following kernel > variable in /etc/system: > set sys_labeling=1 > In addition, it will enable auditing, enable other previously defined > TX services (such as svc:/network/tnd and svc:/system/tsol-zones) > and perform the other tasks that had been part of the TX packages post > installation process. Exactly how does *this* case cause audit and those other services to be enabled ? It is different than before because it is no longer done as part of the install of a package. Maybe if this is clearer I might not have such a strong objection. The answer I'd hope for is that using SMF dependencies but that might not be sufficient in the audit case. The reason I have the objection is that I want to ensure that the project that allows for audit to be enabled/disabled at any time doesn't become overly constrained by this proposal. -- Darren J Moffat From gww@eng.sun.com Tue May 8 11:07:56 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48I7t1R014580 for ; Tue, 8 May 2007 11:07:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48I6diB004854 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 8 May 2007 19:06:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ00403IBDVI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 11:06:49 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00AZ1IBD13B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 11:06: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 l48I6ljO009684; Tue, 08 May 2007 11:06:47 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l48I8SxM028137; Tue, 08 May 2007 11:08:28 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l48I8RDa028136; Tue, 08 May 2007 11:08:27 -0700 (PDT) Date: Tue, 08 May 2007 11:08:27 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <200705081808.l48I8RDa028136@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2119 > I think I've worked out what the core of my problem is: > > > 1) The svc:/system/labeld service is only shipped in the global zone, > > is shipped disabled and not enabled by any SMF profile (it was enabled > > as part of the TX post installation process). > > Enabling this service will result in the Trusted Extensions feature > > being enabled. To accomplish this, if TX is not already enabled, > > the start method for this service will set the following kernel > > variable in /etc/system: > > set sys_labeling=1 > > In addition, it will enable auditing, enable other previously defined > > TX services (such as svc:/network/tnd and svc:/system/tsol-zones) > > and perform the other tasks that had been part of the TX packages post > > installation process. > > Exactly how does *this* case cause audit and those other services to be > enabled ? It is different than before because it is no longer done as > part of the install of a package. I'll let the submitter answer this explicitly. These are implementation details. The point of the case is the method of enabling TX when the packages are installed as part of the WOS. That said, ABICT from the project team, the "start" method will include a check to see if TX is installed, if so start labeld. If not, perform some sanity checks. If they fail, log a message and go into maintenance. If the sanity checks succeed, do the same stuff that installing from EV would have done. > Maybe if this is clearer I might not have such a strong objection. > > The answer I'd hope for is that using SMF dependencies but that might > not be sufficient in the audit case. I don't believe there is any SMF dependency. There isn't today. In fact the Audit project team had to fix a number of svc:/system/auditd bugs that TX showed up relative to zones. > The reason I have the objection is that I want to ensure that the > project that allows for audit to be enabled/disabled at any time doesn't > become overly constrained by this proposal. There should be no difference from TX as delivered today. Gary.. From Darren.Moffat@sun.com Tue May 8 11:14:06 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48IE6fD014732 for ; Tue, 8 May 2007 11:14:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48ID3ia014240; Tue, 8 May 2007 11:13:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ0051XILRDN00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 May 2007 11:13:03 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00AXBILO14A0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 May 2007 11:13:02 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l48ID0lJ003789; Tue, 08 May 2007 18:13:00 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHQ00D01IJ5JD00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 08 May 2007 19:13:00 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHQ00BD1ILN1C40@d1-emea-09.sun.com>; Tue, 08 May 2007 19:13:00 +0100 (BST) Date: Tue, 08 May 2007 19:12:59 +0100 From: Darren J Moffat Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705081808.l48I8RDa028136@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-EXT@sun.com, ric.aleshire@sun.com Message-id: <4640BDAB.2030001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705081808.l48I8RDa028136@marduk.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 743 Gary Winiger wrote: > > I'll let the submitter answer this explicitly. These are > implementation details. The point of the case is the method > of enabling TX when the packages are installed as part of the > WOS. Aren't these interfaces that the start method of svc:/system/labeled is importing that it did not before ? If so they are imported interfaces, they may well be Consolidation Private but they are interfaces. I think this case must specify how *this* case has the labeled service turn on auditing and the other stuff that the previous TX cases did at package install time. Doing something from a package postinstall script is quite different to doing it in the start method of an SMF service. -- Darren J Moffat From rica@domus.sfbay.sun.com Tue May 8 11:25:14 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l48IPD5r015098 for ; Tue, 8 May 2007 11:25:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l48IO0Vg009822 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 8 May 2007 19:24:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHQ0061HJ47CX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 11:24:07 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHQ00AJXJ4414B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 08 May 2007 11:24:04 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l48IO3Je024370; Tue, 08 May 2007 11:24:03 -0700 (PDT) Received: (from rica@localhost) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) id l48IO2m10590; Tue, 08 May 2007 11:24:02 -0700 (PDT) Date: Tue, 08 May 2007 11:24:02 -0700 (PDT) From: Ric Aleshire Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: Darren.Moffat@sun.com Cc: PSARC-EXT@sun.com, Gary Winiger Message-id: <200705081824.l48IO2m10590@domus.sfbay.sun.com> MIME-version: 1.0 Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1674 Gary Winiger wrote: > > Exactly how does *this* case cause audit and those other services to be > > enabled ? It is different than before because it is no longer done as > > part of the install of a package. In short, SMF is used where feasible; audit is an obvious exception. > I'll let the submitter answer this explicitly. These are > implementation details. The point of the case is the method > of enabling TX when the packages are installed as part of the > WOS. > > That said, ABICT from the project team, the "start" method will > include a check to see if TX is installed, if so start labeld. > If not, perform some sanity checks. If they fail, log a message and > go into maintenance. If the sanity checks succeed, do the > same stuff that installing from EV would have done. > > Maybe if this is clearer I might not have such a strong objection. > > > > The answer I'd hope for is that using SMF dependencies but that might > > not be sufficient in the audit case. > > I don't believe there is any SMF dependency. There isn't today. > In fact the Audit project team had to fix a number of > svc:/system/auditd bugs that TX showed up relative to zones. > > > The reason I have the objection is that I want to ensure that the > > project that allows for audit to be enabled/disabled at any time doesn't > > become overly constrained by this proposal. In my guess it shouldn't. After the forthcoming "no-reboot" audit project, the TX code to enable audit would need to be eliminated or replaced with SMF commands, but that should be it. > There should be no difference from TX as delivered today. > > Gary.. > From Darren.Moffat@sun.com Wed May 9 02:56:04 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l499u4X2000913 for ; Wed, 9 May 2007 02:56:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l499t1k0018174; Wed, 9 May 2007 02:55:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHR0070JQ7PP500@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 May 2007 02:55:01 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHR00MQOQ7ON8D0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 May 2007 02:55:00 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l499sxXY018761; Wed, 09 May 2007 09:54:59 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHR00201Q3W4T00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 09 May 2007 10:54:59 +0100 (BST) Received: from [129.150.120.43] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHR00AIAQ7H7T10@d1-emea-09.sun.com>; Wed, 09 May 2007 10:54:54 +0100 (BST) Date: Wed, 09 May 2007 10:54:52 +0100 From: Darren J Moffat Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705081824.l48IO2m10590@domus.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Ric Aleshire Cc: PSARC-EXT@sun.com, Gary Winiger Message-id: <46419A6C.4030905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705081824.l48IO2m10590@domus.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 627 Ric Aleshire wrote: > In my guess it shouldn't. After the forthcoming "no-reboot" audit project, > the TX code to enable audit would need to be eliminated or replaced with > SMF commands, but that should be it. Those are two very different outcomes though. Eliminated is saying that labeling shouldn't require audit Replace with the SMF commands says that it should in reality I would expect a dependency relationship between label and audit services to be used. So what does the project team believe really should be the tie between labeling and audit ? Should labeling force audit on or not ? -- Darren J Moffat From rica@domus.sfbay.sun.com Wed May 9 07:29:37 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l49ETaQ2010253 for ; Wed, 9 May 2007 07:29:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l49ESP9p013043 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 9 May 2007 22:28:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHS0090H2VIXV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 May 2007 07:28:30 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHS006KQ2VH3O50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 May 2007 07:28:29 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l49ESRlS009311; Wed, 09 May 2007 07:28:27 -0700 (PDT) Received: (from rica@localhost) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) id l49ESRO20725; Wed, 09 May 2007 07:28:27 -0700 (PDT) Date: Wed, 09 May 2007 07:28:27 -0700 (PDT) From: Ric Aleshire Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: Darren J Moffat Cc: PSARC-EXT@Sun.COM, Gary Winiger Message-id: <200705091428.l49ESRO20725@domus.sfbay.sun.com> MIME-version: 1.0 Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 859 Darren J Moffat wrote: > Ric Aleshire wrote: > > > In my guess it shouldn't. After the forthcoming "no-reboot" audit project, > > the TX code to enable audit would need to be eliminated or replaced with > > SMF commands, but that should be it. > > Those are two very different outcomes though. > > Eliminated is saying that labeling shouldn't require audit > > Replace with the SMF commands says that it should > in reality I would expect a dependency relationship between > label and audit services to be used. > > So what does the project team believe really should be the tie between > labeling and audit ? Should labeling force audit on or not ? Labeling does require that audit is turned on. In mentioning "eliminating" TX audit enabling, I was considering the possiblilty that audit would alsways be enabled. -Ric From Darren.Moffat@sun.com Wed May 9 07:32:35 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l49EWZ2v010344 for ; Wed, 9 May 2007 07:32:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l49EVUjo027804; Wed, 9 May 2007 07:31:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHS00A0J30J7M00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 May 2007 07:31:31 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHS006HZ30I3L60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 May 2007 07:31:31 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l49EVTSd000293; Wed, 09 May 2007 14:31:29 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHS004012XF6700@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 09 May 2007 15:31:29 +0100 (BST) Received: from [129.150.120.43] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHS00HOO30GO010@d1-emea-10.sun.com>; Wed, 09 May 2007 15:31:29 +0100 (BST) Date: Wed, 09 May 2007 15:31:28 +0100 From: Darren J Moffat Subject: Re: 2007/254 - Enabling method for Trusted Extensions In-reply-to: <200705091428.l49ESRO20725@domus.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Ric Aleshire Cc: PSARC-EXT@sun.com, Gary Winiger Message-id: <4641DB40.2070003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705091428.l49ESRO20725@domus.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1213 Ric Aleshire wrote: > Darren J Moffat wrote: >> Ric Aleshire wrote: >> >>> In my guess it shouldn't. After the forthcoming "no-reboot" audit project, >>> the TX code to enable audit would need to be eliminated or replaced with >>> SMF commands, but that should be it. >> Those are two very different outcomes though. >> >> Eliminated is saying that labeling shouldn't require audit >> >> Replace with the SMF commands says that it should >> in reality I would expect a dependency relationship between >> label and audit services to be used. >> >> So what does the project team believe really should be the tie between >> labeling and audit ? Should labeling force audit on or not ? > > Labeling does require that audit is turned on. In mentioning "eliminating" > TX audit enabling, I was considering the possiblilty that audit would > alsways be enabled. Okay, I hadn't considered that as a possible future state. Thats an interesting enough possible future outcome that I'm willing to hold my nose on this just now and let this case go ahead. We can revisit this as part of the future audit case that removes the bsmconv/reboot step for audit enabling. -- Darren J Moffat From gww@eng.sun.com Wed May 9 07:56:04 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l49Eu3uP011797 for ; Wed, 9 May 2007 07:56:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l49Et05l003211 for <@newsunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Wed, 9 May 2007 07:55:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHS00K0143OPG00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 May 2007 08:55:00 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHS00HG943NZB20@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 May 2007 08:54:59 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l49Esvjk017799; Wed, 09 May 2007 07:54:57 -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 l49Eud9v029469; Wed, 09 May 2007 07:56:39 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l49Eudqg029468; Wed, 09 May 2007 07:56:39 -0700 (PDT) Date: Wed, 09 May 2007 07:56:39 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: Ric.Aleshire@sun.com, Darren.Moffat@sun.com Cc: PSARC-EXT@sun.com, gww@eng.sun.com Message-id: <200705091456.l49Eudqg029468@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2004 > Ric Aleshire wrote: > > Darren J Moffat wrote: > >> Ric Aleshire wrote: > >> > >>> In my guess it shouldn't. After the forthcoming "no-reboot" audit project, > >>> the TX code to enable audit would need to be eliminated or replaced with > >>> SMF commands, but that should be it. > >> Those are two very different outcomes though. > >> > >> Eliminated is saying that labeling shouldn't require audit > >> > >> Replace with the SMF commands says that it should > >> in reality I would expect a dependency relationship between > >> label and audit services to be used. > >> > >> So what does the project team believe really should be the tie between > >> labeling and audit ? Should labeling force audit on or not ? > > > > Labeling does require that audit is turned on. In mentioning "eliminating" > > TX audit enabling, I was considering the possiblilty that audit would > > alsways be enabled. > > Okay, I hadn't considered that as a possible future state. Thats an > interesting enough possible future outcome that I'm willing to hold my > nose on this just now and let this case go ahead. We can revisit this > as part of the future audit case that removes the bsmconv/reboot step > for audit enabling. We've wandered off topic (again ;-). This case is not about audit or enabling audit or where audit comes into play. This case is about enabling TX. The very same TX as approved and implemented. The enabling mechanism is proposed to change from pkgadd of the EV directory to, the packages are there, now run svcadm. Reboot, configuration, definition of TX, interfaces used (except for /etc/system) are all unchanged. If svcadm is not the correct architecture, that's a topical discussion point. If the depricated /etc/system is not correct architecture, that's a topical discussion point -- that I thought had been put to rest. Whether TX should or should not enable auditing and how it does so is unchanged from the 2002/762 case. Gary.. From gww@eng.sun.com Wed May 9 13:03:15 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l49K3FAv029679 for ; Wed, 9 May 2007 13:03:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l49K2CTH018056 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 May 2007 13:02:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHS00D03IBLOI00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 May 2007 13:02:09 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHS0031FIBLRPE0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 May 2007 13:02:09 -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 l49K28xe027740; Wed, 09 May 2007 13:02:08 -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 l49K3pxl029994; Wed, 09 May 2007 13:03:51 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l49K3oVm029993; Wed, 09 May 2007 13:03:50 -0700 (PDT) Date: Wed, 09 May 2007 13:03:50 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/254 - Enabling method for Trusted Extensions To: gww@sac.sfbay.sun.com, psarc-ext@sun.com Cc: ric.aleshire@sun.com Message-id: <200705092003.l49K3oVm029993@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 160 This case was approved as originally speced at today's PSARC meeting. For clarity, spec.txt in the case directory containes the original specification. Gary..