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 at 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 >> >>
