Christophe Blaess

Eris Linux offre un socle logiciel maintenu et maîtrisé sur lequel les applications métiers peuvent être exécutées en toute sécurité dans des containers. La mise à jour régulière du socle système est réalisée par nos soins, au gré des correctifs intégrés dans les recettes de Yocto Project et des nécessités liées à la découverte de vulnérabilités comme nous l’avons évoqué dans les précédents articles.

Nous allons mettre à l’épreuve le système de mise de jour d’Eris Linux, en vérifiant sa robustesse dans des circonstances difficiles volontairement provoquées.

Pas de commentaires»

Le suivi des vulnérabilités d’un système embarqué est essentiel. Nous avons vu dans l’article précédent comment analyser les fichiers produits par Yocto Project pour extraire la liste des CVE (Common Vulnerabilities and Exposures) présentes lors d’une production d’image. Nous avions observé que des vulnérabilités étaient en nombre limité pour la plupart des packages, mais qu’un nombre astronomique de CVE étaient mentionné pour le kernel Linux.

Nous allons voir à présent comment filtrer les résultats pour n’avoir à traiter qu’un nombre raisonnable de vulnérabilités.

Pas de commentaires»

Pour faciliter l’analyse des rapports concernant les CVE produits lors d’un build Yocto Project, j’ai développé un petit outil nommé cve-parse. Il permet d’obtenir rapidement une vue d’ensemble des composants d’une image, de consulter les vulnérabilités associées à un composant particulier ou de rechercher directement une CVE.

Dans le précédent article, consacré au Cyber Resilience Act, nous avons vu qu’en cas de découverte d’une vulnérabilité activement exploitée, l’une des premières questions auxquelles le fabricant doit pouvoir répondre est très simple en apparence : mon produit contient-il le composant vulnérable ?

Pas de commentaires»

Imaginons une situation qui, malheureusement, risque de devenir familière aux fabricants de produits connectés.

Mardi matin, 9 h 15. Vous apprenez qu’une vulnérabilité concernant une bibliothèque Open Source utilisée dans votre produit est désormais activement exploitée. (La définition d’activement exploitée, terme utilisé dans le CRA, Cyber Resilience Act, sera détaillée plus bas)

Votre produit est déjà commercialisé. Plusieurs dizaines, centaines voire milliers d’équipements sont installés chez vos clients. Certains sont accessibles par le réseau, d’autres se trouvent derrière une infrastructure protégée. Comment réagir ?

Pas de commentaires»

Une fois l’application métier développée, le container correspondant construit et déployé sur une carte (ou un groupe de cartes) de test, il est souvent nécessaire de passer à une étape moins réjouissante : le debug !

Analyser le comportement d’une application fonctionnant dans un container, s’exécutant lui-même dans une machine distante – qui est prévue pour empêcher toute intrusion pour des raisons de sécurité – est assez compliqué. Toutefois Eris Linux nous propose deux méthodes simples pour suivre l’exécution de notre code applicatif. (D’autres méthodes verront probablement le jour, cet article sera modifié en conséquence quand ce sera le cas).

Pas de commentaires»

Nous venons de publier une nouvelle version de Yocto Cooker (1.6.0) sur PyPi.

Pendant longtemps, Cooker partait du principe que le menu utilisait le repository Poky. Or, ce dépôt n’est plus utilisé pour les branches ultérieures à novembre 2025 (Whinlatter, Wrynose et la future Blacksail).

Il faut désormais s’appuyer sur plusieurs dépôts pour faire un build.

Pas de commentaires»

Nous avons vu dans les articles précédents de cette série :

• en quoi consiste la distribution embarquée industrielle Eris Linux,
• comment installer Eris sur une carte embarquée, en l’occurrence un Raspberry Pi 5,
• comment déployer des containers avec du code de démonstration,
• comment écrire et embarquer des applications dans des containers.

Les applications que l’on embarque sous forme de code « métier » ne sont que très rarement auto-suffisantes. Elles ont souvent besoin de communiquer avec le système sous-jacent pour consulter ou configurer des éléments du système (par exemple le paramétrage réseau, la configuration du watchdog, celle des LEDs etc.)

Pour cela Eris Linux offre une interface de programmation qui permet, depuis l’intérieur d’un container, de communiquer avec le système hôte. En réalité cette API (Application Programming Interface) est déclinée en deux implémentations. Une bibliothèque (liberis) qui peut être employée par les applications compilées (en C ou C++ par exemple) et un service REST accessible pour les langages interprétés (javascript, Python, etc.). Nous avons déjà aperçu des usages de liberis et du service REST pour l’API d’Eris Linux dans l’article précédent.

Pas de commentaires»