Architecture
This page describes the architecture of the security-oriented technical platform.
The architecture of Safecor is made in respect of the design rules.
A product is composed of one ore more User Domains (virtual machines) with their own application module. The modules should be designed according to their level of trust. All modules using external data (communicating with USB drives or the network for example) should be considered as not trustable and should be separated from modules that only manipulate commands and user interfaces.
A Domain is a volatile virtual machine created on startup. When the virtual machine is created, an Alpine Linux is installed and the application package and its dependencies are installed (see topology.json).
In accordance with the design rule "stateless system", a Domain only exists in memory as long as the system is running. It is re-created each time the system is started.
The product built on Safecor cannot modify any of the core components, including the Domain0, sys-usb and sys-net.
The protocol break strategy is applied everywhere in order to reduce the attack surface.
Most of the physical PCI devices are considered as dangerous because they can be used to introduce threats in the system. For this reason they are captured by dedicated virtual machines:
- sys-usb captures all the PCI buses involved in USB
- sys-net captures all the PCI buses involved in networking (network cards)
The capture in achieved using the PCI passthru facility provided by XEN. It is absolutely necessary to have IOMMU enabled on the system (through VT-d on Intel or AMD-Vi on AMD) for a good memory and device isolation.
The video display and graphic card are captured by Domain0 but the Domains don't access them directly.
The Domain0 offers different low-level services to the Domains including virtual disks, inputs and display.
In the Domain0 there are different services:
-
Mosquittois the core component for the messaging. -
Safecor MQTT tunnelsis a proxy that filters and copies the messages between the Domains sockets and the Mosquitto sockets. -
Safecor orchestratoris the core component for the Domains management. It creates the virtual inputs used by QEMU (keyboard, mouse and touch), creates the XEN configuration files for the Domains, and starts the Domains. -
Safecor inputs proxyis a proxy that filters and copies the inputs data between the Domains and the physical inputs (keyboard, mouse and touch). -
Safecor core controlleris the core controller for shared services (monitoring, sensors, ...). -
Xorgis the window management software that handles the display. It shows the display of the active GUI Domain. -
QEMUis one of the XEN's backends that provides virtual devices like disks, 9p shares, virtual PCI and GPU devices, etc. -
XEN backendis a XEN embedded mechanism (blkfront, blkback) that handles some of the virtual disks (cdrom, disk image).
Each Domain starts with the following devices:
- a boot CDROM containing the vanilla Alpine Linux image.
- a config CDROM containing an apkovl file with the Domain configuration (host name, packages to install, ...).
- a 9p share with the local Alpine repository.
- a 9p share with the local storage.
- a virtual serial port (pv channel) used for the messaging.
If the Domain has a GUI, the following devices are added:
- a virtual keyboard
- a virtual mouse
- a virtual touchscreen
For the Domains, the storage is a share they can use to store files that will be available to other Domains.
There are different use cases related to this feature:
- The Domain produces data that are too big to remain in the Domain allocated memory.
- Domains need to exchange files. Currently there is no direct connection between the Domains for file copy, the only possibility is to use the system's storage. There are plans to add a direct link between Domains and configure it in the Topology.
The local storage is an image file created during the system boot and destroyed during the system shutdown. The image file is ciphered with a strong ephemeral encryption key randomly created during the boot. The key is not written on the disk neither it remains in memory. After the image disk is created and the cipher facility is initialized, the disk is mounted in the Domain0 and the mount point is shared with the other Domains (see the User Domain architecture).
When the system is provisioned, the local storage is created in /usr/lib/safecor/packages. It contains all the product's packages and their dependencies (only Alpine packages).
After all the packages are downloaded into the repository it is signed with a local key. Hence the local storage is protected with a local key specific to a each setup.
Installed packages:
safecor-core
This Domain is in charge of booting the whole system and orchestrating the creation and destruction of the Domains. It contains all the logic of the system that is deployed by the package safecor-core.
The Domain Driver sys-usb is a DomU dedicated to the USB interface. This component is the key element of the security towards threats coming from USB peripherals. See the security strategy for more information.
Installed packages:
safecor-sys-usb
The sys-usb Domain provides the following functions via a special data channel:
- keyboard input
- mouse position
- mouse button states
- touch position
- reading the file catalog from a USB device
- reading a file from a USB device
- writing a file to a USB device
- mounting a virtual storage file (ISO, vmdk, etc)
This Domain is currently not available.
All the product's components are deployed in User Domains.
A user Domain is a simple virtual machine running in the system's memory. It is created during the system's boot, its packets are installed in memory and the whole Domain is destroyed when the system is shutdown or on-demand (see Protocol).
In a Domain, the root mount point / is a tmpfs, which means a RAM disk, all the files it contains will disappear when the Domain is destroyed.
There can be additionnal virtual disks attached to the Domain, depending on its configuration (see Topology):
- A swap disk that can be used to improve the Domain's performance with a better memory page management. The swap disk consists in an image file that is created in the Domain0 just before the Domain start. The image is attached to the Domain and automatically mounted (the package
safecor-domu-basehas to be installed). When the Domain is detroyed, the image file is automatically detroyed. - A temporary disk that can be used to allocate more temporary disk space (mounted on
/tmp) for application that need it. Temporary disk is used by many applications to create temporary files that are removed at the end of the process. The temporary disk avoids these temporary files to saturate the Domain's memory.
Also there are shared that are automatically attached and mounted in the Domain:
-
The local storage is mounted on
/mnt/storage. - The Alpine packages local repository is mounted on
/mnt/packages.
The platform includes the following virtual machines:
| Name | Description | Trust Level |
|---|---|---|
| Dom0 | Domain 0 is a special virtual machine used to manage user Domains and interface with the XenBus. | High |
| sys-usb | This Domain is responsible for managing USB devices (keyboard, mouse, storage devices) and isolating them from the rest of the system. | Low |
The product can display its own contents by declaring a Domain in the topology with the value has_gui=1.
Since version 3.1 there can be multiple GUI Domains that can be switched using a simple message (see Protocol).
There is only one active Domain GUI. This Domain is said to have the focus.
Each GUI Domain produces its content on a virtual graphical display. The Safecor core controller manages the different displays so that only one is visible in fullscreen in the GTK window created by QEMU on XOrg.
A GUI Domain should install the package safecor-gui-base in order to have a fully capable display with a Cirrus VGA graphics card driver. This package installs an XOrg server in the Domain and configures it with the correct display orientation and size.
If the package safecor-gui-base is not used, the display will only use the Linux framebuffer.