CLIP OS is a GNU/Linux meta-distribution designed with the following hypotheses in mind:
- everyone (developer, administrator, end user) is fallible and can commit hazardous actions by mistake;
- all code can contain vulnerabilities, which means that we must take into account the threat, minimize it (e.g., shrink the attack surface), identify potential residual vulnerabilities, and be able to deploy over-the-air updates;
- only trusted code should be executable (no arbitrary code execution nor persistence);
- we consider that there are multiple administrator roles, according to organizational measures or to limit privileges available to one person;
- the system can have multiple authorized users;
- the system can be connected to untrusted networks (e.g., in a road warrior environment);
- log events should be available to detect attacks or misbehavior;
- and multiple user environments can manage data of different sensitivities: low (e.g., Internet) and high (private network).
To achieve these requirements, CLIP OS provides multiple security enhancements such as process isolation, tailored permission model, and multiple hardening developments deeply integrated into the system. There are currently two main use cases to the CLIP OS project, each one provided by a dedicated CLIP OS species: an end user system targeting common office tasks, and a VPN gateway.
CLIP OS started in 2005 and is now publicly developed with the version 5. This version 4 of CLIP OS is not intended to be used as is. Some packages may be missing and others may be incomplete because of the initial publication process. However, as for the version 5, you are free to pick any components or patches (according to their license terms) that may fit your needs.
CLIP OS is based on Gentoo Hardened, which comes with a hardened toolchain and multiple security enhancements. Thus the package manager on the developer side is Portage, but the resulting builds for a CLIP OS distribution are shipped with Debian packages thanks to a custom wrapper. Two signatures, with a CLIP OS-specific format, are appended to each Debian package: one for the developer and another for a controller, thus allowing a two-level sign-off on every update. The update mechanism is fully automated and run in the background in a dedicated VServer container. The critical system components (e.g., kernel, update mechanism, user management, network configuration, etc.) are updated following the A/B update principle with two different partition sets updated alternatively. This ensures that the system remains bootable and recoverable if a critical update fails or is interrupted. An on-the-fly update can be applied for non-critical components (e.g., user applications), thus not requiring a reboot for minor updates but still being able to automatically rollback if an error occurs.
Multiple packages are patched to fit the needs of CLIP OS. These modifications can be found in portage-overlay (identified with USE flags), and custom (and imported) developments are packaged in portage-overlay-clip. The related sources are listed in the Repo manifest.
CLIP OS uses a lot of containers (internally called jails), following the defense in depth principle, thanks to Linux-VServer features.
Linux-VServer is a kernel patch which leverages Linux namespaces to create secure partitioning of processes.
Among other things, it allows to tag processes, resources and networks with context identifiers (XIDs) and network identifiers (NIDs).
It also adds a local network per jail (with no NIC), PTS restrictions, multiple /proc visibility restrictions, WATCH (audit) and ADMIN roles, reduces covert channels, and adds multilevel restrictions.
CLIP OS does not use the upstream VServer userspace tools but a minimal and security-focused vsctl.
A sample jail configuration can be found for a user jail or a web server jail.
Multiple jail layouts, mostly read-only, are used for system services. The content of each jail is minimal to reduce the tools available to attackers (e.g., BusyBox). Communications between jails are handled through secure IPC (e.g., UNIX sockets or SSH on the local loop). Firewall rules control all network accesses (e.g., local loop, Ethernet, Wi-Fi, UMTS, etc.). Moreover, critical services are hardened with custom patches: strongSwan, Syslog-NG, DHCP client, Nginx, etc.
To help create these containers and reduce privileges, CLIP OS provides libraries of security helpers: clip-lib (secure privilege management) and clip-libvserver (container management).
CLIP-LSM is a custom Linux Security Module enhancing the Linux permission model (capabilities), adding extra VServer permissions (e.g., IPsec enforcement) and leveraging hardening features from PaX and grsecurity. Multiple other Linux patches fix some issues and add miscellaneous security features.
Root and kernel-spawned processes are restricted through an extra capability bounding set, a limited enforcement of root setuid bits and a strict Trusted Path Execution.
Devctl is a mechanism providing extended device access control, e.g., to lock security-relevant mount options, and enforce mandatory device and mount access control (read, write and execute).
Veriexec is a simple right management system (inspired from NetBSD) which also checks files integrity. The configuration is independent from the target file(-system) and enables easy on-the-fly updates thanks to the verictl tool. Veriexec handles extra rights per jail, either to add extra access control for operations which are allowed by default on a vanilla kernel (e.g., network access or specific IPsec-related operations), or provide a limited way to allow certain operations that usually require extensive capabilities (e.g., kernel log access). It is also in charge of granting some permission to scripts, according to a composition of effective, inherited and permissive flags.
One of the basic principles of CLIP OS is the enforcement of a "write xor execute" policy, both at the memory management level and with regards to filesystem access rights.
This means that a process should not be allowed to execute something not provided by the system, thus avoiding arbitrary code execution and persistent attacks.
The main goal is to protect the kernel by restricting arbitrary syscalls that an attacker could perform with a crafted binary or certain script languages.
It also improves the multilevel isolation by reducing the ability of an attacker to use side channels with specific code.
These restrictions can natively be enforced for ELF binaries (with the noexec mount option) but require a kernel patch to properly handle scripts (e.g., Python, Perl).
A new open flag (O_MAYEXEC) is then used by modified interpreters.
Since the chroot syscall is used as a secondary isolation mechanism, to further isolate some processes within a given VServer container, some extra restrictions on chroot are also enforced: FD leak and access safeguards, ptrace restrictions, integration with grsecurity and VServer, etc.
CLIP OS can be used as a multilevel operating system, which helps handle data of different sensitivities on the same system, and can limit data leak.
The end user can use two desktop environments: a low level (called RM_B) connected to Internet and a high level (called RM_H) to deal with sensitive data, only accessible through a VPN (IPsec).
Each environment contains usual applications (e.g., web browser, office suite, graphic software) which are confined to their assigned level (e.g., network, files, GUI).
Multiple components must be aware of this security model, enforce it, and enable the end user to manage multiple levels:
- display levels to user (window manager and trusted panel);
- secure and trusted GUI isolation (GUI domains and VNC viewers);
- black and red diodes (cryptd and cryptclt) to push or decrypt files from the low to the high level (following the Bell-LaPadula model), or encrypt files from the high to the low level;
- VServer levels;
- external mass storage signature and data encryption;
- and multilevel smartcard proxy.
CLIP OS can also handle external devices per jail: a scanner, a printer, a webcam, a sound card and a smartcard.
A CLIP OS user account can be configured with a composition of privileged roles: administrator (admin) and auditor (audit).
It is important to note that the privilege delegation for these roles is not based on granting partial or total root privileges (i.e. no sudo or equivalent), but on read and/or write access to specific configuration files within the VServer container dedicated to each role.
Modified configuration files are then securely parsed, and applied if valid, by privileged daemons outside of those containers.
The goal of the admin role is to configure the system. However, such a role must not be able to tamper with the system nor to access other user's data. CLIP OS is designed to grant these accesses to the administrator:
- devices visibility management;
- time and date configuration;
- user management (userd);
- networking and IPsec management (clip-netd);
- display configuration;
- optional packages (e.g., user applications) installation and uninstallation;
- and system update configuration (downloadrequest), but not package signature authorities.
The audit role is used to gather information from the system, but without the ability to access any configuration not related to system logs. Log events are only accessible to this role, but in a read-only way. Log management (e.g., storage limits, remote transfers) is exclusively allowed to the audit role.
These roles can be used through dedicated GUIs (e.g., clip-config), or CLIs and files. This may be available locally by a logged user, or through a dedicated VPN via an SSH session.
We use a hardened system password manager (PAM tcb from Openwall) with the bcrypt hashing algorithm. On embedded devices, users are automatically jailed in the appropriate VServer container when logging in on the command line, through the PAM jail module, while on desktop environments, similar jailing is enforced by the graphical login interface. User's data is stored on dedicated encrypted partitions. There is one partition per user environment: the core system, the low level and the high level. User partition devices are automatically open, decrypted and mounted (in their dedicated jail) when the user logs in. The secret key used for the related cryptographic operations is derived from a password or decrypted by a smartcard. Finally, the partition is unmounted and closed when the user session is closed.
A smartcard can be used simultaneously for user authentication and in multiple isolated environments at the same time thanks to Caml Crush and multiple dedicated jails. Smartcard management is handled through multiple packages: ckiutl, smartcard-monitor, a scdaemon-like (PGP), etc.
Even if the system partition set can be encrypted and an early stage development for TPM support is present (e.g., tpm-cmd, clip-livecd, clip-kernel and syslinux-tpm-patches), CLIP OS 4 does not include physical tampering in its threat model. This is one of the main reasons for a 5th version of CLIP OS, not upgradable from the 4th one.
Multiple IPsec VPNs can be established by a client: high level network, update network, admin network and audit network. A CLIP OS gateway and a dedicated PKI can be set up to handle CLIP OS clients and their networks.
To avoid common entropy issues, a kernel patch and a userspace daemon feed the PRNG.
CLIP OS also provides user tools such as a simplified and hardened PKI management tool: ANSSI-PKI.
The main public talk about CLIP OS 4 was given at the SSTIC conference in 2015.
This repository contains a selection of the initial documents in French targeting multiple audiences: end users, administrators and developers.
- Le changement de mot de passe dans CLIP
- Écran étendu
- KRDC
- Échanger des documents entre les deux niveaux de CLIP
- Guide de démarrage du client CLIP
- Clés USB
- Administration en ligne de commande d'une passerelle CLIP
- Mise en place de l'administration à distance des passerelles CLIP
- Configuration DNS d'un poste CLIP
- Pare-feu
- Fichier resolv.conf
- Effacement manuel d'un poste bureautique CLIP
- Guide d'utilisation d'une passerelle CLIP
- Installation de CLIP
- Rôle et gestion des certificats dans CLIP
- Description Générale
- Description Fonctionnelle
- Architecture de sécurité
- Paquetages CLIP
- Support de l'UEFI
- Génération de paquetages
- Génération d'un support d'installation CLIP
- Guide d'installation de l'environnement de développement
- CLIP-LSM
- Patch VServer
- PaX & grsecurity
- Privilèges Linux
- Générateur d'aléa noyau
- Séquences de démarrage et d'arrêt
- Authentification locale
- X11 et cloisonnement graphique
- Cages et socle CLIP
- Support des cartes à puce sous CLIP
- TPM
- Cages RM
- Configuration Réseau
- Installation CLIP
- Guide de l'utilisateur CLIP-RM
- Guide de création de paquetage
Copyright © 2018 ANSSI.
CLIP OS is a trademark of the French Republic. As a consequence, any use of the name "CLIP OS" has to be first authorized by the ANSSI. This does not preclude changes to the software posted online and their republication or quotation from identifying the original software under the terms of the LGPL v2.1+ license. Regardless, no use of the name "CLIP OS" on a modified version should suggest that this version is the original work published by the ANSSI.
The contents of this documentation is available under the Open License version 2.0 (compatible with the CC-BY license) as published by Etalab (French task force for Open Data).