D6.6 MILS Console System

Transcription

1 Project Number D6.6 MILS Console System Version 1.0 Final Public Distribution Frequentis, LynuxWorks Project Partners: Fondazione Bruno Kessler, fortiss, Frequentis, LynuxWorks, The Open Group, RWTH Aachen University, TTTech, Université Joseph Fourier, University of York Every effort has been made to ensure that all statements and information contained herein are accurate, however the D-MILS Project Partners accept no liability for any error or omission in the same Copyright in this document remains vested in the D-MILS Project Partners.

2 Project Partner Contact Information Fondazione Bruno Kessler fortiss Alessandro Ciamatti Harald Ruess Via Sommarive 18 Guerickestrasse Trento, Italy Munich, Germany Tel: Tel: Fax: Fax: cimatti@fbk.eu ruess@fortiss.org Frequentis LynuxWorks Wolfgang Kampichler Yuri Bakalov Innovationsstrasse 1 Rue Pierre Curie Vienna, Austria Saint-Cyr-l Ecole, France Tel: Tel: Fax: Fax: wolfgang.kampichler@frequentis.com ybakalov@lnxw.com RWTH Aachen University The Open Group Joost-Pieter Katoen Scott Hansen Ahornstrasse 55 Avenue du Parc de Woluwe 56 D Aachen, Germany 1160 Brussels, Belgium Tel: Tel: Fax: Fax: katoen@cs.rwth-aachen.de s.hansen@opengroup.org TTTech Université Joseph Fourier Wilfried Steiner Saddek Bensalem Schonbrunner Strasse 7 Avenue de Vignate Vienna, Austria Gieres, France Tel: Tel: Fax: Fax: wilfried.steiner@tttech.com saddek.bensalem@imag.fr University of York Tim Kelly Deramore Lane York YO10 5GH, United Kingdom Tel: Fax: tim.kelly@cs.york.ac.uk Page ii Version 1.0

3 Contents 1 Introduction 2 2 Objectives Objectives Design and Implementation Guidance Open design and implementation MILS compatible Architecture Description MCS Use Case: Frequentis Voice Service (FVS) Module Decomposition and Dependencies Functional Description Display Manager Device Assignment and Control Trusted Path Input and Output Channels Display Device MCS Clients Voice Client Data Client Design and Implementation Design MILS Console Subsystem Display Manager Device Assignment and Control Trusted Path Input Channel Output Channel Implementation References 14 Version 1.0 Page iii

4 List of Figures 1 MCS single I/O subject (Partition C) MCS decomposition MCS modules and dependencies MCS architecture MCS internal and external interfaces Trusted Path: Partition A Trusted Path: Partition B Page iv Version 1.0

5 Document Control Version Status Date 0.1 Initial outline, Exec Summary 16 March Architecture, Function, Design 29 September AADL corrections 03 October Cloned to make D7.2, limit scope to MCS 11 October AADL corrections, Implementation 03 November Final version Version 1.0 Page v

6 Page vi Version 1.0

7 Executive Summary The D-MILS Project has created a distributed MILS platform, formed from the composition of MILS foundational components. Of the several foundational components identified by the conventional MILS platform architecture, the D-MILS project has need of two components in addition to the separation kernel: the MILS Network Subsystem (MNS) and the MILS Console Subsystem (MCS). Since the Frequentis Voice Services demonstrator requires simultaneous operator interaction with multiple safety and security domains, the MCS, which has the rôle to provide such separation, is included in the technology requirements for D-MILS. MCS, in contrast to the MNS, is not central to the distributed MILS technology, and consequently a somewhat more modest implementation of MCS is undertaken in the D-MILS Project. Nonetheless, both subsystems are conceived in the spirit of their definition in the MILS platform architecture. As for the MNS, the implementation of MCS is intended to be functionally consistent with the MILS architecture definition, though it is not intended to implement all of the functional and assurance requirements specified for the high-assurance MCS foundational component. This approach permits a more complete future implementation, both in terms of functionality and assurance, to be developed by refinement or substitution of parts, without requiring changes to the architecture of the system or to the clients of the MCS. This document describes the implementation of MCS for D-MILS. MCS for D-MILS is implemented as a single subject running on each D-MILS node needing that feature. Since the MCS is required to simultaneously handle user interface data from multiple security/safety domains, it implements and enforces separation of such data as per its rôle in the MILS platform. The internal structure of the MCS is illustrated, the communication between the MCS and its clients is discussed, and the configuration and initialization of the MCS are described. Version 1.0 Page 1

