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
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
(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:
- cp /usr/dt/config/Xservers /etc/dt/config
- 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.