Les systèmes Linux immuables interdisent toute modification persistante de leur cœur. L’approche semble radicale, mais elle renforce en réalité la sécurité des serveurs, ordinateurs et infrastructures cloud contre les cyberattaques.
« Car depuis des décennies, les administrateurs système sont habitués à tout pouvoir modifier en temps réel »
Ça c’est pour les mauvais. Les bons montent la partition root en lecture-seule.
1 « J'aime »
C’est pas un peu gênant le jour où tu dois par exemple étendre ou réorganiser tes partitions ? Tu passes par un boot GParted ?
Le jour où sous Linux il y a une faille zéro day ( il y en a minimum 1 à 2 par an ) tu es dans le baba, tous tes systèmes sont vulnérables de la même manière
Trop de sécurité tue la sécurité
Euh, comment dire… Donc moins de sécurité c’est plus sécurisé ?
C’est pareil avec les systèmes basés sur le même OS, quel que soit l’OS, non ?
1 « J'aime »
Fedora CoreOS est une bonne nouvelle pour les utilisateurs lambda de Fedora parce que les mises à jours fréquentes et partielles peuvent casser le système tous les six mois parce que les pilotes évoluent très vite sans répit. C’est bien de pouvoir se poser et se pauser un peu. C’est aussi pour cela que je suis passé à Debian après de longues années sur Fedora depuis les débuts de RedHat avec SuSE.
2 « J'aime »
Le système bazzite est une distribution de jeu complètement basé sur ce principe, steam os l’est aussi. C’est probablement le futur du jeu vidéo a mon humble avis.
Merci pour le fou rire. 
Donc, le mieux serait de ne prendre aucune mesure ?
Il faut bien avoir en tête justement qu’aucune mesure n’a une efficacité totale et que c’est justement en empilant les mesures de protection que l’on s’en sort.
« Merci pour le fou rire. »
Ce n’est pas toujours faux. Quand ajouter de la sécu te ralenti dans le patching, ça peut être dangereux.
Le choix d’être en immutable est lié à son organisation et son utilisation. Rebuilder un immutable peut prendre du temps.
J’ai utilisé du immutable (ou presque) sur des fermes citrix en rotation constante (destruction et reconstruction de VM), c’est intéressant dans ce genre de cas. Et techniquement, je pouvais injecter un patch quand je voulais, mais normalement il fallait simplement attendre le déploiement progressif.
En cluster c’est bien aussi.
Bref, en datacenter, c’est facilement applicable.
Par contre en entreprise pour certaines charges, tant qu’elles ne sont pas plus virtualisées, c’est pas évident.
Pour rappel, Wimboot sous Windows était presque du immutable, et on peut activer des filtres d’écritures sur n’importe quel windows pour le rendre immutable (reboot = on repart à zéro)
Les immutables peuvent être distribuées signées, ce qui permettra d’activer des fonctionnalités comme les DRM.
Une distro non immutable n’est pas « sûre » car on peut y injecter des pilotes. Une immutable peut être signée par un « tiers de confiance » et à partir de là, les anti-cheat et DRM peuvent obtenir la garantie que les flux des données ne peuvent pas être interceptés niveau du noyau.
C’est un élément de base pour verrouiller nos ordis.
1 « J'aime »
Donc la , si une faille est détectée, la pathétique revient à réinstaller tous le noyaux ?
Déployer un patch va devenir trop difficile
Non, si tu as un patch a installer, ou pour installer de nouvelles applications par exemple, tu introduis une nouvelle version de ton système.
En gros, le principe, c’est que tu empiles les couches (si tu connais Docker, c’est le même principe avec les images Docker), chaque couche étant immutable. Quand le système tourne, le système de fichier que tu vois est l’agrégat de ces couches, et quand un fichier est dans plusieurs couches, tu vois la version de la couche la plus récente. Et il y a en plus une couche « mutable » qui est l’état en direct du système.
À chaque redémarrage, ça repart sur la dernière couche immutable, et toutes les modifications faites dans la couche mutable lors de la session précédente sont perdues.
À tout moment, tu peux faire une action pour « valider » l’état courant de ta couche mutable, pour en faire une nouvelle couche immutable, ce qui permet d’installer des correctifs ou des nouvelles applications.
Et en cas de besoin, tu peux toujours revenir à une couche plus ancienne, l’immutabilité te garanti que ces couches plus anciennes sont conservées et non altérées.
1 « J'aime »
Un zero-day ne veut pas dire système non sécurisé. Par exemple, sur un serveur, des règles comme OWASP Core Rule Set (CRS) peuvent bloquer une grande partie des tentatives avant qu’un correctif existe.
Sur un système immuable, même en cas d’exploitation, l’attaquant peut se heurter à un système en lecture seule. Une éventuelle escalade de privilèges ne permet pas de modifier l’OS, ni d’installer une persistance durable.
1 « J'aime »
Article intéressant,merci !
1 « J'aime »
Tu remontes ta partition en lecture/écriture quand tu veux
Même chose chez, nous reconstruisons nos serveurs citrix toutes les nuits a partir d’un os mis à jour sur lequel on déploie les applicatifs mis à jour par les devs
C’est à dire, via le user root avec un reboot derrière ? C’est un peu lourd niveau maj j’ai l’impression… après je comprends l’intérêt, surtout si derrière tu mets du docker.