8 1 Introduction This document, and the software it describes, constitute Deliverable D 6.6 of WP 6 (MILS Console System) of the EU FP7 Distributed MILS for Dependable Information and Communication Infrastructures (D-MILS) Project; Project Number The Distributed MILS Project (D-MILS Project) has created a D-MILS platform, formed from the composition of MILS foundational components. Of the several foundational components identified by the conventional MILS platform architecture, the D-MILS project has need of two components in addition to the MILS separation kernel: the MILS Network Subsystem (MNS) and the MILS Console Subsystem (MCS). This document describes the requirements, architecture, functionality, design, implementation, and assurance considerations for the MCS for distributed MILS (D-MILS). Page 2 Version 1.0

9 2 Objectives The technical requirements for the MILS Console System are based on the WP1 requirements for the Frequentis Voice Services demonstrator (D 1.2) [2], the D-MILS Technology Requirements (D,1.3) [1], and the general characteristics of MILS console subsystems as described in the MILS platform architecture [3]. 2.1 Objectives The objective is to provide a standalone subject (or subjects) implementing a MILS console system that supports Frequentis voice service, as well as other common user interface devices, and has a configuration function compatible with the DMCC and the configuration functions of the MILS network and the separation kernel. 2.2 Design and Implementation Guidance Open design and implementation In keeping with the European Commission s emphasis on effective dissemination and exploitation, is intended that the D-MILS technology be easily adopted and applied by as broad a community of developers and industries as possible. Other projects should be able to adapt it and other research extend it MILS compatible Numerous concepts and definitions are already established within the MILS community. Additional emerging standards are being developed that are needed for the achievement of long held community goals for MILS and the growth of MILS to be capable of handling more diverse use cases. Consequently, although not all of these considerations might be germane if D-MILS were being done in a vacuum, they are relevant because of the bigger picture and future plans to build upon Distributed MILS and to further augment the capabilities of MILS. Version 1.0 Page 3

10 3 Architecture Description 3.1 MCS Use Case: Frequentis Voice Service (FVS) A distributed MILS (D-MILS) architecture for FVS is presented in D 7.2. One of the FVS positions is an integrated working position, which utilizes the concept of an MCS. The FVS test bed for D-MILS verification includes voice and data services providing radio and data communication features. Each element provides a distinct feature set needed to implement the required end-to-end communication services. The working position integrates voice and data services and therefore has access to different domains. MCS for D-MILS is implemented as a single subject running on each D-MILS node needing that feature. Since the MCS is required to simultaneously handle user interface data from both the voice service and data service domains, it implements and enforces separation of such data. The basic internal structure of the MCS is illustrated in figure 1. Figure 1: MCS single I/O subject (Partition C) Partition C hosts the MCS and maintains node internal connections (red arrows) to its clients, partition A (voice) and partition B (data) domain. Such connections are part of the D-MILS configuration and permit flows between partitions A - C and B - C but strictly separate A from B. For the particular purpose of performance validation it has been decided to implement input and output channels via TCP/IP. This approach takes advantage of the D-MILS architecture but also simplifies the assignment and control of client channels as they connect via D-MILS node internal network interfaces. 3.2 Module Decomposition and Dependencies There are two groups of modules that are considered - modules that comprise the MCS and modules that are external to the MCS but either map an I/O devices or provide a certain function essential Page 4 Version 1.0

11 to the Frequentis voice service. Modules that are internal to the MCS (corresponding partition in brackets): Display Manager (C) Trusted Path (C) Device assign and control (C) Display Device (C) Input channels (C) Output channels (C) FVS modules that are not part of the MCS: Voice client (A) USB subsystem (A) Data client (B) Monitor (C) USB subsystem (C) Media input and output devices are allocated to the voice service specific subject (USB subsystem partition A) by a device allocation subsystem that is independent of the MCS, as in figure 2. Figure 2: MCS decomposition Remaining input and output devices (USB subsystem partition C) that are monitor, keyboard and mouse are managed by the MCS. The MCS subject implements display manager, trusted path and device assignment and it defines MILS ports interconnecting these entities. Further there are input and output channels towards client partitions. The voice client supports a browser based user interface (BUI) providing output for display by any Internet browser or any web rendering engine. Thus we differentiate between a monitor, specifically a piece of computer equipment and a display device that is responsible for rendering and display of the requested contents on the screen in the following sections. Version 1.0 Page 5

12 4 Functional Description Figure 3 provides a schematic overview of functional elements described within this section. Figure 3: MCS modules and dependencies 4.1 Display Manager The display manager mediates all output to the display. It is responsible for enforcing the display policy and therefore partitions the display device in time and/or space. A guiding principle for the operation of the trusted display manager is that the current partitioning is readily apparent to the human user. The trusted display manager must present the output of clients in a sufficiently visually unambiguous manner so that the user will not make security-related errors based on a misinterpretation of information presented on the display device arising from the manner in which the information is presented. For example, a trusted display region (described in the next section) could continuously display the security attributes of the (topmost) window under the cursor. 4.2 Device Assignment and Control The MCS provides the ability to associate groups of input and output devices with input and output channels, and to assign channels, and thereby the associated devices, to clients. An association of several devices together to a channel constrains the devices to be assigned simultaneously. For example, a keyboard and a mouse may be constrained to always be assigned to the same client at any given time. Device assignment via channels may be of different types; for instance devices may be used in certain periods of processing by one client at a time. This concept is also known as "Serial Sharing". The MCS may also provide the ability to assign an input or output device to a client for the Page 6 Version 1.0

13 duration of a session, known as "Semi-permanent Assignment", or completely assigned to the client. Finally, certain devices may handle output from multiple clients at the same time, or handle input for multiple clients, called "Concurrent Sharing". 4.3 Trusted Path The trusted path is a logically distinct communication path between the MCS and the user that is used for security relevant communications. The trusted path may be initiated either by the user, to perform an MCS built-in security relevant function, or by MCS, to inform the user of a security relevant event, or status information. When communicating with the trusted path or a trusted subsystem, input and output between the trusted function and the user flows over distinct channels. 4.4 Input and Output Channels The MCS mediates all access by client partitions or subjects to human interface devices (HID) comprising the console input and console output devices. The client sends data to the console output devices on output channels, and receives data from the console input devices on input channels. For each client there are zero or more input channels, one or more output channels. 4.5 Display Device The rendering engine responsible for displaying the requested content. For example if the requested content is HTML, it is responsible for parsing the HTML and CSS and displaying the parsed content on the screen. This allows to implement a trusted display independent of the physical device (video system/monitor) of the underlying platform but requires a single i/o partition. 4.6 MCS Clients Voice Client The voice client is a VoIP client that supports SIP (signaling) and RTP (media) and connects to preconfigured VoIP services (e.g. gateways to analoge radios) or voice clients located at remote D-MILS nodes. User interaction, originating from a remote browser based user interface (BUI), establishes, controls and terminates radio and telephone dialogs Data Client The data client is a simple load balancer for TCP based protocols. As such it relays and filters HTTP traffic between the display device and data services located at remote D-MILS nodes. The data clients maintains a list of data services the MCS is permitted to access. Version 1.0 Page 7

14 5 Design and Implementation This section describes the design and implementation of the MILS Console System. 5.1 Design Figure 4 illustrates how the MCS policy architecture is designed. The MCS itself is a native application that supports web content rendering and extends JavaScript to support custom functions. This is used in order to implement the trusted path by capturing display events and maintaining specific callbacks to such events within the MCS. In fact, each client partition supports an HTML based user interface locally stored to and accessed by the MCS application through the device assignment and control function. The trusted display mode is configured to simultaneously display two windows containing information from the voice and data partition. Further, the MCS input and output channel offers web sockets (WS) via HTTP for duplex communication. MILS ports internal to the MCS are part of the MCS subject and implemented using inter-process communication facilities of the partitions operating system (dashed lines), whereas, ports interconnecting MCS and client partitions utilize instances of network connections from the D-MILS node local loopback interface. Figure 4: MCS architecture A Webkit webview represents a concurrently shared display device allowing to implement a trusted display independent of video system/monitor in use. Since this is a plain user mode implementation, neither specific kernel drivers required nor does it require to develop extra modules for a specific target platform. The Webkit webview allows implementing C functions as call back for JavaScript provided to the BUI in order to implement the trusted path. The following paragraphs describe each functional element following the rules of MILS-AADL. Page 8 Version 1.0

15 5.1.1 MILS Console Subsystem The MCS core implements four external interfaces that connect to MCS clients (data), keyboard (event), mouse (event) and he display device (data). Interfaces internal to the MCS are in general data interfaces that read configuration files, exchange render objects or request callback functions, see figure 5. Specific interfaces (event, data) are clockwise numbered depending on where they connect. Figure 5: MCS internal and external interfaces system MCS features Input: out data port; Output: in data port; Keyboard: in event port; Mouse: in event port Display: out data port; end MCS; system implementation MCS.Impl subcomponents display_manager: thread tmanager.impl; input_channel: thread tinput.impl; output_channel: thread toutput.impl; device_assignment: thread tassignment.impl; trusted_path: thread tpath.impl; flows port Output -> output_channel._indata4; port input_channel._outdata4 -> Input; port display_manager._outdata2 -> Display; connections port Keyboard -> trusted_path._inevent2; port Mouse -> trusted_path._inevent3; end MCS.Impl; Version 1.0 Page 9

16 5.1.2 Display Manager thread tmanager features _indata3: in data port; _indata4: in data port; _outdata2: out data port; end tmanager; thread implementation tmanager.impl flows port trusted_path._outdata1 -> _indata3; port output_channel._outdata2 -> _indata4; port _outdata2 -> Display; end tmanager.impl; Device Assignment and Control thread tassignment features _outdata1: out data port; _outdata2: out data port; _outdata4: out data port; end tassignment; thread implementation tassignment.impl flows port _outdata1 -> output_channel._indata3; port _outdata2 -> trusted_path._indata1; port _outdata4 -> input_channel._indata1; end tassignment.impl; Trusted Path thread tpath features _inevent2: in event port; _inevent3: in event port; _indata1: in data port; _outdata1: out data port; _outdata4: out data port; end tpath; thread implementation tpath.impl flows port device_assignment._outdata2 -> _indata1; port _outdata1 -> display_manager._indata3; port _outdata4 -> input_channel._indata2; connections port Keyboard -> _inevent2; port Mouse -> _inevent3; end tpath.impl; Input Channel thread tinput features _indata1: in data port; _indata2: in data port; _outdata4: out data port; end tinput; thread implementation tinput.impl flows port device_assignment._outdata4 -> _indata1; port trusted_path._outdata4 -> _indata2; port _outdata4 -> Input; end tinput.impl; Page 10 Version 1.0

17 5.1.6 Output Channel thread toutput features _indata2: in data port; _indata4: in data port; _outdata2: out data port; end toutput; thread implementation toutput.impl flows port device_assignment._outdata1 -> _indata2; port Output -> _indata4; port _outdata2-> display_manager._indata4; end toutput.impl; 5.2 Implementation WebkitGTK, as the foundation of the MCS implementation, implements an HTML renderer and therefore allows a static configuration of the display device that is assigning different display areas to client partitions. Trusted Path and Display Manager are functions called by the MCS application and read configuration files that are considered as part of Device Assignment and Control. The following code example describes the main tasks of the Display Manager that are registering a callback function with view events (keyboard and mouse) in order to implement the Trusted Path and loading the main view of the display. void funcdisplaymanager() {... g_signal_connect (G_OBJECT (web_view), "window-object-cleared", G_CALLBACK(window_object_cleared_cb), web_view); webkit_web_view_load_uri (WEBKIT_WEB_VIEW (web_view), "file://dac/mcs-ui.html"); }... Display areas are assigned by loading the following file (mcs-ui.html) <!DOCTYPE html> <html> <head>... </head> <body> <iframe allowtransparency="true" src="file://dac/mcs-ui-voice.html"...></iframe> <iframe allowtransparency="true" src="file://dac/mcs-ui-data.html"...></iframe> </body> </html> which puts the user interface that connects to the voice client partition on top of the data client partition user interface. The registered callback function implements the Trusted Path with code fragments that highlight and indicate the active partition within a dedicated screen area (label) as listed below. Version 1.0 Page 11

18 void functrustedpath() {... gtk_label_set_attributes(gtk_label (g_tp_label), attrlist); gtk_label_set_text (GTK_LABEL (g_tp_label), stringplaintext); }... Further, when loading html files that are specific to client partitions, JavaScript code is loaded and initiated that implements Input- and Output Channel per domain. function initwebsocket() { window.websocket = window.websocket window.mozwebsocket; connection = new WebSocket( ws://... ); } function SendData(element, state) { connection.send(json.stringify({id: id, el: element, st: parseint(state)})); } function ReceivedData(json_message) {... } var getmessage = JSON.parse(json_message); var element = getmessage.el; var state = getmessage.st; var id = getmessage.id; Figure 6 shows the MCS with a split user interface - the top display region shows the user interface which connects to Partition A (voice), whereas the section below connects to the data domain (Partition B). The bottom status line indicates the active partition according to the Trusted Path. Figure 6: Trusted Path: Partition A Page 12 Version 1.0

19 As soon as the user changes to the data domain (mouse move or mouse click) the Trusted Path status line changes to Partition B and the corresponding user interface region is highlighted with a red frame, as shown in figure 7. Figure 7: Trusted Path: Partition B Summarized, the MCS implements Display Manager, Trusted Path and reads static configuration from a file system local to Partition C (considered as Device Assignment and Control). Both, Inputand Output channels are instantiated per display region and directly connect to corresponding partitions without any interference. Version 1.0 Page 13

20 References [1] Requirements for distributed MILS technology. Technical Report D1.3, Version 1.2, D-MILS Project, August [2] Safety and security requirements for Frequentis Voice Service demonstrator. Technical Report D1.2, Version 1.3, D-MILS Project, March [3] Rance DeLong. MILS Platform Protection Profile, Draft version 0.4, To appear. 3 Page 14 Version 1.0