Archives par étiquette : ubuntu

Linux : run0 ou la fin programmée de sudo ?

Pendant des décennies, la commande sudo a été la clé de voûte de l’administration des systèmes Unix et Linux, un passage obligé pour les administrateurs souhaitant effectuer des opérations privilégiées. Cependant, un vent de changement souffle sur l’écosystème Linux. Des annonces récentes et des décisions majeures de la part de distributions influentes comme Fedora et Ubuntu laissent entrevoir la disparition programmée de sudo au profit de nouvelles alternatives plus modernes et sécurisées. Le leader de cette révolution n’est autre que run0, un outil intégré à systemd qui promet de redéfinir notre rapport aux privilèges système.

Le talon d’Achille de sudo: une question de conception

Pour comprendre ce changement, il faut revenir sur la faille fondamentale de sudo. Depuis sa création dans les années 1980, cette commande repose sur un mécanisme ancien et risqué : le bit setuid.

Le problème est que sudo est un binaire appartenant à root avec le bit setuid activé (rws). Cela signifie qu’un utilisateur standard, en exécutant sudo, voit le processus s’exécuter avec les droits de root. Si le binaire présente des défauts, un attaquant peut injecter une exploitation qui sera alors exécutée avec les droits root.

La surface d’attaque de sudo est également pointée du doigt. Avec plus de 100 000 lignes de code (presque 150 000 lignes, ce qui peut étonner car basiquement sudo effectue un fork+exec, fonctionnalité qui peut s’écrire en moins de 100 lignes de code en langage C), la marge d’erreur est considérable. Cet héritage des débuts d’Unix est aujourd’hui perçu par de nombreux experts comme une anomalie : « SUID est un concept très étrange. Dans mon monde idéal, nous aurions un système d’exploitation qui n’utilise pas du tout SUID ».

run0: la réponse de systemd

Continuer la lecture

Créer et gérer son miroir local des dépôts officiels Ubuntu

La mise en place d’un dépôt personnel, ou miroir local, des dépôts officiels Ubuntu est une pratique d’administration système qui consiste à cloner tout ou partie des dépôts de paquets sur un serveur situé sur le réseau local. L’objectif est de centraliser les sources de mise à jour et d’installation pour l’ensemble des machines d’un parc informatique.

L’un des intérêts majeurs d’un miroir local est l’optimisation de l’utilisation de la bande passante et le gain de temps. Dans un environnement où plusieurs machines doivent être mises à jour, chaque serveur ou poste de travail télécharge individuellement les mêmes paquets depuis les serveurs publics d’Ubuntu, ce qui entraîne une duplication massive des données .

En installant un miroir local, les téléchargements depuis l’extérieur ne sont effectués qu’une seule fois, lors de la synchronisation du miroir avec les dépôts officiels. Toutes les autres machines du réseau se servent ensuite de ce miroir, via le réseau local, pour obtenir leurs paquets . La vitesse de transfert sur un réseau local (par exemple, via Ethernet ou Wi-Fi) est en effet bien supérieure aux débits offerts par une connexion internet, ce qui rend les installations et les mises à jour quasi instantanées .

La mise en place d’un miroir local offre une indépendance vis-à-vis de la connexion internet. Dans des environnements où l’accès à internet est limité, instable ou inexistant, comme les laboratoires, les salles de classe ou les réseaux industriels, le miroir devient une ressource essentielle . Les machines peuvent continuer à s’installer, se mettre à jour et fonctionner normalement même en cas de panne de la connexion internet ou d’indisponibilité des serveurs officiels . Cette autonomie garantit la continuité des opérations dans des environnements critiques .

Pour les administrateurs système, un miroir local est un outil de contrôle puissant. En ne synchronisant que les dépôts et les composants sélectionnés, l’administrateur garde la main sur les versions des paquets disponibles pour ses utilisateurs . Il est ainsi possible de geler un environnement à un instant T, de tester les mises à jour de sécurité sur un petit nombre de machines avant un déploiement plus large, ou de garantir que toutes les machines d’un parc utilisent une version identique d’un paquet donné . En pratique, l’administrateur modifie le fichier /etc/apt/mirror.list pour ne retenir que les dépôts pertinents (par exemple, en ne conservant que la branche security pour les mises à jour de sécurité) .

Voici un tutoriel détaillé expliquant comment créer, utiliser et entretenir un miroir de dépôt Ubuntu.

Continuer la lecture