-
Notifications
You must be signed in to change notification settings - Fork 0
Security
This page deals with security in the system and best practices to make a secure system.
The security strategy relies on some key design concepts:
- Isolation: the components of the system are separated from each other. It means that they belong to their own virtual machine and have no direct contact with the other components. Thus the threats cannot contaminate the whole system.
- Protocol break: the communication between the components use a very simple data protocol with a very low attack surface. An attack from outside the system cannot propagate inside the system using TCP-IP or USB for example as these protocols are confined in their repective components (sys-usb, sys-net, ...) and the data flow uses another data protocol and channel.
- Collaboration: the components of the system that don't need to manipulate files or external data don't have access to them. Instead, they collaborate with other components to get the information or data they need. This reduces the risk of contaminating the core of the system.
- Simplicity: the architecture of the core is very simple and this simplicity limits configuration or design weaknesses that could be exploited by threats. This is a major design rule.
This section deals with the hardening rules.
The services are executed as a normal user (without privilege). The user root is never be used for any service nor application in the system.
Each service is associated with its own user and belongs to the group safecor.
Its configuration files and the files it creates are owned by its user. The file it needs to access but does not own are accessible as long as they belong to the group safecor.
The following rules apply:
- A service is not allowed to list, read or modify the configuration files of another service.
- A service is not allowed to list, read or modify any of the operating system's configuration files.
These rules apply in the Domain0, the Driver Domains and the User Domains. In the product's Domains, designers are encouraged to apply these rules to avoid creating leaks in the system.
The shared contents, like the storage, can be accessed R/W with a user that belongs to the group safecor. The group safecor is added to the Domain by the package safecor-domu-base (see Packages).
In this chapter we analyze the potential data remanence on the system after its usage.
It may concern:
- the files created during the system's usage
- the files read from an external device (USB storage for example)
- the data copied in memory
- the secrets embedded in the system (private keys)
To be completed
Alpine Linux official repository provides cryptographically signed packages. Their signature is embedded inside the package file and the signing keys are managed by the Alpine maintainers.
When a package is installed, each package's signature is verified before installation. The public key is embedded in the system itself.
Unless both maintainers' keys and systems' keys are corrupted it si almost impossible to install a corrupted package.
The product's packages are signed by its own maintainer and he is responsible of the tracability of its package by providing the public key for the signature verification.
When a system based on Safecor is provisionned, a local repository is created with all the packages needed for the Domains creation (see the page Architecture). This local repository is signed with an ephemeral key-pair randomly generated during the provisioning. The key-pair is unique and the private key is removed at the end of the provisioning process.
The public key is embedded into each Domain configuration virtual cdrom (see Architecture) using an APK overlay file (apkovl).
When the Domains boot they verify the signatures of all the packets using the public key of the local repository.
The local storage is an image file created during the system boot and destroyed during it's shutdown.
The image is ciphered before being mounted in the Domain0 and shared with the other Domains including sys-usb. This image is considered as dangerous and a potential source of leaks. That is the reason why it can never be reused.
The ciphering process relies on cryptsetup (LUKS) and a strong ephemeral encryption key (AES-512 XTS) and is randomly generated during the boot of the system. The image file is destroyed when the system is shutdown. In the case the image file persists on the disk it is destroyed on the next boot.
Even if the image file was extracted from the system it could not be deciphered because the (ephemeral) random key used for ciphering is lost as soon as the file has been ciphered and is never written on the disk.