Remote Multilevel Desktop Sessions

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
# VNC
   /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.

Comments:

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?

Posted by Remote Desktop Software on July 08, 2010 at 04:32 AM PDT #

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?

Posted by sean perez on January 25, 2011 at 07:18 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog explores some of the security features of Oracle Solaris. In particular, topics such as Role-Based Access Control and Labeled Security are my special interests.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks