From Alan.Coopersmith@sun.com Wed Aug 6 16:36:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m76Na0UQ000137 for ; Wed, 6 Aug 2008 16:36:01 -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 m76NZCrt005839; Thu, 7 Aug 2008 07:35:58 +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 <0K5700E03DJVJD00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Aug 2008 16:35:55 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K570047UDJUYE60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Aug 2008 16:35:54 -0700 (PDT) Received: from almas.sfbay.sun.com (localhost [127.0.0.1]) by almas.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m76NZs0f002562; Wed, 06 Aug 2008 16:35:54 -0700 (PDT) Received: (from alanc@localhost) by almas.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m76NZsPN002559; Wed, 06 Aug 2008 16:35:54 -0700 (PDT) Date: Wed, 06 Aug 2008 16:35:54 -0700 (PDT) From: Alan Coopersmith Subject: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: LSARC-ext@sun.com Cc: Glenn.Faden@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3672 I am sponsoring this fasttrack for Ric Aleshire & Lokanath Das of the Trusted Extensions team, and have set the timeout for one week from today, Thursday, August 14. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Unix Domain Sockets for X11 clients in Trusted Extensions 1.2. Name of Document Author/Supplier: Author: Richard Aleshire 1.3 Date of This Document: 06 August, 2008 4. Technical Description This fast-track makes changes related to Trusted Extensions in the handling and use of Unix Domain sockets for X11 clients. A micro/patch release binding is requested. Problem The X11 server supports several transports: UNIX domain sockets, pipes, or TCP networking. In Trusted Extensions, X11 clients run in labeled zone and cannot use UNIX domain sockets to reach the X11 server in the global zone. Therefore they must rely on TCP connections which implies that each zone must have a network interface. A common TX configuration is to use "all-zones" interfaces, so that labeled zones and the global zone can share the same IP address. Labeled zone clients set their DISPLAY environment to the hostname of the global zone to connect to the X11 server. For example: DISPLAY=foobar:0 To avoid the requirement of configuring a network interface in each zone, the loopback interface is now configured automatically as an all-zones interface. Starting with Nevada build 82 and S10u6_03, it can be used by labeled zone clients for TCP X11 connections. This allowed settings like: DISPLAY=localhost:0 or DISPLAY=:0 to both work, as well. In the latter case, it worked because Xlib fell back to try localhost after UNIX domain failed. However, starting in Nevada build 85, the X library has been changed to use UNIX domain sockets if the DISPLAY variable matches the local hostname (as it does with labeled zones). When a connection fails, it retries up to 4 more times, sleeping between each try, before falling back to another connection type (such as TCP). As a result, TX clients either fail to connect or take 15 seconds to make the connection. The only workaround we have now is to explicitly set the DISPLAY to localhost:0. Solution a) Allow labeled zones to access global zone X11 server via UNIX domain sockets If Trusted Extensions is enabled, the kernel will permit labeled zones to connect to global zone clients if the global zone UNIX domain rendezvous file is made available to the zone via a loopback mount. b) The X11 server will use a new rendezvous directory when TX is enabled. Normally, the UNIX domain rendezvous files are in the directory /tmp/.X11-unix. To allow the rendezvous files to be exported to labeled zones, the directory pathname will be changed to: /var/tsol/door/.X11-unix. This directory pathname is chosen because /var/tsol/doors is already loopback mounted into every labeled zone, to export the door rendezvous files for nscd and the label daemon. To make this change transparent to clients, a symbolic link to /tmp/.X11-unix will be created in each zone, including the global zone. This solution will permit labeled zone X11 clients to use any of the various DISPLAY environment variables they have been using previously, and not require the use of TCP. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Kais.Belgaied@Sun.COM Wed Aug 6 20:11:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m773Bhbe006928 for ; Wed, 6 Aug 2008 20:11:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m773BcEp029930; Thu, 7 Aug 2008 04:11:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5700K0FNJE9R00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Aug 2008 20:11:38 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K57007RYNJESFC0@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Aug 2008 20:11:38 -0700 (PDT) Received: from [129.146.11.145] (sr1-jurassic-02.SFBay.Sun.COM [129.146.11.145]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m773BbxM226610; Wed, 06 Aug 2008 20:11:38 -0700 (PDT) Date: Wed, 06 Aug 2008 20:11:37 -0700 From: Kais Belgaied Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> To: Alan Coopersmith Cc: LSARC-ext@Sun.COM, Glenn.Faden@Sun.COM, Lokanath.Das@Sun.COM, Ric.Aleshire@Sun.COM Reply-to: Kais.Belgaied@Sun.COM Message-id: <489A67E9.8040301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 1442 > Solution > > a) Allow labeled zones to access global zone X11 server via UNIX domain sockets > > If Trusted Extensions is enabled, the kernel will permit labeled zones > to connect to global zone clients if the global zone UNIX domain > rendezvous file is made available to the zone via a loopback mount. > When you do (b), (a) follows naturally without any extra change. connect(3SOCKET)'ing to the AF_UNIX socket named /var/tsol/door/.X11-unix will succeed the moment that node is visible to the zone. Am I missing a change proposed in sockfs or other part of the Solaris kernel as part of this case? Kais. > > b) The X11 server will use a new rendezvous directory when TX is enabled. > > Normally, the UNIX domain rendezvous files are in the directory /tmp/.X11-unix. > To allow the rendezvous files to be exported to labeled zones, the directory > pathname will be changed to: > > /var/tsol/door/.X11-unix. > > This directory pathname is chosen because /var/tsol/doors is already > loopback mounted into every labeled zone, to export the door rendezvous > files for nscd and the label daemon. To make this change transparent to > clients, a symbolic link to /tmp/.X11-unix will be created in each zone, > including the global zone. > > This solution will permit labeled zone X11 clients to use any of the > various DISPLAY environment variables they have been using previously, > and not require the use of TCP. > > From ric.aleshire@Sun.COM Thu Aug 7 13:31:29 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m77KVS9N003424 for ; Thu, 7 Aug 2008 13:31: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 m77KVQhY002430 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 8 Aug 2008 04:31: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 <0K5800J03ZOEZH00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 07 Aug 2008 13:31:26 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5800HZ9ZODGN60@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 07 Aug 2008 13:31:25 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m77KVO2V016755; Thu, 07 Aug 2008 13:31:24 -0700 (PDT) Received: from [127.0.0.1] (vpn-129-150-16-50.SFBay.Sun.COM [129.150.16.50]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m77KVNV15114; Thu, 07 Aug 2008 13:31:23 -0700 (PDT) Date: Thu, 07 Aug 2008 13:31:22 -0700 From: Ric Aleshire Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <489A67E9.8040301@Sun.COM> To: Kais.Belgaied@Sun.COM Cc: Alan Coopersmith , LSARC-ext@Sun.COM, Glenn.Faden@Sun.COM, Lokanath.Das@Sun.COM Message-id: <489B5B9A.8020700@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Antivirus: avast! (VPS 080807-0, 08/07/2008), Outbound message X-Antivirus-Status: Clean References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <489A67E9.8040301@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 1861 Kais Belgaied wrote: > >> Solution >> >> a) Allow labeled zones to access global zone X11 server via UNIX >> domain sockets >> >> If Trusted Extensions is enabled, the kernel will permit labeled zones >> to connect to global zone clients if the global zone UNIX domain >> rendezvous file is made available to the zone via a loopback mount. >> > > When you do (b), (a) follows naturally without any extra change. > connect(3SOCKET)'ing to the AF_UNIX > socket named /var/tsol/door/.X11-unix will succeed the moment that > node is visible to the zone. > > Am I missing a change proposed in sockfs or other part of the Solaris > kernel as part of this case? > > Kais. Yes - currently in the kernel socket I/O code, there is a check that the AF_UNIX socket endpoint is in the same zone as the server peer. The proposal for a) above means that this check will be modified, so that when TX is enabled and the socket zone and server zone do not match, then the server must be in the global zone. -Ric >> b) The X11 server will use a new rendezvous directory when TX is >> enabled. >> >> Normally, the UNIX domain rendezvous files are in the directory >> /tmp/.X11-unix. >> To allow the rendezvous files to be exported to labeled zones, the >> directory >> pathname will be changed to: >> >> /var/tsol/door/.X11-unix. >> >> This directory pathname is chosen because /var/tsol/doors is already >> loopback mounted into every labeled zone, to export the door rendezvous >> files for nscd and the label daemon. To make this change transparent to >> clients, a symbolic link to /tmp/.X11-unix will be created in each zone, >> including the global zone. >> >> This solution will permit labeled zone X11 clients to use any of the >> various DISPLAY environment variables they have been using previously, >> and not require the use of TCP. >> >> > From Alan.Coopersmith@Sun.COM Thu Aug 7 14:14:54 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m77LEsjP005822 for ; Thu, 7 Aug 2008 14:14:54 -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 m77LEr85011770; Thu, 7 Aug 2008 14:14:53 -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 <0K5900J011OTVW00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 14:14:53 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900GP81OTTY30@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 14:14:53 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m77LEr39020553; Thu, 07 Aug 2008 14:14:53 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5900J011KJEW00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Thu, 07 Aug 2008 14:14:53 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5900D1J1OSGV30@fe-sfbay-10.sun.com>; Thu, 07 Aug 2008 14:14:53 -0700 (PDT) Date: Thu, 07 Aug 2008 14:14:52 -0700 From: Alan Coopersmith Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <489B5B9A.8020700@sun.com> Sender: Alan.Coopersmith@Sun.COM To: Ric Aleshire Cc: Kais.Belgaied@Sun.COM, LSARC-ext@Sun.COM, Glenn.Faden@Sun.COM, Lokanath.Das@Sun.COM Message-id: <489B65CC.7030405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <489A67E9.8040301@Sun.COM> <489B5B9A.8020700@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 779 Ric Aleshire wrote: > Yes - currently in the kernel socket I/O code, there is a check that the > AF_UNIX socket endpoint is in the same > zone as the server peer. The proposal for a) above means that this > check will be modified, so that when TX is > enabled and the socket zone and server zone do not match, then the > server must be in the global zone. Which raises the interesting question of whether that check should really be for TX, or if this should be something that can be set on for any machine with Zones, and which TX just happens to always set. It would seem things like running X clients in Etude or BrandZ zones could also benefit from this. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Nicolas.Williams@Sun.COM Thu Aug 7 14:18:30 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m77LIT8p005887 for ; Thu, 7 Aug 2008 14:18:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m77LINEw039826; Thu, 7 Aug 2008 15:18:28 -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 <0K5900L031URV800@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 14:18:27 -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 <0K5900HIJ1URGRE0@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Aug 2008 14:18:27 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m77LI7em012054; Thu, 07 Aug 2008 16:18:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m77LI7JO012053; Thu, 07 Aug 2008 16:18:07 -0500 (CDT) Date: Thu, 07 Aug 2008 16:18:06 -0500 From: Nicolas Williams Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <489B65CC.7030405@sun.com> To: Alan Coopersmith Cc: Ric Aleshire , Kais.Belgaied@Sun.COM, Glenn.Faden@Sun.COM, LSARC-ext@Sun.COM, Lokanath.Das@Sun.COM Message-id: <20080807211806.GA25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <489A67E9.8040301@Sun.COM> <489B5B9A.8020700@sun.com> <489B65CC.7030405@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: 894 On Thu, Aug 07, 2008 at 02:14:52PM -0700, Alan Coopersmith wrote: > Ric Aleshire wrote: > > Yes - currently in the kernel socket I/O code, there is a check that the > > AF_UNIX socket endpoint is in the same > > zone as the server peer. The proposal for a) above means that this > > check will be modified, so that when TX is > > enabled and the socket zone and server zone do not match, then the > > server must be in the global zone. > > Which raises the interesting question of whether that check should really > be for TX, or if this should be something that can be set on for any machine > with Zones, and which TX just happens to always set. It would seem things > like running X clients in Etude or BrandZ zones could also benefit from this. I agree, though being careful to use untrusted cookies, of course. The problem this case is trying to solve affects non-TX zones uses too. From Kais.Belgaied@sun.com Thu Aug 7 16:16:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m77NGc6i009858 for ; Thu, 7 Aug 2008 16:16:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m77NGWIx008005; Fri, 8 Aug 2008 00:16:34 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5900A017BMS200@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 16:16:34 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5900AYD7BLFR00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Aug 2008 16:16:33 -0700 (PDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m77NGXSp181201; Thu, 07 Aug 2008 16:16:33 -0700 (PDT) Date: Thu, 07 Aug 2008 16:16:33 -0700 From: Kais Belgaied Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <20080807211806.GA25547@Sun.COM> To: Nicolas Williams Cc: Alan Coopersmith , Ric Aleshire , Glenn.Faden@sun.com, LSARC-ext@sun.com, Lokanath.Das@sun.com Reply-to: Kais.Belgaied@sun.com Message-id: <489B8251.3030306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <489A67E9.8040301@Sun.COM> <489B5B9A.8020700@sun.com> <489B65CC.7030405@sun.com> <20080807211806.GA25547@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 1214 Nicolas Williams wrote: > On Thu, Aug 07, 2008 at 02:14:52PM -0700, Alan Coopersmith wrote: > >> Ric Aleshire wrote: >> >>> Yes - currently in the kernel socket I/O code, there is a check that the >>> AF_UNIX socket endpoint is in the same >>> zone as the server peer. The proposal for a) above means that this >>> check will be modified, so that when TX is >>> enabled and the socket zone and server zone do not match, then the >>> server must be in the global zone. >>> Thanks for the answer Ric. >> Which raises the interesting question of whether that check should really >> be for TX, or if this should be something that can be set on for any machine >> with Zones, and which TX just happens to always set. It would seem things >> like running X clients in Etude or BrandZ zones could also benefit from this. >> this sounds tempting. anyway, the project team has the choice here whether to keep the scope of this case as-is, or extend it tp permit privileged cross-zone communication through AF_UNIX sockets beyond tx. Kais > I agree, though being careful to use untrusted cookies, of course. > > The problem this case is trying to solve affects non-TX zones uses too. > From edward.pilatowicz@sun.com Fri Aug 8 14:09:23 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m78L9MLg016670 for ; Fri, 8 Aug 2008 14:09:23 -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 m78L99Hf023535; Sat, 9 Aug 2008 05:09:18 +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 <0K5A00203W3FH700@brm-avmta-1.central.sun.com>; Fri, 08 Aug 2008 15:09:15 -0600 (MDT) Received: from mcescher.eng.sun.com ([129.146.224.55]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5A00EGOW3EQ6A0@brm-avmta-1.central.sun.com>; Fri, 08 Aug 2008 15:09:14 -0600 (MDT) Received: from mcescher.eng.sun.com (localhost [127.0.0.1]) by mcescher.eng.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m78L9EUA284043; Fri, 08 Aug 2008 14:09:14 -0700 (PDT) Received: (from edp@localhost) by mcescher.eng.sun.com (8.14.3+Sun/8.14.3/Submit) id m78L9E26284042; Fri, 08 Aug 2008 14:09:14 -0700 (PDT) Date: Fri, 08 Aug 2008 14:09:14 -0700 From: Edward Pilatowicz Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> To: Alan Coopersmith Cc: LSARC-ext@sun.com, Glenn.Faden@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <20080808210912.GA283721@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> X-Authentication-warning: mcescher.eng.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 4823 hey ric and lokanath, i work on the zones team and i've always been interested in allowing xclients from non-global and non-labeled zones with no networking to access an x server in the global zone. the loopback network interface doesn't work for this purposes because non-labeled zones don't use the all-zones interfaces flag. so i'd be interested in seeing unix domain sockets allow for cross zone communication in all zones, not just labeled zones. i also would like to minimize the number of non-obvious "special" system behaviors for labeled zones. my one concern about this is the security implications. so when were unix domain sockets modified to disallow cross zone communication? was this done by the original zones case? or by trusted extensions? looking back at the original case that disallowed for this behavior might provide some insight into the security reasons related to this restriction. ed On Wed, Aug 06, 2008 at 04:35:54PM -0700, Alan Coopersmith wrote: > I am sponsoring this fasttrack for Ric Aleshire & Lokanath Das of the > Trusted Extensions team, and have set the timeout for one week from today, > Thursday, August 14. > > -Alan Coopersmith- alan.coopersmith@sun.com > Sun Microsystems, Inc. - X Window System Engineering > > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Unix Domain Sockets for X11 clients in Trusted Extensions > 1.2. Name of Document Author/Supplier: > Author: Richard Aleshire > 1.3 Date of This Document: > 06 August, 2008 > 4. Technical Description > > This fast-track makes changes related to Trusted Extensions in the > handling and use of Unix Domain sockets for X11 clients. A micro/patch > release binding is requested. > > > Problem > > The X11 server supports several transports: UNIX domain sockets, pipes, > or TCP networking. In Trusted Extensions, X11 clients run in labeled > zone and cannot use UNIX domain sockets to reach the X11 server in the > global zone. Therefore they must rely on TCP connections which implies > that each zone must have a network interface. A common TX configuration > is to use "all-zones" interfaces, so that labeled zones and the global > zone can share the same IP address. Labeled zone clients set their > DISPLAY environment to the hostname of the global zone to connect to > the X11 server. For example: > > DISPLAY=foobar:0 > > To avoid the requirement of configuring a network interface in each > zone, the loopback interface is now configured automatically as an > all-zones interface. Starting with Nevada build 82 and S10u6_03, it can > be used by labeled zone clients for TCP X11 connections. This allowed > settings like: > > DISPLAY=localhost:0 > or > DISPLAY=:0 > > to both work, as well. In the latter case, it worked because Xlib fell > back to try localhost after UNIX domain failed. > > However, starting in Nevada build 85, the X library has been changed to > use UNIX domain sockets if the DISPLAY variable matches the local > hostname (as it does with labeled zones). When a connection fails, > it retries up to 4 more times, sleeping between each try, before falling > back to another connection type (such as TCP). > > As a result, TX clients either fail to connect or take 15 seconds to > make the connection. The only workaround we have now is to explicitly > set the DISPLAY to localhost:0. > > Solution > > a) Allow labeled zones to access global zone X11 server via UNIX domain sockets > > If Trusted Extensions is enabled, the kernel will permit labeled zones > to connect to global zone clients if the global zone UNIX domain > rendezvous file is made available to the zone via a loopback mount. > > > b) The X11 server will use a new rendezvous directory when TX is enabled. > > Normally, the UNIX domain rendezvous files are in the directory /tmp/.X11-unix. > To allow the rendezvous files to be exported to labeled zones, the directory > pathname will be changed to: > > /var/tsol/door/.X11-unix. > > This directory pathname is chosen because /var/tsol/doors is already > loopback mounted into every labeled zone, to export the door rendezvous > files for nscd and the label daemon. To make this change transparent to > clients, a symbolic link to /tmp/.X11-unix will be created in each zone, > including the global zone. > > This solution will permit labeled zone X11 clients to use any of the > various DISPLAY environment variables they have been using previously, > and not require the use of TCP. > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > X > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From Glenn.Faden@sun.com Fri Aug 8 14:54:56 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m78Lstin017186 for ; Fri, 8 Aug 2008 14:54:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m78Lspeq012652 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 8 Aug 2008 22:54:54 +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 <0K5A00M01Y7IHG00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 08 Aug 2008 14:54:54 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5A0088DY7IN2D0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 08 Aug 2008 14:54:54 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m78LssEh023280 for ; Fri, 08 Aug 2008 14:54:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5A00H01Y2QCY00@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 08 Aug 2008 14:54:54 -0700 (PDT) Received: from rampartgf.local ([69.144.34.25]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5A0091PY7F6K80@fe-sfbay-09.sun.com>; Fri, 08 Aug 2008 14:54:52 -0700 (PDT) Date: Fri, 08 Aug 2008 14:54:50 -0700 From: Glenn Faden Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <20080808210912.GA283721@eng.sun.com> Sender: Glenn.Faden@sun.com To: Edward Pilatowicz Cc: Alan Coopersmith , LSARC-ext@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <489CC0AA.10904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <20080808210912.GA283721@eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 6088 Ed, The kernel changes to permit cross-zone UNIX domain sockets haven't been putback yet. Ric will be doing that. The new policy is restricted such that the server must be in the global zone. Although I agree that we should minimize the uniqueness of labeled zones, we would need some other way to distinguish between environments where there is a single uid namespace across zones, and the case where zones have unique uids. In TX we require the former since the X server enforces access controls for all X resources based on the client's. The TX Xorg server is extensively modified to maintain client credentials and to protect resources on a per-zone and per-user basis. Since TX enforces a restriction that the uids are shared across zones, it is not required for a client in a labeled zone to present MIT-COOKIE tokens or other authentication data. We just rely on the uid acquired via getpeerucred. I think the current behavior of X11 in labeled zones is already substantially different from standard Solaris, so this case should only focus on TX behavior. --Glenn Edward Pilatowicz wrote: > hey ric and lokanath, > > i work on the zones team and i've always been interested in allowing > xclients from non-global and non-labeled zones with no networking to > access an x server in the global zone. the loopback network interface > doesn't work for this purposes because non-labeled zones don't use the > all-zones interfaces flag. > > so i'd be interested in seeing unix domain sockets allow for cross > zone communication in all zones, not just labeled zones. i also would > like to minimize the number of non-obvious "special" system behaviors > for labeled zones. > > my one concern about this is the security implications. so when were > unix domain sockets modified to disallow cross zone communication? > was this done by the original zones case? or by trusted extensions? > looking back at the original case that disallowed for this behavior > might provide some insight into the security reasons related to > this restriction. > > ed > > On Wed, Aug 06, 2008 at 04:35:54PM -0700, Alan Coopersmith wrote: > >> I am sponsoring this fasttrack for Ric Aleshire & Lokanath Das of the >> Trusted Extensions team, and have set the timeout for one week from today, >> Thursday, August 14. >> >> -Alan Coopersmith- alan.coopersmith@sun.com >> Sun Microsystems, Inc. - X Window System Engineering >> >> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Unix Domain Sockets for X11 clients in Trusted Extensions >> 1.2. Name of Document Author/Supplier: >> Author: Richard Aleshire >> 1.3 Date of This Document: >> 06 August, 2008 >> 4. Technical Description >> >> This fast-track makes changes related to Trusted Extensions in the >> handling and use of Unix Domain sockets for X11 clients. A micro/patch >> release binding is requested. >> >> >> Problem >> >> The X11 server supports several transports: UNIX domain sockets, pipes, >> or TCP networking. In Trusted Extensions, X11 clients run in labeled >> zone and cannot use UNIX domain sockets to reach the X11 server in the >> global zone. Therefore they must rely on TCP connections which implies >> that each zone must have a network interface. A common TX configuration >> is to use "all-zones" interfaces, so that labeled zones and the global >> zone can share the same IP address. Labeled zone clients set their >> DISPLAY environment to the hostname of the global zone to connect to >> the X11 server. For example: >> >> DISPLAY=foobar:0 >> >> To avoid the requirement of configuring a network interface in each >> zone, the loopback interface is now configured automatically as an >> all-zones interface. Starting with Nevada build 82 and S10u6_03, it can >> be used by labeled zone clients for TCP X11 connections. This allowed >> settings like: >> >> DISPLAY=localhost:0 >> or >> DISPLAY=:0 >> >> to both work, as well. In the latter case, it worked because Xlib fell >> back to try localhost after UNIX domain failed. >> >> However, starting in Nevada build 85, the X library has been changed to >> use UNIX domain sockets if the DISPLAY variable matches the local >> hostname (as it does with labeled zones). When a connection fails, >> it retries up to 4 more times, sleeping between each try, before falling >> back to another connection type (such as TCP). >> >> As a result, TX clients either fail to connect or take 15 seconds to >> make the connection. The only workaround we have now is to explicitly >> set the DISPLAY to localhost:0. >> >> Solution >> >> a) Allow labeled zones to access global zone X11 server via UNIX domain sockets >> >> If Trusted Extensions is enabled, the kernel will permit labeled zones >> to connect to global zone clients if the global zone UNIX domain >> rendezvous file is made available to the zone via a loopback mount. >> >> >> b) The X11 server will use a new rendezvous directory when TX is enabled. >> >> Normally, the UNIX domain rendezvous files are in the directory /tmp/.X11-unix. >> To allow the rendezvous files to be exported to labeled zones, the directory >> pathname will be changed to: >> >> /var/tsol/door/.X11-unix. >> >> This directory pathname is chosen because /var/tsol/doors is already >> loopback mounted into every labeled zone, to export the door rendezvous >> files for nscd and the label daemon. To make this change transparent to >> clients, a symbolic link to /tmp/.X11-unix will be created in each zone, >> including the global zone. >> >> This solution will permit labeled zone X11 clients to use any of the >> various DISPLAY environment variables they have been using previously, >> and not require the use of TCP. >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> X >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> From Edward.Pilatowicz@sun.com Fri Aug 8 15:43:23 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m78MhMYN018078 for ; Fri, 8 Aug 2008 15:43:22 -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 m78MhKUh043141; Fri, 8 Aug 2008 16:43:21 -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 <0K5B009010G8M800@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Aug 2008 15:43:20 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5B005PS0G8B3C0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Aug 2008 15:43:20 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m78MhKQu360947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 08 Aug 2008 15:43:20 -0700 (PDT) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m78MhKol360946; Fri, 08 Aug 2008 15:43:20 -0700 (PDT) Date: Fri, 08 Aug 2008 15:43:19 -0700 From: Edward Pilatowicz Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <489CC0AA.10904@sun.com> To: Glenn Faden Cc: Alan Coopersmith , LSARC-ext@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <20080808224319.GF314160@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <20080808210912.GA283721@eng.sun.com> <489CC0AA.10904@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 6527 On Fri, Aug 08, 2008 at 02:54:50PM -0700, Glenn Faden wrote: > Ed, > > The kernel changes to permit cross-zone UNIX domain sockets haven't been > putback yet. Ric will be doing that. The new policy is restricted such that > the server must be in the global zone. Although I agree that we should > minimize the uniqueness of labeled zones, we would need some other way to > distinguish between environments where there is a single uid namespace > across zones, and the case where zones have unique uids. In TX we require > the former since the X server enforces access controls for all X resources > based on the client's. The TX Xorg server is extensively modified to > maintain client credentials and to protect resources on a per-zone and > per-user basis. Since TX enforces a restriction that the uids are shared > across zones, it is not required for a client in a labeled zone to present > MIT-COOKIE tokens or other authentication data. We just rely on the uid > acquired via getpeerucred. > > I think the current behavior of X11 in labeled zones is already > substantially different from standard Solaris, so this case should only > focus on TX behavior. > i'm not asking about the X11 behavior wrt zones, i'm asking about the cross-zone domain sockets behavior. has cross-zone UNIX domain traffic always been disallowed since zones were introduced? if not, when was that restriction added? > --Glenn > > > Edward Pilatowicz wrote: >> hey ric and lokanath, >> >> i work on the zones team and i've always been interested in allowing >> xclients from non-global and non-labeled zones with no networking to >> access an x server in the global zone. the loopback network interface >> doesn't work for this purposes because non-labeled zones don't use the >> all-zones interfaces flag. >> >> so i'd be interested in seeing unix domain sockets allow for cross >> zone communication in all zones, not just labeled zones. i also would >> like to minimize the number of non-obvious "special" system behaviors >> for labeled zones. >> >> my one concern about this is the security implications. so when were >> unix domain sockets modified to disallow cross zone communication? >> was this done by the original zones case? or by trusted extensions? >> looking back at the original case that disallowed for this behavior >> might provide some insight into the security reasons related to >> this restriction. >> >> ed >> >> On Wed, Aug 06, 2008 at 04:35:54PM -0700, Alan Coopersmith wrote: >> >>> I am sponsoring this fasttrack for Ric Aleshire & Lokanath Das of the >>> Trusted Extensions team, and have set the timeout for one week from today, >>> Thursday, August 14. >>> >>> -Alan Coopersmith- alan.coopersmith@sun.com >>> Sun Microsystems, Inc. - X Window System Engineering >>> >>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >>> This information is Copyright 2008 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Unix Domain Sockets for X11 clients in Trusted Extensions >>> 1.2. Name of Document Author/Supplier: >>> Author: Richard Aleshire >>> 1.3 Date of This Document: >>> 06 August, 2008 >>> 4. Technical Description >>> >>> This fast-track makes changes related to Trusted Extensions in the >>> handling and use of Unix Domain sockets for X11 clients. A micro/patch >>> release binding is requested. >>> >>> >>> Problem >>> >>> The X11 server supports several transports: UNIX domain sockets, pipes, >>> or TCP networking. In Trusted Extensions, X11 clients run in labeled >>> zone and cannot use UNIX domain sockets to reach the X11 server in the >>> global zone. Therefore they must rely on TCP connections which implies >>> that each zone must have a network interface. A common TX configuration >>> is to use "all-zones" interfaces, so that labeled zones and the global >>> zone can share the same IP address. Labeled zone clients set their >>> DISPLAY environment to the hostname of the global zone to connect to >>> the X11 server. For example: >>> >>> DISPLAY=foobar:0 >>> >>> To avoid the requirement of configuring a network interface in each >>> zone, the loopback interface is now configured automatically as an >>> all-zones interface. Starting with Nevada build 82 and S10u6_03, it can >>> be used by labeled zone clients for TCP X11 connections. This allowed >>> settings like: >>> >>> DISPLAY=localhost:0 >>> or >>> DISPLAY=:0 >>> >>> to both work, as well. In the latter case, it worked because Xlib fell >>> back to try localhost after UNIX domain failed. >>> >>> However, starting in Nevada build 85, the X library has been changed to >>> use UNIX domain sockets if the DISPLAY variable matches the local >>> hostname (as it does with labeled zones). When a connection fails, >>> it retries up to 4 more times, sleeping between each try, before falling >>> back to another connection type (such as TCP). >>> >>> As a result, TX clients either fail to connect or take 15 seconds to >>> make the connection. The only workaround we have now is to explicitly >>> set the DISPLAY to localhost:0. >>> >>> Solution >>> >>> a) Allow labeled zones to access global zone X11 server via UNIX domain sockets >>> >>> If Trusted Extensions is enabled, the kernel will permit labeled zones >>> to connect to global zone clients if the global zone UNIX domain >>> rendezvous file is made available to the zone via a loopback mount. >>> >>> >>> b) The X11 server will use a new rendezvous directory when TX is enabled. >>> >>> Normally, the UNIX domain rendezvous files are in the directory /tmp/.X11-unix. >>> To allow the rendezvous files to be exported to labeled zones, the directory >>> pathname will be changed to: >>> >>> /var/tsol/door/.X11-unix. >>> >>> This directory pathname is chosen because /var/tsol/doors is already >>> loopback mounted into every labeled zone, to export the door rendezvous >>> files for nscd and the label daemon. To make this change transparent to >>> clients, a symbolic link to /tmp/.X11-unix will be created in each zone, >>> including the global zone. >>> >>> This solution will permit labeled zone X11 clients to use any of the >>> various DISPLAY environment variables they have been using previously, >>> and not require the use of TCP. >>> >>> >>> 6. Resources and Schedule >>> 6.4. Steering Committee requested information >>> 6.4.1. Consolidation C-team Name: >>> X >>> 6.5. ARC review type: FastTrack >>> 6.6. ARC Exposure: open >>> >>> From Glenn.Faden@sun.com Fri Aug 8 22:10:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7959xUR029532 for ; Fri, 8 Aug 2008 22:09:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7959uci015801 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 9 Aug 2008 06:09:58 +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 <0K5B00603ICLX900@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 08 Aug 2008 22:09:57 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5B00108ICLSY50@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 08 Aug 2008 22:09:57 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7959vG0011774 for ; Fri, 08 Aug 2008 22:09:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5B00K01IAY9A00@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 08 Aug 2008 22:09:56 -0700 (PDT) Received: from rampartgf.local ([69.144.34.25]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5B00DBNICJ8DC0@fe-sfbay-09.sun.com>; Fri, 08 Aug 2008 22:09:56 -0700 (PDT) Date: Fri, 08 Aug 2008 22:09:55 -0700 From: Glenn Faden Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <20080808224319.GF314160@eng.sun.com> Sender: Glenn.Faden@sun.com To: Edward Pilatowicz Cc: Alan Coopersmith , LSARC-ext@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <489D26A3.2070702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <20080808210912.GA283721@eng.sun.com> <489CC0AA.10904@sun.com> <20080808224319.GF314160@eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 355 Edward Pilatowicz wrote: > > i'm not asking about the X11 behavior wrt zones, i'm asking about the > cross-zone domain sockets behavior. > > has cross-zone UNIX domain traffic always been disallowed since zones > were introduced? if not, when was that restriction added? > The restriction was part of the initial zones project integration. --Glenn From gww@eng.sun.com Sat Aug 9 11:28:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m79ISfPs013655 for ; Sat, 9 Aug 2008 11:28:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m79ISdAd000633 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 9 Aug 2008 19:28:40 +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 <0K5C00907JBQRE00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Sat, 09 Aug 2008 12:28:38 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5C00COJJBQ6NB0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Sat, 09 Aug 2008 12:28:38 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m79ISb4S055999; Sat, 09 Aug 2008 11:28:37 -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 m79IPHoR005386; Sat, 09 Aug 2008 11:25:17 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m79IPHxn005385; Sat, 09 Aug 2008 11:25:17 -0700 (PDT) Date: Sat, 09 Aug 2008 11:25:17 -0700 (PDT) From: Gary Winiger Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com Cc: Alan.Coopersmith@sun.com, LSARC-ext@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <200808091825.m79IPHxn005385@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 889 > Edward Pilatowicz wrote: > > > > i'm not asking about the X11 behavior wrt zones, i'm asking about the > > cross-zone domain sockets behavior. > > > > has cross-zone UNIX domain traffic always been disallowed since zones > > were introduced? if not, when was that restriction added? > > > > The restriction was part of the initial zones project integration. Since other forms of IPC export from the global zone exists (viz. doors), what's the compelling reason to not allow IPC of Unix domain? That is why should this only be allowed for labeled systems? It seems to me there is little policy difference between a door rendezvous and a Unix domain socket rendezvous being exported from the GZ to another zone. Has anyone checked with the Zones and networking project teams? IMO, the restriction should just be removed (the less TX specific code the better ;-). Gary.. From ric.aleshire@sun.com Wed Aug 13 11:23:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7DINDiX011583 for ; Wed, 13 Aug 2008 11:23:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7DINDYZ012474 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 13 Aug 2008 19:23:13 +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 <0K5J00B07XQORW00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 13 Aug 2008 12:23:12 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5J002U3XQN7P70@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 13 Aug 2008 12:23:11 -0600 (MDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7DINAxI006889; Wed, 13 Aug 2008 11:23:10 -0700 (PDT) Received: from [127.0.0.1] (vpn-129-150-20-98.SFBay.Sun.COM [129.150.20.98]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m7DIN8V20988; Wed, 13 Aug 2008 11:23:08 -0700 (PDT) Date: Wed, 13 Aug 2008 11:23:08 -0700 From: Ric Aleshire Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808091825.m79IPHxn005385@marduk.eng.sun.com> To: Gary Winiger Cc: Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com, Alan.Coopersmith@sun.com, LSARC-ext@sun.com, Lokanath.Das@sun.com Message-id: <48A3268C.3070400@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Z8WYV3ROcXevitwMPxNDpw)" X-PMX-Version: 5.4.1.325704 X-Antivirus: avast! (VPS 080813-0, 08/13/2008), Outbound message X-Antivirus-Status: Clean References: <200808091825.m79IPHxn005385@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 3900 This is a multi-part message in MIME format. --Boundary_(ID_Z8WYV3ROcXevitwMPxNDpw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Gary Winiger wrote: >> Edward Pilatowicz wrote: >> >>> i'm not asking about the X11 behavior wrt zones, i'm asking about the >>> cross-zone domain sockets behavior. >>> >>> has cross-zone UNIX domain traffic always been disallowed since zones >>> were introduced? if not, when was that restriction added? >>> >>> >> The restriction was part of the initial zones project integration. >> > > Since other forms of IPC export from the global zone exists > (viz. doors), what's the compelling reason to not allow > IPC of Unix domain? That is why should this only be > allowed for labeled systems? > It seems to me there is little policy difference between > a door rendezvous and a Unix domain socket rendezvous > being exported from the GZ to another zone. > Has anyone checked with the Zones and networking project > teams? > IMO, the restriction should just be removed (the less TX specific > code the better ;-). > > Gary.. > I'm checking with the Zones group, but from my perspective I have no problem with making just the kernel socket change "global" and not dependent on TX. So the "a)" part would just read: The kernel will permit labeled zones to connect to global zone clients if the global zone UNIX domain rendezvous file is made available to the zone via a loopback mount. If anyone has any issue with this plan or believes more time is needed to run the case due to this modification, please reply. As mentioned, I'll check explicitly with zones-core. -Ric --Boundary_(ID_Z8WYV3ROcXevitwMPxNDpw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: 
Edward Pilatowicz wrote:
    
i'm not asking about the X11 behavior wrt zones, i'm asking about the
cross-zone domain sockets behavior.

has cross-zone UNIX domain traffic always been disallowed since zones
were introduced?  if not, when was that restriction added?
  
      
The restriction was part of the initial zones project integration.
    

	Since other forms of IPC export from the global zone exists
	(viz. doors), what's the compelling reason to not allow
	IPC of Unix domain?  That is why should this only be
	allowed for labeled systems?
	It seems to me there is little policy difference between
	a door rendezvous and a Unix domain socket rendezvous
	being exported from the GZ to another zone.
	Has anyone checked with the Zones and networking project
	teams?
	IMO, the restriction should just be removed (the less TX specific
	code the better ;-).

Gary..

I'm checking with the Zones group,  but from my perspective I have no problem with making just
the kernel socket change "global" and not dependent on TX.  So the "a)" part would just read:

    The kernel will permit labeled zones to connect to global zone clients if the global zone UNIX domain
    rendezvous file is made available to the zone via a loopback mount.

If anyone has any issue with this plan or believes more time is needed to run the case due to this
modification, please reply.  As mentioned, I'll check explicitly with zones-core.

-Ric
--Boundary_(ID_Z8WYV3ROcXevitwMPxNDpw)-- From gww@eng.sun.com Thu Aug 14 18:07:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F176F5018305 for ; Thu, 14 Aug 2008 18:07:06 -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 m7F1754x034926 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 14 Aug 2008 19:07:06 -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 <0K5M00C0FB3S4400@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 18:07:04 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M008P5B3RRT80@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 18:07:03 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7F172Io015022; Thu, 14 Aug 2008 18:07:02 -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 m7F13bwq011408; Thu, 14 Aug 2008 18:03:37 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7F13bQf011407; Thu, 14 Aug 2008 18:03:37 -0700 (PDT) Date: Thu, 14 Aug 2008 18:03:37 -0700 (PDT) From: Gary Winiger Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: gww@eng.sun.com, ric.aleshire@sun.com Cc: Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com, Alan.Coopersmith@sun.com, LSARC-ext@sun.com, Lokanath.Das@sun.com Message-id: <200808150103.m7F13bQf011407@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1866 > > Since other forms of IPC export from the global zone exists > > (viz. doors), what's the compelling reason to not allow > > IPC of Unix domain? That is why should this only be > > allowed for labeled systems? > > It seems to me there is little policy difference between > > a door rendezvous and a Unix domain socket rendezvous > > being exported from the GZ to another zone. > > Has anyone checked with the Zones and networking project > > teams? > > IMO, the restriction should just be removed (the less TX specific > > code the better ;-). > > > > Gary.. > > > > I'm checking with the Zones group, but from my perspective I have no > problem with making just > the kernel socket change "global" and not dependent on TX. So the "a)" > part would just read: > > The kernel will permit labeled zones to connect to global zone > clients if the global zone UNIX domain > rendezvous file is made available to the zone via a loopback mount. > > If anyone has any issue with this plan or believes more time is needed > to run the case due to this > modification, please reply. As mentioned, I'll check explicitly with > zones-core. Maybe I don't understand this reply. Let me try again. I don't see why there should be any check for Unix domain rendezvous. I don't see where rendezvous even between non-global zones is fundimentally different than IP network end points. In particular, if something in the GZ wanted to make itself available in local zones, it would be up to the GZ admin to correctly set up the visibility of the rendezvous files, just as is true for door rendezvous. Similarly for non-global zones to see into each other's file spaces that would have to be set up by the GZ admin. So, I'm missing why any checks are needed. What don't I understand about the zones policy and this proposal? Gary.. From ric.aleshire@sun.com Thu Aug 14 18:40:42 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F1egXU018852 for ; Thu, 14 Aug 2008 18:40:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7F1eebq026650 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 14 Aug 2008 18:40:42 -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 <0K5M00B0RCNSBP00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 19:40:40 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M009NRCNRFT60@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 19:40:39 -0600 (MDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7F1ebfk043095; Thu, 14 Aug 2008 18:40:37 -0700 (PDT) Received: from [127.0.0.1] (vpn-129-150-34-90.Central.Sun.COM [129.150.34.90]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m7F1eY801596; Thu, 14 Aug 2008 18:40:35 -0700 (PDT) Date: Thu, 14 Aug 2008 18:40:33 -0700 From: Ric Aleshire Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808150103.m7F13bQf011407@marduk.eng.sun.com> To: Gary Winiger Cc: Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com, Alan.Coopersmith@sun.com, LSARC-ext@sun.com, Lokanath.Das@sun.com Message-id: <48A4DE91.3010803@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_n7e0bYn3MAUZwGGOXbCxag)" X-PMX-Version: 5.4.1.325704 X-Antivirus: avast! (VPS 080814-0, 08/14/2008), Outbound message X-Antivirus-Status: Clean References: <200808150103.m7F13bQf011407@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 5415 This is a multi-part message in MIME format. --Boundary_(ID_n7e0bYn3MAUZwGGOXbCxag) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Gary Winiger wrote: >>> Since other forms of IPC export from the global zone exists >>> (viz. doors), what's the compelling reason to not allow >>> IPC of Unix domain? That is why should this only be >>> allowed for labeled systems? >>> It seems to me there is little policy difference between >>> a door rendezvous and a Unix domain socket rendezvous >>> being exported from the GZ to another zone. >>> Has anyone checked with the Zones and networking project >>> teams? >>> IMO, the restriction should just be removed (the less TX specific >>> code the better ;-). >>> >>> Gary.. >>> >>> >> I'm checking with the Zones group, but from my perspective I have no >> problem with making just >> the kernel socket change "global" and not dependent on TX. So the "a)" >> part would just read: >> >> The kernel will permit labeled zones to connect to global zone >> clients if the global zone UNIX domain >> rendezvous file is made available to the zone via a loopback mount. >> >> If anyone has any issue with this plan or believes more time is needed >> to run the case due to this >> modification, please reply. As mentioned, I'll check explicitly with >> zones-core. >> > > Maybe I don't understand this reply. Let me try again. I don't > see why there should be any check for Unix domain rendezvous. > I don't see where rendezvous even between non-global zones > is fundimentally different than IP network end points. > In particular, if something in the GZ wanted to make itself > available in local zones, it would be up to the GZ admin > to correctly set up the visibility of the rendezvous files, > just as is true for door rendezvous. Similarly for non-global > zones to see into each other's file spaces that would have to > be set up by the GZ admin. So, I'm missing why any checks > are needed. > What don't I understand about the zones policy and this proposal? > > Gary.. > You're saying that for Trusted Extensions or not, you suggest allowing all cross-zone Unix domain sockets, not just those exported from GZ? In TX at least, I don't know of any good usage case for this, and would potentially allow GZ admin to violate MAC, without any kernel policy here. In exporting from GZ, data by definition is admin_low thus properly accessible by any zone. -Ric --Boundary_(ID_n7e0bYn3MAUZwGGOXbCxag) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: 
	Since other forms of IPC export from the global zone exists
	(viz. doors), what's the compelling reason to not allow
	IPC of Unix domain?  That is why should this only be
	allowed for labeled systems?
	It seems to me there is little policy difference between
	a door rendezvous and a Unix domain socket rendezvous
	being exported from the GZ to another zone.
	Has anyone checked with the Zones and networking project
	teams?
	IMO, the restriction should just be removed (the less TX specific
	code the better ;-).

Gary..
  
      
I'm checking with the Zones group,  but from my perspective I have no 
problem with making just
the kernel socket change "global" and not dependent on TX.  So the "a)" 
part would just read:

    The kernel will permit labeled zones to connect to global zone 
clients if the global zone UNIX domain
    rendezvous file is made available to the zone via a loopback mount.

If anyone has any issue with this plan or believes more time is needed 
to run the case due to this
modification, please reply.  As mentioned, I'll check explicitly with 
zones-core.
    

	Maybe I don't understand this reply.  Let me try again.  I don't
	see why there should be any check for Unix domain rendezvous.
	I don't see where rendezvous even between non-global zones
	is fundimentally different than IP network end points.
	In particular, if something in the GZ wanted to make itself
	available in local zones, it would be up to the GZ admin
	to correctly set up the visibility of the rendezvous files,
	just as is true for door rendezvous.  Similarly for non-global
	zones to see into each other's file spaces that would have to
	be set up by the GZ admin.  So, I'm missing why any checks
	are needed.
	What don't I understand about the zones policy and this proposal?

Gary..

You're saying that for Trusted Extensions or not, you suggest allowing all cross-zone Unix domain
sockets, not just those exported from GZ?  In TX at least, I don't know of any good usage case
for this, and would potentially allow GZ admin to violate MAC, without any kernel policy here.
In exporting from GZ, data by definition is admin_low thus properly accessible by any zone.

-Ric




--Boundary_(ID_n7e0bYn3MAUZwGGOXbCxag)-- From lokanath.das@sun.com Thu Aug 14 20:29:01 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F3T1BQ020015 for ; Thu, 14 Aug 2008 20:29:01 -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 m7F3T03X004805 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 14 Aug 2008 20:29:01 -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 <0K5M00J07HOCN100@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 21:29:00 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M00DH8HOBFR60@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 21:29:00 -0600 (MDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7F3Sw25023098; Thu, 14 Aug 2008 20:28:58 -0700 (PDT) Received: from [129.150.13.74] (vpn-129-150-13-74.SFBay.Sun.COM [129.150.13.74]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m7F3Sv801992; Thu, 14 Aug 2008 20:28:57 -0700 (PDT) Date: Thu, 14 Aug 2008 20:29:10 -0700 From: Lokanath Das Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808150103.m7F13bQf011407@marduk.eng.sun.com> To: Gary Winiger Cc: ric.aleshire@sun.com, Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com, Alan.Coopersmith@sun.com, LSARC-ext@sun.com Message-id: <48A4F806.9090300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808150103.m7F13bQf011407@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 3097 Gary Winiger wrote: >>> Since other forms of IPC export from the global zone exists >>> (viz. doors), what's the compelling reason to not allow >>> IPC of Unix domain? That is why should this only be >>> allowed for labeled systems? >>> It seems to me there is little policy difference between >>> a door rendezvous and a Unix domain socket rendezvous >>> being exported from the GZ to another zone. >>> Has anyone checked with the Zones and networking project >>> teams? >>> IMO, the restriction should just be removed (the less TX specific >>> code the better ;-). >>> >>> Gary.. >>> >> I'm checking with the Zones group, but from my perspective I have no >> problem with making just >> the kernel socket change "global" and not dependent on TX. So the "a)" >> part would just read: >> >> The kernel will permit labeled zones to connect to global zone >> clients if the global zone UNIX domain >> rendezvous file is made available to the zone via a loopback mount. >> >> If anyone has any issue with this plan or believes more time is needed >> to run the case due to this >> modification, please reply. As mentioned, I'll check explicitly with >> zones-core. > > Maybe I don't understand this reply. Let me try again. I don't > see why there should be any check for Unix domain rendezvous. > I don't see where rendezvous even between non-global zones > is fundimentally different than IP network end points. > In particular, if something in the GZ wanted to make itself > available in local zones, it would be up to the GZ admin > to correctly set up the visibility of the rendezvous files, > just as is true for door rendezvous. Similarly for non-global > zones to see into each other's file spaces that would have to > be set up by the GZ admin. So, I'm missing why any checks > are needed. > What don't I understand about the zones policy and this proposal? > > Gary.. Gary, your understanding is correct. For two processes to communicate using unix domain sockets, they need to be using the same rendezvous. Under the current proposal, the server that creates the socket resides in the global zone. A non-global zone client can communicate with this server using the unix domain socket only if it uses the same rendezvous. What Ric was saying was that rendezvous need to be loop-back mounted in the non-global zone from the global zone. How it gets mounted will depend on the subsystem that uses this feature. This mounting obviously will have to be done either by an admin (manually) or automatically (by smf or some other means). I don't think Ric is adding any new code to check if the rendezvous is loop-back mounted (because the check is already there i.e the communicating processes have to use the *same* rendezvous). For example, in case of Trusted Extensions X, the X server creates the rendezvous in a location that is loopback mounted via an smf service. The X clients use this new rendezvous to communicate with the X server. Please note that this case doesn't allow communication between two non-global zones. -Lokanath From gww@eng.sun.com Thu Aug 14 22:42:28 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F5gSHt023266 for ; Thu, 14 Aug 2008 22:42:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7F5gQB8012816 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 14 Aug 2008 22:42:28 -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 <0K5M0060DNURSO00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 23:42:27 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M004ABNUQWG30@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 23:42:27 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7F5gP4W060164; Thu, 14 Aug 2008 22:42: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 m7F5cw48011700; Thu, 14 Aug 2008 22:38:58 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7F5cwpq011699; Thu, 14 Aug 2008 22:38:58 -0700 (PDT) Date: Thu, 14 Aug 2008 22:38:58 -0700 (PDT) From: Gary Winiger Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: gww@eng.sun.com, lokanath.das@sun.com Cc: ric.aleshire@sun.com, Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com, Alan.Coopersmith@sun.com, LSARC-ext@sun.com Message-id: <200808150538.m7F5cwpq011699@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2879 > > Maybe I don't understand this reply. Let me try again. I don't > > see why there should be any check for Unix domain rendezvous. > > I don't see where rendezvous even between non-global zones > > is fundimentally different than IP network end points. > > In particular, if something in the GZ wanted to make itself > > available in local zones, it would be up to the GZ admin > > to correctly set up the visibility of the rendezvous files, > > just as is true for door rendezvous. Similarly for non-global > > zones to see into each other's file spaces that would have to > > be set up by the GZ admin. So, I'm missing why any checks > > are needed. > > What don't I understand about the zones policy and this proposal? > > > > Gary.. > > Gary, your understanding is correct. This and > Please note that this case doesn't allow communication between > two non-global zones. the final statement don't seem to match what I'm asking. Let me try again. Simply why, if the rendezvous is visable, i.e., can be opened/is visible in ANY zone, can't the peer communicate with the creator of the rendezvous? Networking folk, please excuse me if I don't have the terminology right. I'm not talking about how a labeled system differs from an unlabeled system. I'm asking about all configurations of OpenSolaris and S10. If an admin creates a way that zones can share a rendezvous file, why should there be any further restriction? Project team, have the zones and networking teams been asked about this? I don't recall seeing an explicit response. Perhaps, a final spec is needed after the case converges to make this part of the case clear. Gary.. ====== > For two processes to communicate using unix domain sockets, they > need to be using the same rendezvous. Under the current proposal, > the server that creates the socket resides in the global zone. > A non-global zone client can communicate with this server using > the unix domain socket only if it uses the same rendezvous. > > What Ric was saying was that rendezvous need to be loop-back mounted > in the non-global zone from the global zone. How it gets mounted will > depend on the subsystem that uses this feature. This mounting obviously > will have to be done either by an admin (manually) or automatically > (by smf or some other means). > > I don't think Ric is adding any new code to check if the rendezvous > is loop-back mounted (because the check is already there i.e > the communicating processes have to use the *same* rendezvous). > > For example, in case of Trusted Extensions X, the X server creates > the rendezvous in a location that is loopback mounted via an smf > service. The X clients use this new rendezvous to communicate with > the X server. > > Please note that this case doesn't allow communication between > two non-global zones. > > -Lokanath > From gww@eng.sun.com Thu Aug 14 22:58:19 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F5wJhE024070 for ; Thu, 14 Aug 2008 22:58:19 -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 m7F5wHZm028053 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 14 Aug 2008 22:58:18 -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 <0K5M0071FOL6YU00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 23:58:18 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M0046COL5WG50@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 14 Aug 2008 23:58:17 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7F5wG4m065500; Thu, 14 Aug 2008 22:58:16 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m7F5smag011741; Thu, 14 Aug 2008 22:54:48 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7F5smeQ011740; Thu, 14 Aug 2008 22:54:48 -0700 (PDT) Date: Thu, 14 Aug 2008 22:54:48 -0700 (PDT) From: Gary Winiger Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: gww@eng.sun.com, ric.aleshire@sun.com Cc: Alan.Coopersmith@sun.com, Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com, LSARC-ext@sun.com, Lokanath.Das@sun.com Message-id: <200808150554.m7F5smeQ011740@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1755 > > Maybe I don't understand this reply. Let me try again. I don't > > see why there should be any check for Unix domain rendezvous. > > I don't see where rendezvous even between non-global zones > > is fundimentally different than IP network end points. > > In particular, if something in the GZ wanted to make itself > > available in local zones, it would be up to the GZ admin > > to correctly set up the visibility of the rendezvous files, > > just as is true for door rendezvous. Similarly for non-global > > zones to see into each other's file spaces that would have to > > be set up by the GZ admin. So, I'm missing why any checks > > are needed. > > What don't I understand about the zones policy and this proposal? > > > > Gary.. > > > > You're saying that for Trusted Extensions or not, you suggest allowing > all cross-zone Unix domain > sockets, not just those exported from GZ? Yes, if the rendezvous is visible, why can't it communicate? What did the zones and networking teams have to say? > In TX at least, I don't know > of any good usage case > for this, and would potentially allow GZ admin to violate MAC, without > any kernel policy here. For sure, the TX admin wouldn't normally configure a system to create a MAC voilation. But of course, they could if configured things that way, (presuming I understand correctly) just like net_mac_aware would do for IP sockets. Gary.. > In exporting from GZ, data by definition is admin_low thus properly > accessible by any zone. One can quibble about that. If X11 is communicating with all labels, it's proper label would be admin_high and it would be trusted to not violate MAC. VIZ, net_reply_equal from ealier versions of Solaris with labels. From Darren.Moffat@sun.com Fri Aug 15 02:23:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F9N0RK029847 for ; Fri, 15 Aug 2008 02:23:01 -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 m7F9MwAd008398 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 15 Aug 2008 17:22:59 +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 <0K5M00003Y2AEL00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 02:22:58 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M00LLJY293N30@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 02:22:58 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7F9Mvfu005634 for ; Fri, 15 Aug 2008 09:22:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5M00101XTW2S00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 10:22:57 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5M006PPY23OQ40@fe-emea-10.sun.com>; Fri, 15 Aug 2008 10:22:53 +0100 (BST) Date: Fri, 15 Aug 2008 10:22:51 +0100 From: Darren J Moffat Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808150103.m7F13bQf011407@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Ric.Aleshire@sun.com, Lokanath.Das@sun.com, Alan.Coopersmith@sun.com, Glenn.Faden@sun.com, LSARC-ext@sun.com, Edward.Pilatowicz@sun.com Message-id: <48A54AEB.6010804@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808150103.m7F13bQf011407@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 1156 Gary Winiger wrote: > Maybe I don't understand this reply. Let me try again. I don't > see why there should be any check for Unix domain rendezvous. > I don't see where rendezvous even between non-global zones > is fundimentally different than IP network end points. > In particular, if something in the GZ wanted to make itself > available in local zones, it would be up to the GZ admin > to correctly set up the visibility of the rendezvous files, > just as is true for door rendezvous. Similarly for non-global > zones to see into each other's file spaces that would have to > be set up by the GZ admin. So, I'm missing why any checks > are needed. I spoke with a customer recently that has a need for exactly this type of cross zone communication. They need it in both the TX and non-TX cases. In their case they want the GZ to be required to setup the channels but also want two local zones to be able to communicate without requiring IP networking (longer term Crossbow may help them and they could use IP networking but for now they can't). This customer would also like to do the same thing with doors. -- Darren J Moffat From gww@eng.sun.com Fri Aug 15 07:28:33 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FESXd8005487 for ; Fri, 15 Aug 2008 07:28:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7FESXfX023564 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 15 Aug 2008 08:28:33 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5N00003C7KMJ00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 08:28:32 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00L6CC7J3M20@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 08:28:31 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7FESTi7025583; Fri, 15 Aug 2008 07:28:29 -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 m7FEP2ma012019; Fri, 15 Aug 2008 07:25:02 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7FEP24U012018; Fri, 15 Aug 2008 07:25:02 -0700 (PDT) Date: Fri, 15 Aug 2008 07:25:02 -0700 (PDT) From: Gary Winiger Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: Ric.Aleshire@sun.com, Lokanath.Das@sun.com, Alan.Coopersmith@sun.com, Glenn.Faden@sun.com, LSARC-ext@sun.com, Edward.Pilatowicz@sun.com Message-id: <200808151425.m7FEP24U012018@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 658 > I spoke with a customer recently that has a need for exactly this type > of cross zone communication. They need it in both the TX and non-TX > cases. In their case they want the GZ to be required to setup the > channels but also want two local zones to be able to communicate without > requiring IP networking (longer term Crossbow may help them and they > could use IP networking but for now they can't). > > This customer would also like to do the same thing with doors. Maybe naively, I thought they already could with doors. I thought if you could see the door file, you could place a door_call to the server that created the file. Gary.. From Darren.Moffat@sun.com Fri Aug 15 07:46:26 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FEkPGG005711 for ; Fri, 15 Aug 2008 07:46:25 -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 m7FEkPYK029584 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 15 Aug 2008 08:46:25 -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 <0K5N0010FD1BXA00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 08:46:23 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00L57D193O30@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 08:46:22 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7FEkLMT007103 for ; Fri, 15 Aug 2008 14:46:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5N00701CXPKE00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 15:46:21 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5N005C7D17TH30@fe-emea-09.sun.com>; Fri, 15 Aug 2008 15:46:21 +0100 (BST) Date: Fri, 15 Aug 2008 15:46:19 +0100 From: Darren J Moffat Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808151425.m7FEP24U012018@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Ric.Aleshire@sun.com, Lokanath.Das@sun.com, Alan.Coopersmith@sun.com, Glenn.Faden@sun.com, LSARC-ext@sun.com, Edward.Pilatowicz@sun.com Message-id: <48A596BB.8040803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808151425.m7FEP24U012018@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 789 Gary Winiger wrote: >> I spoke with a customer recently that has a need for exactly this type >> of cross zone communication. They need it in both the TX and non-TX >> cases. In their case they want the GZ to be required to setup the >> channels but also want two local zones to be able to communicate without >> requiring IP networking (longer term Crossbow may help them and they >> could use IP networking but for now they can't). >> >> This customer would also like to do the same thing with doors. > > Maybe naively, I thought they already could with doors. > I thought if you could see the door file, you could place > a door_call to the server that created the file. I believe you can but they do need UNIX domain sockets too for some of the apps. -- Darren J Moffat From gww@eng.sun.com Fri Aug 15 07:56:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FEuiea006070 for ; Fri, 15 Aug 2008 07:56:44 -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 m7FEub9R028774 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 15 Aug 2008 22:56:43 +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 <0K5N00I0LDIIYS00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 07:56:42 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N005Y1DIIEND0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 07:56:42 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7FEuebv040768; Fri, 15 Aug 2008 07:56: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 m7FErDcw012084; Fri, 15 Aug 2008 07:53:13 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7FErDO8012083; Fri, 15 Aug 2008 07:53:13 -0700 (PDT) Date: Fri, 15 Aug 2008 07:53:13 -0700 (PDT) From: Gary Winiger Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: Ric.Aleshire@sun.com, Lokanath.Das@sun.com, Alan.Coopersmith@sun.com, Glenn.Faden@sun.com, LSARC-ext@sun.com, Edward.Pilatowicz@sun.com Message-id: <200808151453.m7FErDO8012083@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 515 >> >> This customer would also like to do the same thing with doors. > > > > Maybe naively, I thought they already could with doors. > > I thought if you could see the door file, you could place > > a door_call to the server that created the file. > > I believe you can but they do need UNIX domain sockets too for some of > the apps. Indeed and my comments are that I seen no architectural or security difference between Unix domain and door rendezvious, so why is Unix domain being restricted? Gary.. From Darren.Moffat@sun.com Fri Aug 15 07:58:36 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FEwa6S006089 for ; Fri, 15 Aug 2008 07:58:36 -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 m7FEwXal021052 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 15 Aug 2008 07:58:36 -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 <0K5N00J15DLN1600@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 07:58:35 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N0052RDLMENE0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 07:58:35 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7FEwYA0008295 for ; Fri, 15 Aug 2008 14:58:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5N00F01DHSCU00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 15:58:34 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5N006GWDLHOQE0@fe-emea-10.sun.com>; Fri, 15 Aug 2008 15:58:30 +0100 (BST) Date: Fri, 15 Aug 2008 15:58:29 +0100 From: Darren J Moffat Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808151453.m7FErDO8012083@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Ric.Aleshire@sun.com, Lokanath.Das@sun.com, Alan.Coopersmith@sun.com, Glenn.Faden@sun.com, LSARC-ext@sun.com, Edward.Pilatowicz@sun.com Message-id: <48A59995.7080905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808151453.m7FErDO8012083@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 765 Gary Winiger wrote: >>>>> This customer would also like to do the same thing with doors. >>> Maybe naively, I thought they already could with doors. >>> I thought if you could see the door file, you could place >>> a door_call to the server that created the file. >> I believe you can but they do need UNIX domain sockets too for some of >> the apps. > > Indeed and my comments are that I seen no architectural or > security difference between Unix domain and door rendezvious, > so why is Unix domain being restricted? I agree with you here Gary I think the fact that the GZ admin has to set these up is sufficient protection. If more than that is needed maybe it should be a per local zone setting, with the default allowing it. -- Darren J Moffat From johnz@domus.sfbay.sun.com Fri Aug 15 10:59:40 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FHxepE013666 for ; Fri, 15 Aug 2008 10:59:40 -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 m7FHxcL4030140 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 15 Aug 2008 11:59:40 -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 <0K5N00301LZE5Z00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 10:59:38 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00JPGLZEP3E0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 10:59:38 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7FHxapv028988; Fri, 15 Aug 2008 10:59:36 -0700 (PDT) Received: (from johnz@localhost) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) id m7FHxZE05765; Fri, 15 Aug 2008 10:59:35 -0700 (PDT) Date: Fri, 15 Aug 2008 10:59:35 -0700 (PDT) From: John Zolnowsky x69422/408-404-5064 Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: Ric.Aleshire@sun.com, Lokanath.Das@sun.com, Alan.Coopersmith@sun.com, Glenn.Faden@sun.com, LSARC-ext@sun.com, Edward.Pilatowicz@sun.com Message-id: <200808151759.m7FHxZE05765@domus.sfbay.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1007 > Date: Fri, 15 Aug 2008 07:53:13 -0700 (PDT) > From: Gary Winiger > >> >> This customer would also like to do the same thing with doors. > > > > > > Maybe naively, I thought they already could with doors. > > > I thought if you could see the door file, you could place > > > a door_call to the server that created the file. > > > > I believe you can but they do need UNIX domain sockets too for some of > > the apps. > > Indeed and my comments are that I seen no architectural or > security difference between Unix domain and door rendezvious, > so why is Unix domain being restricted? The door mechanism has a similar restriction for TX as is being proposed for Unix domain. From usr/src/uts/common/fs/doorfs/door_vnops.c:door_open(): * MAC policy for doors. Restrict cross-zone open()s so that only * door servers in the global zone can have clients from other zones. * For other zones, client must be within the same zone as server. -JZ From ric.aleshire@sun.com Fri Aug 15 11:44:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FIiJ3n019654 for ; Fri, 15 Aug 2008 11:44:20 -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 m7FIiIUi014485 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 16 Aug 2008 02:44:18 +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 <0K5N00G03O1TGF00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 11:44:17 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00686O1TUW60@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 15 Aug 2008 11:44:17 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7FIiGg7057827; Fri, 15 Aug 2008 11:44:16 -0700 (PDT) Received: from [127.0.0.1] (vpn-129-150-18-120.SFBay.Sun.COM [129.150.18.120]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m7FIi8806172; Fri, 15 Aug 2008 11:44:08 -0700 (PDT) Date: Fri, 15 Aug 2008 11:44:07 -0700 From: Ric Aleshire Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808150538.m7F5cwpq011699@marduk.eng.sun.com> To: Gary Winiger Cc: lokanath.das@sun.com, Edward.Pilatowicz@sun.com, Glenn.Faden@sun.com, Alan.Coopersmith@sun.com, LSARC-ext@sun.com Message-id: <48A5CE77.50303@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zhdfjIIxkFe3b1spirdx/Q)" X-PMX-Version: 5.4.1.325704 X-Antivirus: avast! (VPS 080815-0, 08/15/2008), Outbound message X-Antivirus-Status: Clean References: <200808150538.m7F5cwpq011699@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 8676 This is a multi-part message in MIME format. --Boundary_(ID_zhdfjIIxkFe3b1spirdx/Q) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Gary Winiger wrote: >>> Maybe I don't understand this reply. Let me try again. I don't >>> see why there should be any check for Unix domain rendezvous. >>> I don't see where rendezvous even between non-global zones >>> is fundimentally different than IP network end points. >>> In particular, if something in the GZ wanted to make itself >>> available in local zones, it would be up to the GZ admin >>> to correctly set up the visibility of the rendezvous files, >>> just as is true for door rendezvous. Similarly for non-global >>> zones to see into each other's file spaces that would have to >>> be set up by the GZ admin. So, I'm missing why any checks >>> are needed. >>> What don't I understand about the zones policy and this proposal? >>> >>> Gary.. >>> >> Gary, your understanding is correct. >> > > This and > > >> Please note that this case doesn't allow communication between >> two non-global zones. >> > > the final statement don't seem to match what I'm asking. > Let me try again. Simply why, if the rendezvous is visable, > i.e., can be opened/is visible in ANY zone, can't the peer > communicate with the creator of the rendezvous? > Networking folk, please excuse me if I don't have the terminology > right. > I'm not talking about how a labeled system differs from an > unlabeled system. I'm asking about all configurations of > OpenSolaris and S10. > If an admin creates a way that zones can share a rendezvous > file, why should there be any further restriction? > To me it seems similar to lofs policy that TX has. That could also have been left unobstructed and at the discretion of which mounts the admins choose. Since we have policy there, it seems consistent for sockets to also have policy. > Project team, have the zones and networking teams been asked > about this? I don't recall seeing an explicit response. > I haven't had any repsonses to my queries... > Perhaps, a final spec is needed after the case converges > to make this part of the case clear. > I agree. Despite the date, this is de facto pending due to Alan's vacation. I think we should assume the case is still running until this part is resolved, which will likely run into next week when Alan and Glenn return. I believe we've narrowed it down to a just a question of TX behavior - whether any policy enforcement is needed there. The direction for non-TX is to remove cross-zone limitations. -Ric > Gary.. > ====== > >> For two processes to communicate using unix domain sockets, they >> need to be using the same rendezvous. Under the current proposal, >> the server that creates the socket resides in the global zone. >> A non-global zone client can communicate with this server using >> the unix domain socket only if it uses the same rendezvous. >> >> What Ric was saying was that rendezvous need to be loop-back mounted >> in the non-global zone from the global zone. How it gets mounted will >> depend on the subsystem that uses this feature. This mounting obviously >> will have to be done either by an admin (manually) or automatically >> (by smf or some other means). >> >> I don't think Ric is adding any new code to check if the rendezvous >> is loop-back mounted (because the check is already there i.e >> the communicating processes have to use the *same* rendezvous). >> >> For example, in case of Trusted Extensions X, the X server creates >> the rendezvous in a location that is loopback mounted via an smf >> service. The X clients use this new rendezvous to communicate with >> the X server. >> >> Please note that this case doesn't allow communication between >> two non-global zones. >> >> -Lokanath >> >> --Boundary_(ID_zhdfjIIxkFe3b1spirdx/Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: 
	Maybe I don't understand this reply.  Let me try again.  I don't
	see why there should be any check for Unix domain rendezvous.
	I don't see where rendezvous even between non-global zones
	is fundimentally different than IP network end points.
	In particular, if something in the GZ wanted to make itself
	available in local zones, it would be up to the GZ admin
	to correctly set up the visibility of the rendezvous files,
	just as is true for door rendezvous.  Similarly for non-global
	zones to see into each other's file spaces that would have to
	be set up by the GZ admin.  So, I'm missing why any checks
	are needed.
	What don't I understand about the zones policy and this proposal?

Gary..
      
Gary, your understanding is correct.
    

	This and

  
Please note that this case doesn't allow communication between
two non-global zones.
    

	the final statement don't seem to match what I'm asking.
	Let me try again.  Simply why, if the rendezvous is visable,
	i.e., can be opened/is visible in ANY zone, can't the peer
	communicate with the creator of the rendezvous?
	Networking folk, please excuse me if I don't have the terminology
	right.
	I'm not talking about how a labeled system differs from an
	unlabeled system.  I'm asking about all configurations of
	OpenSolaris and S10. 
	If an admin creates a way that zones can share a rendezvous
	file, why should there be any further restriction?

To me it seems similar to lofs policy that TX has.  That could also have been left unobstructed
and at the discretion of which mounts the admins choose.  Since we have policy there, it seems
consistent for sockets to also have policy.

	Project team, have the zones and networking teams been asked
	about this?  I don't recall seeing an explicit response.

I haven't had any repsonses to my queries...

	Perhaps, a final spec is needed after the case converges
	to make this part of the case clear.

I agree.  Despite the date, this is de facto pending due to Alan's vacation.  I think we should
assume the case is still running until this part is resolved, which will likely run into next week
when Alan and Glenn return.  I believe we've narrowed it down to a just a question of TX
behavior - whether any policy enforcement is needed there.  The direction for non-TX is
to remove cross-zone limitations.

-Ric


Gary..
======
  
For two processes to communicate using unix domain sockets, they
need to be using the same rendezvous. Under the current proposal,
the server that creates the socket resides in the global zone.
A non-global zone client can communicate with this server using
the unix domain socket only if it uses the same rendezvous.

What Ric was saying was that rendezvous need to be loop-back mounted
in the non-global zone from the global zone. How it gets mounted will 
depend on the subsystem that uses this feature. This mounting obviously
will have to be done either by an admin (manually) or automatically
(by smf or some other means).

I don't think Ric is adding any new code to check if the rendezvous
is loop-back mounted (because the check is already there i.e
the communicating processes have to use the *same* rendezvous).

For example, in case of Trusted Extensions X, the X server creates
the rendezvous in a location that is loopback mounted via an smf
service. The X clients use this new rendezvous to communicate with
the X server.

Please note that this case doesn't allow communication between
two non-global zones.

-Lokanath

--Boundary_(ID_zhdfjIIxkFe3b1spirdx/Q)-- From Alan.Coopersmith@sun.com Tue Aug 19 15:47:01 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7JMl06K002989 for ; Tue, 19 Aug 2008 15:47:00 -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 m7JMkpNt020326 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 19 Aug 2008 16:47:00 -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 <0K5V00F05DYB0H00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 19 Aug 2008 15:46:59 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5V00AYHDYBG460@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 19 Aug 2008 15:46:59 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7JMkx6H025257 for ; Tue, 19 Aug 2008 15:46:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5V00G01DTAID00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 19 Aug 2008 15:46:59 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5V00MSTDXTT440@fe-sfbay-10.sun.com>; Tue, 19 Aug 2008 15:46:42 -0700 (PDT) Date: Tue, 19 Aug 2008 15:46:41 -0700 From: Alan Coopersmith Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> Sender: Alan.Coopersmith@sun.com To: LSARC-ext@sun.com Cc: Glenn.Faden@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <48AB4D51.4050401@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 543 Alan Coopersmith wrote: > I am sponsoring this fasttrack for Ric Aleshire & Lokanath Das of the > Trusted Extensions team, and have set the timeout for one week from today, > Thursday, August 14. As this case has not yet reached a consensus and we are waiting for a decision on the handling of cross-zone Unix domain sockets, I have set the status to "waiting need spec" and will restart the timer once we have that decision. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From alan.coopersmith@sun.com Wed Aug 20 17:55:04 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7L0t3CE019057 for ; Wed, 20 Aug 2008 17:55:04 -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 m7L0t34I036525 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 20 Aug 2008 18:55:03 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5X00107EJQ7J00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 20 Aug 2008 17:55:02 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5X00LHAEJPNZB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 20 Aug 2008 17:55:01 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7L0t1Dk013426 for ; Wed, 20 Aug 2008 17:55:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5X00E01EAWLJ00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 20 Aug 2008 17:55:01 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5X008PPEJM4BB0@fe-sfbay-10.sun.com>; Wed, 20 Aug 2008 17:54:58 -0700 (PDT) Date: Wed, 20 Aug 2008 17:54:58 -0700 From: Alan Coopersmith Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <48AB4D51.4050401@sun.com> Sender: alan.coopersmith@sun.com To: LSARC-ext@sun.com Cc: Craig Payne , Glenn.Faden@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <48ACBCE2.3030101@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <48AB4D51.4050401@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 4802 Alan Coopersmith wrote: > Alan Coopersmith wrote: >> I am sponsoring this fasttrack for Ric Aleshire & Lokanath Das of the >> Trusted Extensions team, and have set the timeout for one week from today, >> Thursday, August 14. > > As this case has not yet reached a consensus and we are waiting for a > decision on the handling of cross-zone Unix domain sockets, I have set > the status to "waiting need spec" and will restart the timer once we > have that decision. The various parties have come to consensus off-line and a new spec is put forth, so I am restarting the timer, and will let it run until the end of the day Friday, August 22, unless someone would like to request more time. The revised spec is provided in the case directory in the file named "spec". A version with changebars follows - the change to previous is that Unix domain sockets will be able to communicate across all types of zones whenever their endpoints are made available in both zones, except as restricted by TX labeled data policies. This project continues to only make the Unix domain sockets for X11 communications automatically available in TX labeled zones. For all other types of zones, either the system admin or later projects from the teams responsible for those zone types will have to make the sockets available if cross-zone X11 communication is desired across them. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering ------------------------------------------------------------------------------- This fast-track makes changes related to Trusted Extensions in the handling and use of Unix Domain sockets for X11 clients. A micro/patch release binding is requested. Problem The X11 server supports several transports: UNIX domain sockets, pipes, or TCP networking. In Trusted Extensions, X11 clients run in labeled zone and cannot use UNIX domain sockets to reach the X11 server in the global zone. Therefore they must rely on TCP connections which implies that each zone must have a network interface. A common TX configuration is to use "all-zones" interfaces, so that labeled zones and the global zone can share the same IP address. Labeled zone clients set their DISPLAY environment to the hostname of the global zone to connect to the X11 server. For example: DISPLAY=foobar:0 To avoid the requirement of configuring a network interface in each zone, the loopback interface is now configured automatically as an all-zones interface. Starting with Nevada build 82 and S10u6_03, it can be used by labeled zone clients for TCP X11 connections. This allowed settings like: DISPLAY=localhost:0 or DISPLAY=:0 to both work, as well. In the latter case, it worked because Xlib fell back to try localhost after UNIX domain failed. However, starting in Nevada build 85, the X library has been changed to use UNIX domain sockets if the DISPLAY variable matches the local hostname (as it does with labeled zones). When a connection fails, it retries up to 4 more times, sleeping between each try, before falling back to another connection type (such as TCP). As a result, TX clients either fail to connect or take 15 seconds to make the connection. The only workaround we have now is to explicitly set the DISPLAY to localhost:0. Solution | a) Fix bug preventing cross-zone usage of UNIX domain sockets | | The original zones case specified that there should be no restrictions | on UNIX domain socket communication between zones if the endpoints | were made available in both zones. [1] This was broken in the | implementation after the initial integration and will be fixed for all | types of zones by this project. | | However, a restriction will be added for TX that prevents labeled | non-global zones from communicating with each other via UNIX domain | sockets, as is already done for doors. | | [1] Chapter 13 of PSARC 2002/174 Design Spec: | http://opensolaris.org/os/community/arc/caselog/2002/174/zones-design.spec.opensolaris.pdf b) The X11 server will use a new rendezvous directory when TX is enabled. Normally, the UNIX domain rendezvous files are in the directory /tmp/.X11-unix. To allow the rendezvous files to be exported to labeled zones, the directory pathname will be changed to: /var/tsol/door/.X11-unix. This directory pathname is chosen because /var/tsol/doors is already loopback mounted into every labeled zone, to export the door rendezvous files for nscd and the label daemon. To make this change transparent to clients, a symbolic link to /tmp/.X11-unix will be created in each zone, including the global zone. This solution will permit labeled zone X11 clients to use any of the various DISPLAY environment variables they have been using previously, and not require the use of TCP. From Alan.Coopersmith@sun.com Wed Aug 20 18:17:01 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7L1H1CF020065 for ; Wed, 20 Aug 2008 18:17:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7L1H0rO029832 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 20 Aug 2008 18:17:01 -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 <0K5X00K0FFKCQ400@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 20 Aug 2008 19:17:00 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5X005A1FKBIKC0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 20 Aug 2008 19:17:00 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7L1GxSE014663 for ; Wed, 20 Aug 2008 18:16:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5X00B01FIDI200@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 20 Aug 2008 18:16:59 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5X00AS3FKB0K00@fe-sfbay-10.sun.com>; Wed, 20 Aug 2008 18:16:59 -0700 (PDT) Date: Wed, 20 Aug 2008 18:16:58 -0700 From: Alan Coopersmith Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <48ACBCE2.3030101@sun.com> Sender: Alan.Coopersmith@sun.com To: LSARC-ext@sun.com Cc: Glenn.Faden@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <48ACC20A.1080408@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <48AB4D51.4050401@sun.com> <48ACBCE2.3030101@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1390 Alan Coopersmith wrote: > This project continues to only make the Unix domain sockets for X11 > communications automatically available in TX labeled zones. For all > other types of zones, either the system admin or later projects from > the teams responsible for those zone types will have to make the sockets > available if cross-zone X11 communication is desired across them. An aside for the record, should any of those other teams be considering this - another implementation option would be to implement on Solaris the "Abstract Namespace" for Unix domain sockets that Linux has implemented. These sockets use ascii strings to represent the name space that do not refer to filesystem paths, so could avoid having to arrange for filesystem coordination between the zones, but would clearly need some other method of configuring which ones were allowed to be seen in other zones. Since X.Org recently added support for using the abstract namespace for X11 connections on OS'es which support them, this could be especially interesting for BrandZ zones, since it would allow them to use Unix domain sockets without having to modify the Linux version of libX11 in a way similar to the modifications made in this case. That is absolutely not part of this case though. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Tue Aug 26 07:20:43 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QEKhaQ021459 for ; Tue, 26 Aug 2008 07:20:43 -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 m7QEKf9G016722 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 26 Aug 2008 07:20:43 -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 <0K6700A09P6IEJ00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 26 Aug 2008 08:20:42 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6700A5WP6G8L00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 26 Aug 2008 08:20:40 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7QEKek1017883 for ; Tue, 26 Aug 2008 07:20:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700101OXFIY00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 26 Aug 2008 07:20:40 -0700 (PDT) Received: from [10.6.102.118] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6700KV0P6112A0@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 07:20:26 -0700 (PDT) Date: Tue, 26 Aug 2008 07:20:25 -0700 From: Alan Coopersmith Subject: Re: Unix Domain Sockets for X11 clients in Trusted Extensions [LSARC/2008/506 FastTrack timeout 08/14/2008] In-reply-to: <48ACBCE2.3030101@sun.com> Sender: Alan.Coopersmith@sun.com To: LSARC-ext@sun.com Cc: Craig Payne , Glenn.Faden@sun.com, Lokanath.Das@sun.com, Ric.Aleshire@sun.com Message-id: <48B41129.6090201@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808062335.m76NZsPN002559@almas.sfbay.sun.com> <48AB4D51.4050401@sun.com> <48ACBCE2.3030101@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 404 Alan Coopersmith wrote: > The various parties have come to consensus off-line and a new spec is put > forth, so I am restarting the timer, and will let it run until the end of > the day Friday, August 22, unless someone would like to request more time. This case is now closed approved. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering