A Nitpicker's guide to a minimal-complexity secure GUI

Welcome to the interactive presentation of Nitpicker. Nitpicker is a new low-complexity graphical user interface (GUI) that is designed to execute security-sensitive applications and existing software side-by-side. This presentation will show off the features of Nitpicker and guide you through our software. The presented software stack is in an experimental stage and may include glitches. Still, I hope to illustrate the core ideas of Nitpicker.

Experimentation platform

Before we start with the actual presentation of Nitpicker, let me introduce the experimental operating system platform that we use as foundation. Right now, your computer executes the software stack that is illustrated in this figure:

The basis for the operating system is provided by the L4/Fiasco microkernel developed by our research group. This small kernel is the only software that is executed with kernel priviledges. In contrast to a classical OS kernel such as the Linux kernel with millions of lines of priviledged code, L4/Fiasco consists of only 15,000 lines of privileged code. All other system components and applications are deprivileged user-level programs. Each of these programs is executed within a protected address space. You can think of such an address space as a protecting capsule. When protected by such a capsule, a program cannot be damaged or spied on by another unauthorized program.

Ontop of the L4/Fiasco microkernel, there are some basic services, for example a memory manager, an application loader, and a device manager. These components consist of ca. 35,000 lines of code. Compared to the Linux kernel, this OS foundation is extremely tiny. Nitpicker runs directly ontop of the L4/Fiasco microkernel und uses these basic services.

The program, you are currently looking at is a client of Nitpicker. Again, this presentation program is fairly small (ca. 3,500 lines of code). So altogether, the currently executed software stack has an extremely low source code complexity of less than 60,000 lines of code. Whereas lower source-code complexity practically means less bugs and flaws, it also means less features. For this reason, it is important to provide support for executing legacy applications as well.

How about some DOpE?

For Nitpicker, there are almost no native applications available. The current software setup on its own is of limited use. To enable existing legacy software to be used in this environment, Nitpicker provides the feature to support other windowing systems as its clients and therefore, make the applications of these windowing systems available to Nitpicker as well. Let me illustrate this idea by starting the DOpE window server as a Nitpicker client. DOpE is a window server that runs on top of L4/Fiasco. Our research group develops DOpE as an experimentation platform and there exist various toy applications for this GUI.

You can start DOpE by clicking here (in the Demo-CD version of this document).

After some seconds, some new window appears on screen. These windows are completely managed by the DOpE window server. For example, DOpE decides what to do when you drag a window title with the mouse, how to draw the user interface elements (widgets), and how to layout the widgets. Both clients, the presentation program as well as DOpE window server, share one and the same screen and nonetheless, you can naturally interact with both of them. The following figure illustrates the current setup:

When you click on one of the DOpE windows, DOpE's root window will become visible and you can see the drop shadows of the DOpE windows. For making screen shots more attractive, DOpE supports translucent windows. You can see such a translucent window by clicking on the Particles Button. Note that DOpE is not aware of the presence of the Tutorial Browser. It has no way to observe the Tutorial Browser and therefore, cannot incorporate the Browser window in the translucency computations. If you move the Particles window over the Browser window, you will not see the Browser window shining through the DOpE window.

But probably you never have heard of DOpE before. So this is still of limited use for you. Let me give another example.

X Window System

The L4/Fiasco microkernel allows us to execute other operating system kernels as user-level programs. In 1997, our group demonstrated, that a slightly modified Linux kernel can be executed as user-mode program on the L4/Fiasco microkernel, hence this version of Linux is called L4Linux.

You can start L4Linux by clicking here (in the Demo-CD version of this document).

In a couple of seconds, a new DOpE window should pop up, where you can see the boot sequence of Linux. For this demonstration, we run Linux entirely on a small custom-made RAM-disk distribution. But you could use the L4Linux kernel also with a commodity Linux distribution. L4Linux is completely binary-compatible with Linux. For simplicity, the RAM-disk does not feature multiple users. When the boot sequence is finished, you can log in as root (Do not forget to activate the L4Linux console window by clicking on it):

 L4Linux login: root

Now you should see a fresh shell prompt waiting for commands:

 L4Linux:~#

We do not want to go much into L4Linux but go straight to starting the X Window System (X11):

 L4Linux:~# startx

In the L4Linux console window, you will see a couple of messages and after some seconds, some X11 windows (e.g. a X terminal window) will appear. We will not need the (now blanked out) L4Linux window anymore and you may move it out of the visible screen area by dragging its window title.

In contrast to the classical approach of displaying an entire desktop within one window, Nitpicker allows for much more flexibility. As you can see, all windows of DOpE, the presentation program, and X11 are integrated into one screen and you can interact with all of them at the same time. The windows of the X11 session are managed by the WindowMaker window manager and all features of this window manager are available, for example virtual desktops and scrolling menus.

Note that the default keyboard layout used is german. If you want to change the keyboard layout, for example to US-english, you can issue the following command to the X terminal window:

 bash-3.1# setxkbmap us

The following figure illustrates the current setup:

Nitpicker allows us to interact with an arbitrary number of window systems and small native Nitpicker applications at the same time. In the next Section, we will see the benefit of this approach for protecting security-sensitive applications from spyware.

Fighting spyware

GUIs of todays operating systems (e.g., X11) enable arbitrary applications to sample key strokes and mouse movements. Furthermore, there are no means to prevent programs from observing and even manipulating other applications. As a consequence, one malicious program with access to the GUI can put the privacy of the user and all other GUI applications at risk.

Of course, Nitpicker cannot improve the security of such legacy GUIs but it enables us to execute multiple of these Legacy GUIs at the same time while maintaining isolation between them. For example, we could run two instances of L4Linux, one for processing sensitive information and another for browsing the internet. Both instances of L4Linux can have a full X11 session. If the Internet-L4Linux gets compromised by spyware, the spyware can spy only on the Internet-L4Linux but it cannot observe or manipulate the other L4Linux instance.

Key loggers

For illustrating the idea of preventing key loggers, let us start some spyware by hand by issueing the following command to the xterm window:

 bash-3.1# xeyes &

The Xeyes program observes all mouse movements of the user. A similar program could sample all key strokes of the user. When using X11, the user's privacy depends on all programs that use his X11 session. Modern desktop environments involve an extremely large amount of high-complex programs. With regard to the user input, the user has to trust millions of lines of code. With Nitpicker, we can improve this situation.

If you move the mouse cursor over a non-X11 window, you will see that Xeyes is not able to follow your mouse movements anymore. Nitpicker routes user input events exclusively to the client to which the user refers his input. For example, text (e.g. a password) typed into a DOpE window is only visible to DOpE, X11 wouldn't even know that a key was pressed.

Arcane observation

Key loggers are just one example of spyware. Another approach to intrude the privacy of the user is observing his desktop. Current window systems provide no means to protect the user from such attacks. The simplest way to observe the desktop is simply to take a screenshot (that may include confidential information) and transfer the image over the network. On X11, any program is allowed to take screenshots. Now, let us see what an attacker can see after taking a screenshot of our current setup.

For taking a screenshot, we use the X11 screenshot program called xwd and write the image into the file 'scrdump':

 bash-3.1# xwd -root -out scrdump

Now, let us inspect the result by using xwud. After starting xwud, you can leave the program by pressing 'q':

 bash-3.1# xwud -in scrdump

As you can see, the screenshot contains only the X11 windows. The Tutorial Browser as well as all DOpE windows are not visible. Therefore, a security-sensitive DOpE application is protected from being observed by X11 malware.

Uncovering Trojan Horses

Beside Spyware, Trojan Horses are the most prominent species of malware. Trojan Horses mimic trusted applications to wrest sensitive information from the user. With Nitpicker, all window decorations are managed by the client. Thus, Nitpicker cannot prevent a malicious client from imitating the look and feel of a security-sensitive application, for example a login window that requests a password.

To uncover Trojan Horses, Nitpicker provides a special labeling feature that I called X-Ray mode. You can toggle Nitpicker between X-Ray mode and the currently active flat mode by pressing the Scroll-Lock key on your keyboard.

In X-Ray mode, all screen regions are dimmed except for the client that currently holds the focus. Additionally, you can see textual labels that Nitpicker assigns to all the different regions on screen. The labeling information is provided by the loader (which should support secure booting). The labels enable you to clearly distinguish windows managed by the different domains (DOpE, X11, Scout Tutorial Browser). Note that the labels are not located at fixed positions within the windows, but they are placed such that they are visible. For this reason, I call these labels floating labels. In contrast to the text displayed in window titles, these floating labels cannot be faked by any application, so you can trust the presented information and uncover Trojan Horses.

Now, security-sensitive applications can securely communicate with the user via Nitpicker without depending on a huge legacy GUI. Therefore, the so called trusted computing base (TCB), the security-critical code foundation, for such applications can be reduced by an order of magnitude.

How does it work?

Even though there are several interesting technical aspects of Nitpicker, let me explain only the most important one: How can we display multiple different windowing systems together at one desktop?

Nitpicker deals with only two kinds of objects: buffers and views.

