Graphical Desktop (X) Questions

Does the Network Security Toolkit Support A Graphical Desktop (X)?

Yes. However, the Network Security Toolkit boots in Console mode by default.

How Do I Start Get To The Graphical Desktop (X)?

The easiest way to bring up a graphical desktop (X) is by selecting Graphical Desktop mode at the initial boot screen.

If your system automatically boots into Console mode before you select the Graphical Desktop mode, you will need to log in as the root user, and run the following command to switch the system to Graphical Desktop mode:

[root@dhcp136 ~]# init 5

The above will start up the Graphical Desktop mode, but leave the system running the network instead of NetworkManager service. If you plan on logging in using the GNOME desktop, you may want to disable the network service and enable the NetworkManager service prior to starting the Graphical Desktop. To do this, enter the commands:

[root@dhcp136 ~]# chkconfig network off
[root@dhcp136 ~]# chkconfig NetworkManager on
[root@dhcp136 ~]# init 5

Does the Network Security Toolkit Support Virtual X (VNC)?

Yes. You can run a virtual X desktop on the Network Security Toolkit probe and view it remotely on any client machine. This allows Windows, Mac OS X and many other client systems to bring up the graphical desktop running on a remote Network Security Toolkit system. The client system will require a Java enabled web browser, or a native VNC viewer application.

You can start the VNC server on your Network Security Toolkit system either by running the nstvncadmin script or using the lvnc bash shell alias after logging into the Network Security Toolkit system. Alternatively, you can use the Network Security Toolkit Web User Interface (NST WUI). From the main menu bar, select 'System | Virtual Computing | VNC Server Session Management. The NST WUI provides a form which allows you to tweak many of the VNC server options (we highly recommend it).

Once you have the VNC server running on your Network Security Toolkit, you can use a VNC client program to attach to and control the virtual X desktop. Linux and Apple OS X 10.6 systems typically ship with a native or 3rd party VNC viewer. Here are some other 3rd party VNC clients which are known to work (shown alphabetically):

• Chicken of the VNC - For Apple OS X users.
• RealVNC - Many different versions and platforms. Not all of the versions are free.
• TigerVNC - Based off of TightVNC. For Windows and Linux systems (and Apple OS X users skilled in compiling GNU software).
• TightVNC - For Windows and Linux systems.
• UltraVNC - A Windows specialized version of VNC.

How Do I Launch X Applications from a ssh Connection?

How Do I Enable X Applications Across a ssh Connection?

You can enable X applications across a ssh connection by including the -X command line option.

ssh -X 192.168.1.100

Alternatively, you can add the ForwardX11=yes option to the start of your ~/.ssh/config file.

How Do I Verify That X Applications are Enabled Across My ssh Connection?

To verify that X applications are enabled across your ssh connection, check the setting of your DISPLAY environment variable and try launching a X application (like: xterm, xclock, gnome-terminal, ...):

taco-e:~ pkb$ ssh root@taco-dev32
Last login: Mon Oct 15 07:45:17 2012 from taco-e.linux.bogus

================================================
= Linux Network Security Toolkit (NST v2.16.0) =
================================================

[root@taco-dev32 ~]# echo $DISPLAY
localhost:10.0
[root@taco-dev32 ~]# xterm &
[1] 3629
[root@taco-dev32 ~]# 

Why Do X Applications Stop Working Across a ssh Connection?

If you are using the ssh utility under Mac OS X, you may find that X applications will launch perfectly fine initially. However, after a period of time elapses, you may find that you are no longer able to launch X applications. You should be able to use the ForwardX11Timeout parameter in your ~/.ssh/config file to extend this time. For example, adding the following line to the start of your ~/.ssh/config file should allow you to start X applications for 48 hours after establishing your ssh connection:

ForwardX11Timeout=48h

Why Won't The X Applications Launch From The WUI?

The Network Security Toolkit web based user interface (WUI) provides many links to launch X based applications. In order to use these links, all of the following conditions must be met:

• The client machine must be running a X server. Linux and Mac OS X machines typically support this natively. Windows machines do not support this natively - but you can use packages from http://www.cygwin.com/ to add this capability.
• The machine running the X server must have its firewall rules set such that TCP connections to the X server port are permitted. This will typically be port 6000. For security reasons, most systems will prohibit this by default.
• The X server on your client machine must permit TCP connections. For security reasons, many distributions disable this feature. You can scan the X server port (typically port 6000) to determine if the X server is accepting external TCP connections.
• You must run the xhost command on your X server to add the IP address of the Network Security Toolkit probe. This will allow the Network Security Toolkit probe to make use of your client machine's X server as its display.

The Best/Simplest Way To Enable X Connections

Refer to the "Running X Window Applications Through The SSH Tunnel" section on the "HowTo Limit Remote Access To "ssh" Connections" page for details on using ssh to enable the launching of X applications from the NST WUI.

The Difficult Less Secure Way

The following documents a more generic and difficult approach to enabling your NST system to accept remote X connections such as those triggered by launching commands from the NST WUI.

By default, the gdm desktop manager does not permit TCP connections to the X server. You can used the gdmsetup utility to enable this feature. Alternatively, you can add (or modify) the following line in your /etc/gdm/custom.conf.

[security]

# Adding the following to the [security] section will
# allow TCP connections to the X server

DisallowTCP=false

After updating the gdm configuration, you will need to restart gdm. This can be done by killing the gdm-binary process. Make sure you close all of your X applications BEFORE restarting the gdm process as all processes owned by the X server will be killed.

[root@probe ~]# ps -ef | grep gdm-binary
root      1354     1  0 14:19 ?        00:00:00 /usr/sbin/gdm-binary -nodaemon
root      2027  1917  0 14:48 pts/1    00:00:00 grep gdm-binary
[root@probe ~]# kill 1354
       

At this point, you should be able to log into your system and TCP port 6000 should be open. You can use the nmap command to verify this:

[root@probe ~]# nmap 192.168.110.2

Starting Nmap 5.21 ( http://nmap.org ) at 2010-11-03 14:49 EDT
Nmap scan report for probe (192.168.110.2)
Host is up (0.000014s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
443/tcp  open  https
6000/tcp open  X11

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
[root@probe ~]# 

Just because TCP port 6000 is open does not mean that your X server will accept connections from any host. In order to project a X window onto your X server, you will need to run the xhost command and grant access to the remote machine. For example, if the NST WUI you are using is running on machine 192.168.110.3, you need to permit machine 192.168.110.3 to display windows on your X server. To do this, you need to run the following command:

[root@probe ~]$ xhost +192.168.110.3
192.168.110.3 being added to access control list
[root@probe ~]# xhost
access control enabled, only authorized clients can connect
INET:192.168.110.3
SI:localuser:gdm
SI:localuser:root
[root@probe ~]#  

You should now be able to display applications running on machine 192.168.110.3 on your desktop. If your system is 192.168.110.2, here is a simple check you can use to verify this.

[root@probe]# ssh root@192.168.110.3
Password:
[root@192.168.110.3]# export DISPLAY=192.168.110.2:0.0; xclock &      

If everything is setup correctly, you should see the window of a clock application running remotely on 192.168.110.3 show up on your desktop.

How Do I Enable A Graphical Desktop Login At Boot?

On A Live Boot

When the NST system boots, choose Graphical Desktop from the syslinux boot loader screen.

You will need to do this each time you boot the system if you are booting from read-only media like a DVD. If you are booting from a Live USB installation, you can make the Graphical Desktop the default boot method by editing the file: "/syslinux/syslinux.cfg". The trick is to move the line: "menu default" from the bottom of the Console section to the bottom of the Graphical Desktop section.

On A Hard Disk Installation

There are several methods to boot directly to Graphical Desktop mode which is controlled by the init - Upstart process management daemon .

By default, you will have a text based login when you boot from the Network Security Toolkit CD. To enable a graphical login, one of the following may be done:

• At the grub boot screen, select Graphical Desktop mode. If you choose this route, you will need to do this every time your system boots.
• Edit the file: "/boot/grub/grub.conf". Change the number in the line: "default=0" to the index (starting from 0) of the entry in your grub configuration file that corresponds to the Graphical Desktop mode.
• Edit the file: "/boot/grub/grub.conf" and remove the " 3", " 5" values found at the end of each kernel line. The number 3 forces a Console boot and the number 5 forces a Graphical Desktop boot. By removing these values from the grub configuration file, whether or not a Graphical Desktop boot should be controlled by the "id:" line found in "/etc/inittab". Edit the "/etc/inittab" file and change the "id:" line to:

id:5:initdefault:

How Do I Force GNOME Fallback Mode At Boot?

We have found that some systems will fail in their GNOME 3 detection capabilities. Even though these systems might be capable of running a graphical desktop environment (using Fluxbox or GNOME 3 in fallback mode), you won't ever have the chance to log in, because the graphical login screen will fail to run.

The problem seems to be that the system fails in the way it detects the graphics capabilities and thinks that it can run GNOME 3 with all of the bells and whistles when in fact it can't. To fix this problem, you need to force fallback mode for the login screen. By forcing fallback mode, you will cause a instance of the /usr/libexec/gdm-simple-greeter process to run instead of a instance of gnome-shell --gdm-mode process.

To force fallback mode for the login screen, you need to edit the file /usr/share/gnome-session/sessions/gdm-shell.session and change (or add) the setting of the IsRunnableHelper parameter. By setting this parameter to /bin/false, the auto-detection will always fail and force the login screen into fallback mode.

Here is a example of what the modified /usr/share/gnome-session/sessions/gdm-shell.session might look like:

[GNOME Session] 
Name=Display Manager
RequiredComponents=gnome-shell;gnome-settings-daemon;
#IsRunnableHelper=bash -c 'gnome-shell --help | grep -q gdm-mode && /usr/libexec/gnome-session-check-accelerated'
IsRunnableHelper=/bin/false
FallbackSession=gdm-fallback

Finally run this NST tweak:

/usr/share/nstboot/setgnomedisplaymode gnome-fallback

How Do I Capture A GNOME Login Screen?

Use the following ImageMagick screen capture utility: import to capture an NST GNOME 3 login screen. The trick here is to be able to switch between virtual terminals using the command line with the chvt command.

• Boot your NST system using a graphical GNOME 3 desktop boot.

• Once the GNOME 3 login screen is present, switch to a virtual terminal using the keyboard: "Ctrl-Alt-F2" (i.e., Virtual Terminal Screen associated with the F2 function key). Systemd uses the systemd-logind manager application to control the virtual terminal allocation on an NST system.

• Log in as the "root" user.

• Finally run the following command saving the login screen as file: "nst_login_screen.png" to the "/tmp" directory:

chvt 1; sleep 5; XAUTHORITY=/var/lib/gdm/:0.Xauth DISPLAY=:0.0 import -window root "/tmp/nst_login_screen.png"; chvt 2;

Note 1: Virtual Login Screen (chvt 1)

Note 2: Virtual Terminal Login (chvt 2)