| Flightdeck-UI — a Cockpit on your Desktop | ||
|---|---|---|
| <<< Previous | Architecture of the Flightdeck-UI Library | Next >>> |
While security is not an area of focus for user interface elements, no project can be complete without discussing its security implications. Accordingly, this section presents a brief analysis of security issues concerning the Flightdeck-UI library.
User interface elements are designed to be embedded in an application. These elements must be generic in nature to be broadly useful. It is therefore not possible (beyond some general boundary checking) for a user interface element to act as a filter for an application's data. Only application-specific code can ultimately determine what should be displayed to the user, what should be thrown out, and what should cause an alarm condition to be raised.
Keeping the above discussion in mind, the following sections provide some suggestions for the secure use of the Flightdeck-UI.
Except for basic, command-line functionality, it is difficult to justify a user interface with administrator privileges. In the case of a GUI, running as root is particularly undesirable, since complex systems have more vulnerabilities.
Even if root access is required, it is possible to avoid having the user interface execute as root. For example, a simple custom daemon can talk to a non-privileged application, and carry out tasks on its behalf. Of course, such a daemon must be carefully written to prevent unauthorized operations, but that is the case for any program with administrative privileges. The daemon/non-privileged application solution isolates the critical functionality in a separate process, thus reducing the number of ways in which serious failures can occur.
In the Flightdeck-UI, two areas of potential vulnerability may be identified. One is the initialization of a user interface element, and the other is the update method call. These observations can serve as a basis for coming up with a threat model for Flightdeck-UI (although the full development of such a model is likely excessive). Note that a truly thorough discussion would cover vulnerabilities of Python, Tkinter and many other subsystems. This is well beyond the scope of this document, but it serves as one more reminder of why security is such a difficult topic.
In practical terms, a user of Flightdeck-UI may be advised to take the following security-related precautions.
Ensure that all calls to constructors of Flightdeck-UI classes have carefully verified parameters. Particular attention should be paid to items such as the Style objects and their driver functions because of their potential to cause destructive code to be executed — repeatedly in the case of the latter.
If the data passed via the update method of an AnalogGauge object is at all suspect, the driver function originally supplied to the gauge's Style object should perform a check on all data.
Particular care should be taken when using the cmdwatch.py demonstration program. This program monitors the output of a user-specified command. Supplying a destructive command (such as rm) could cause damage to the system. For this reason, it is not recommended that cmdwatch.py be run as root.
A powerful way to protect any application — whether it uses Flightdeck-UI or not — is to include careful screening of its inputs. Any potentially dangerous information (such as that received over a network) should be pre-checked by dedicated routines before reaching the core of the application.
The pre-check routines set up a perimeter defense around the core functionality. They should be kept as simple as possible to minimize errors in this critical part of the application. It is frequently practical to create a reconfigurable filter chain, which calls a number of these pre-check routines one after another. Such an arrangement typically results in a modular, reusable set of simple routines — just what is needed for security.
A perimeter defense allows greater certainty that the right data is being fed to the main body of the application. This central part can be extremely complex in some cases, thus making it difficult to build intrinsic security into it. The perimeter defense approach allows the factoring out of many security concerns. In consequence, security bugs should be easier to fix (there are fewer places to look for security problems), and functionality changes are far less likely to accidentally introduce new vulnerabilities.
| <<< Previous | Home | Next >>> |
| Source Code Files | Up | License |