A buffer is a memory region that holds two-dimensional pixel data. The memory region is provided by the client to Nitpicker via shared memory. Nitpicker has no notion of windows. A window is expected to have window decorations and policies, for example a window can be moved by dragging the window title with the mouse. Nitpicker provides a much simpler object type that we call view. A view is a rectangular area on screen presenting a region of a buffer. Each view has an arbitrary size and position on screen, defined by the client. If the view's size on screen is smaller than its assigned buffer, the client can define the viewport on the buffer by specifying a vertical and horizontal offset. Note that there may exist multiple views on one and the same buffer whereas each view can have an individual size and position on screen and presents a different region of the buffer. Each time a client changes the content of a buffer, it informs Nitpicker about the affected buffer region. Nitpicker then updates all views that display the specified buffer region. Views may overlap on screen. A client can define the stacking position of a view by specifying an immediate neighbor in the view stack. While each client manages the local stacking order of its views, the global stacking order of all views is only known to Nitpicker.

The following Figure illustrates the use of buffers and views for merging two legacy window systems into one Nitpicker screen:

Each client performs drawing operations on its buffer and tells Nitpicker about the buffer regions to display on screen by creating views on the buffer. In the Figure above, each client creates one view per client window and keeps the view configuration always consistent with the window configuration. For example, when the user brings a legacy window ontop, we also bring the corresponding view ontop.

To integrate a legacy window system into a Nitpicker session, we need to do the following things:

1. Enable the legacy window system to perform drawing operations into a Nitpicker-buffer instead on screen. This can be done by providing a pseudo-frame-buffer driver

2. Feed input events from Nitpicker to the legacy window system, for example by using a custom driver or emulating input devices, for which drivers are available

3. Apply legacy window-state changes to corresponding Nitpicker-views

Whereas the first two points are straight-forward, the third one depends on the actual legacy window system. On X11, we can simply record all window events by using a X11 client program (250 lines of code) that registers for all window events at the X11 root window. Therefore we do not need to modify the X-Server at all. For supporting DOpE, I added ca. 200 lines of support code to the DOpE window server. A more ancient example is the Atari GEM GUI running in the Hatari emulator. I managed to integrate GEM into Nitpicker by installing a small patch program (250 lines of C/ASM code) on the unmodified (closed-source) Atari TOS and adding a new virtual device to the Hatari emulator.

These examples demonstrate the very low engeneering effort needed to make legacy GUIs available on Nitpicker.

If you are interested in learning more details about the inner life of Nitpicker, I refer you to the following paper:

N. Feske, C. Helmuth

A Nitpicker's guide to a minimal-complexity secure GUI

(In proceedings of the 21st Annual Computer Security Applications Conference (ACSAC 2005), Tucson, Arizona, USA, December 2005)

Download at

http://www.tudos.org/papers_ps/feske-nitpicker.pdf

Why is it cool?

To conclude this presentation, let me summarize the strongest points of Nitpicker. First of all, the biggest strength of Nitpicker is the low number of features, simplicity and an extremely low source-code complexity. The following figure compares Nitpicker against other GUI servers.

For X11, I only counted the inner core of the X.org server without any drivers. EWS is the EROS Window System, developed by Jonathan Shapiro's group who reanimated the discussion about secure GUIs in 2004.

The extremely low source-code complexity of Nitpicker enables us to dwarf the trusted computing base of security-sensitive GUI applications by an order of magnitude compared to todays commodity operating systems.

Secondly, Nitpicker is no compromise of compatibility versus security but it enables us to complement commodity platforms by secure applications. This argument applies also to graphical real-time programs as another application area. Nitpicker allows us to interact with real-time applications and legacy non-real-time applications at the same time.

Finally, its source code is available under the terms of the GPL.

Future challenges

Of course, there exist plenty of ideas about Nitpicker's future, for example making Nitpicker available to other platforms than L4 (e.g., the Xen Hypervisor) or applying Nitpicker to secure platforms (e.g., as a way to interact with virtual security domains in a MLS system). The most interesting research area for me however, is the safe support of hardware accelerated graphics. Currently, Nitpicker performs graphical output via software graphics routines. Making hardware-accelerated graphics usable by Nitpicker and untrusted clients at the same time is a very challenging problem that I'd like to address in my future work.

Contact

For questions, feedback, criticism, or any other reason, please contact me:

Postal address

 Norman Feske
 Dammweg 2
 01097 Dresden
 Germany

E-Mail

 feske@os.inf.tu-dresden.de

Website

http://os.inf.tu-dresden.de/~nf2

Reboot the machine

Click here (in the Demo-CD version of this document) to reboot your machine.