Ce blog a pour objectif de présenter, de manière simple et concise, différents concepts liés au monde associatif, ainsi que des techniques et notions informatiques.

Les articles sont volontairement courts afin de proposer une lecture rapide et accessible, tout en allant à l’essentiel.

Si vous souhaitez voir un concept particulier abordé sur le blog, n’hésitez pas à me contacter à l’adresse suivante : contact@ethiciel.org.

Ce blog est généré par un petit programme C qui lit un flux atom et le transforme grâce à une feuille XSLT en HTML, markdown. Il gère aussi le format PDF mais en générant un fichier HTML par XSLT et en le convertissant en PDF (XSLT-FO aurait pu être utilisé mais cette option ne s'est pas imposée comme une évidence en C).

Linux repose largement sur un modèle permissif : un processus autorisé peut lancer d’autres binaires via execve.

SELinux, AppArmor, namespaces et conteneurs réduisent ces risques, mais au prix d’une configuration complexe. D’où l’idée d’un Linux « restrictif par défaut » : exécuté sur des ressources applicatives en liste blanche.

Aucun POC ni vérification du code noyau Linux n'ont été opérés pour le moment. Cette affirmation est basée uniquement sur l'existance de la fonction execve dans le noyau. Fonction qui est utilisé par plusieurs prototypes de fonctions glibc.

Plusieurs mécanismes dans le noyau et en dehors du noyau tentent de répondre à la maîtrise des ressources attribuées aux processus Linux. Néanmoins, les failles récentes sur SUDO mais aussi BASH il y a quelques années, ont démontré que le système attend sûrement un autre schéma de raisonnement pour rendre plus sûr le système Linux.

L'escalade permise par toute compromission d'une application ou d'un démon root pourrait être contrainte par l'application de règles défensives. Un programme qui n'a pas de raison d'accéder à execve qu'il soit lancé ou non par root devrait pouvoir déclarer de façon signé qu'il ne peut pas le faire pour éviter tout dérrapage.

L’atomicité des opérations de transfert de fichiers, notamment via mv/rename ou un cp dans un répertoire temporaire suivi d’un renommage atomique, facilite le retour en arrière : une modification est appliquée entièrement ou pas du tout. Ce retour en arrière après un ctrl-break par exemple ne peut pas s’appliquer de façon atomique si l’opération traverse plusieurs filesystems. Un répertoire temporaire pour la copie de données devrait être disponible pour chaque partition.

Et si votre shell ne se contentait plus d’exécuter des commandes, mais aidait à les comprendre avant validation ?

L’idée : décrire chaque commande par une grammaire et proposer une auto-complétion sur les arguments avec aide contextuelle sur leur utilisation ou accès au man grâce à la touche <TAB>, proposer une complétion contextuelle navigable, filtrer fichiers wildcardés (en sélectionnant ceux que l'on veut vraiment dans la ligne de commande), sélectionner le <PID>, <UID> ou <GID> ou <DEV> après une option qui nécessite un PID, UID ou GID, ou devices selon les droits, explorer le filesystem quand l'option attend <FILE> | <DIR>, rechercher l’historique par regexp et construire un AST sémantique pour évaluer par sa résolution l'acceptabilité de l'opération selon le mode activé (défensif ou non défensif).

Un mode défensif pourrait alors simuler cp, mv ou rm, estimer espace et atomicité, détecter les risques également liés aux permissions et proposer retour en arrière, corbeille ou transaction avant exécution.

Ce projet d'extension de shell semble assez complexe à réaliser, cela demanderait sûrement le codage de nouvelles versions des commandes unix pour qu'elles répondent au schéma défensif proposé. Néanmoins le shell peut être étendu pour aider et guider l'administrateur ou l'utilisateur standard à saisir des commandes sans erreur de saisie si les options de toutes les commandes accessibles peuvent être définies dans une grammaire pour chacune d'elles.

Et si l’email redevenait local ?

Ce projet imagine une messagerie où les fournisseurs d'emails ne servent plus qu’au transport. Les messages sont récupérés, chiffrés, stockés, signés et répliqués sur les appareils de l’utilisateur grâce par exemple à des serveurs de stockage sécurisés.

L’antispam repose sur une confiance mutuelle via invitations mutuelle signées. L'application mail utiliserait SMTP/POP3, stockage .eml, chiffrement et synchronisation.

Ce projet n'a pas encore fait l'objet d'un poc. Ce qui est vraiment important et intéressant, c'est l'espace de stockage local-first et signé par PGP/GPG, distribué et synchronisé sur téléphones, tablettes, ordinateurs à partir d'un protocole open source sécurisé par ssh et multiplateformes (sftp,scp ?).

VTTK (View & Terminal ToolKit) propose un raisonnement méta ou des algorithmes aux propriétés connexes pour tous les types et tailles d'écran capables d’adapter automatiquement une application GTK, Qt ou Slint au terminal, au type et à la taille d’écran disponible, sans modifier son API et ainsi, si possible, maintenir la compatibilité ABI avec les versions Gtk, QT et Slint actuelles.

Pour la plupart des composants de saisie standards, ce n'est pas une question de taille d'écran mais une question de présentation de la saisie des informations. Ce que l'on peut saisir sur un grand écran peut l'être également sur un petit écran en une ou plusieurs étapes/écrans car, généralement, il a des dimensions aujourd'hui assez acceptables pour les ordiphones qui ont quelques années.

Certaines applications comme les éditeurs audio pourrait demander un affichage en mande paysage plutôt que portrait sur mobile. Cette difficulté reste à adresser.

Ce projet a fait l'objet d'un POC sur Gtk4. Il a prouvé qu'une interception des ABI GTK4 était possible sur des composants graphiques permettant ainsi de gérer une sortie text/readline, text/tui, graphic/wayland, w3c/text et w3c/graphic de façon complètement transparente à l'application tant que l'interprétation de la représentation des composants graphiques est possible dans les contraintes de la sortie d'écran visée.

Si la sortie d'écran possède des limitations sémantiques pour les composants à afficher, une erreur peut être remontée. Par exemple, une carte géographique ou une image peut difficilement prendre place en mode texte. Mais un grand nombre d'adaptations sont possibles pour les saisies diverses et variées soit en un écran soit en plusieurs écrans.

Linux permet de créer des fichiers contenant des systèmes de fichiers, avec une taille physique parfois inférieure à leur taille virtuelle. L'image fichier contenant un système de fichiers serait un classique : /etc, /usr, /var, /var/data, /tmp possiblement sur le même système. Une application et ses données dans un seul espace utilisateur deviendraient alors un objet portable unique, déplaçable d’un disque local ou réseau à un autre par un simple mv ou cp d'un seul fichier.

Il pourrait même devenir multiplateformes grâce à l'utilisation de Podman qui permettrait de conteneuriser l'application sous Linux ou de la démarrer dans une VM sous MacOS et Windows même si elle présente du code compatible Linux.

Grâce à l'utilisation d'un ISO Live Linux sur une clé USB, on pourrait obtenir une application portable en quelques minutes sous contraintes de pouvoir démarrer un système OS externe (sur clé USB) sur l'ordinateur cible. Cela demande aujourd'hui l'accès à l'interface de paramétrage de la machine. Il faut généralement quelques connaissances techniques pour y arriver.

Un shell en dessous de la barre de manu en langage naturel pourrait devenir une interface universelle pour piloter les applications. Chaque logiciel exposerait son état et ses fonctions sous forme d’actions, getters, setters et structures de contrôle, décrites par une grammaire extensible qui, une fois parsée, génèrerait un arbre AST sémantique.

Des plugins validés par la gouvernance du projet ajouteraient actions, transformations, menus, suite de tests, suite de performance et traitements batch. Les commandes seraient traduites en AST puis en Python avec import API lib C applicative et interprété ou C et compilé, afin d’automatiser des workflows, partager des macros et créer des standards ouverts entre applications.

Enfin, le système shell pourrait être la somme de toutes les extensions applicatives et pourrait permettre d'exécuter des choses du genre :

		kdenlive(
			fais-moi un short à partir du projet toto 
			pour Pixelfed et téléverse-le sur mon compte laurent
		)
		

Ce projet n'a pas fait l'objet d'un POC spécifique englobant tous ses aspects mais la réunion de plusieurs grammaires BNF a été testée avec succès. Il a aussi été vérifié que l'extension d'une application par l'utilisation d'une lib chargée dynamiquement est possible si le programme Linux ELF le permet (firefox est statique et ne le permet donc pas par exemple).