Glenn Faden's Blog

  • August 16, 2007

Remote Multilevel Desktop Sessions

Guest Author
Trusted Extensions does not currently support remote desktop sessions using the X Display Manager Protocol, XDMCP. See dtlogin(1X). We currently lack a mechanism for passing the user and role identities of remote X11 clients to the trusted X11 server. The security policy for role assumption and DAC isolation depend on these attributes. We do use the Secure RPC protocol (see xhost(1)) to maintain an access control list for X11 connections, but we use getpeerucred(2) to match clients uids against this list. The corresponding ucredgetuid(3) function is not supported for remote connections.

Remote X11 client access is generally disabled, and only Trusted Path processes can modify the X11 server access control policy. For remote CDE access, we provide a script, dtappsession(1), which brings up a remote Tooltalk session and Application Manager. But this is a pretty limited solution. We are working on a secure solution based on XDMCP.

Meanwhile, I have developed a workaround which uses VNC. I am currently using this on a headless T2000 system, storms.sfbay, running Solaris 10 update 4. Since it has no graphics display, I considered using Xvnc, which is a combined X11 and VNC server. But that server doesn't support the xtsol extension, so it wasn't viable. Instead, I am using a shell script called Xvfb(1), which is a wrapper around Xsun(1), that uses a virtual framebuffer, and requires no mouse or keyboard. I am using a VNC server called x0vncserver, which is downloadable from the RealVNC web site. It is included in the VNC Free Edition for Solaris 7 (SPARC). Yes, it's that old!

There is a better VNC server that is included in Solaris Expresss Developer Edition, in /usr/bin/vino-session, that  works on x86/x64. I haven't found a pre-compiled version of vino-session or x0vncserver (x86) for Solaris 10, but the sources are available, so we could build one.

The RealVNC bundle includes a vncviewer that you can use on your local system. In my case, I run it in my internal zone. This doesn't require CIPSO, but your local system must be assigned the admin_low network template in the tnrhdb(4) file of the headless system.

On the headless system, I copied following two files:
  1.  cp  /usr/dt/config/Xservers /etc/dt/config
  2. cp  /usr/dt/config/Xsetup /etc/dt/config
I modified /etc/dt/config/Xservers.
#   :0  Local local_uid@console root /usr/X11/bin/Xserver :0 -nobanner

  :0   Local local_uid@none root /usr/openwin/bin/Xvfb :0 -nobanner -dev  vfb screen 0 1024x768x24

and added the following to /etc/dt/config/Xsetup
   /usr/local/bin/x0vncserver display=:0 PasswordFile=/.vnc/passwd >/dev/null 2>&1 &

The password for VNC access is set by the utility vncpasswd. Since I ran it as root on the server, it is stored under /.vnc
I ran the same program on my local system so that I don't need to enter the password each time.

After modifying these files, you need to restart the dtlogin process:
svcadm restart cde-login
On the client side I just run this:
vncviewer PasswordFile=/home/gfaden/.vnc/passwd  storms.sfbay

 You can also use the Java-based vino viewer in SXDE, by running /usr/share/gnome/vino/vino-client.jar .

The dtgreet(1)  window (Welcome to storms) comes up and you can choose trusted CDE or JDS. They should both work fairly well. When you logout, the VNC session ends, too.

There are a few minor problems, such as the cursor not being updated correctly, and there is an issue with changing Trusted JDS workspace labels. In my previous blog, I mentioned a workaround for this bug which disabled the MIT Shared Pixmap extension, MIT-SHM. However, the VNC server requires this extension, so it must be enabled.

VNC supports encryption between the client and server if you need it. In my case, I didn't bother; I'm on a protected network (SWAN), or using IPsec when working from home.

Join the discussion

Comments ( 2 )
  • Remote Desktop Software Thursday, July 8, 2010

    Please forgive me because I am a bit of a layperson. My question is, why would you go to all this trouble when you could install third party software? I grabbed some remote desktop software from Proxy Networks and I was enjoying a stable connection within minutes. What are the advantage to that solution over what you have described here?

  • sean perez Tuesday, January 25, 2011

    For someone who knows nothing about networking or remote desktop access custom solutions, would you recommend buying 3rd party remote desktop software? My theory is that it will save time vs hiring/training employees to follow more complex bespoke procedures. Thoughts?

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.