Le défi d’un utilisateur BSD avec Alpine Linux

• Histoire d’Alpine Linux

  • Alpine Linux est une distribution Linux généraliste, indépendante et non commerciale, conçue pour les utilisateurs avancés qui accordent de l’importance à la sécurité, à la simplicité et à l’efficacité des ressources
  • Tous les binaires userland sont compilés en PIE (Position Independent Executables) et bénéficient d’une protection contre le stack smashing, ce qui permet de prévenir à l’avance toute une classe d’exploits, y compris liés à des vulnérabilités zero-day
  • En 2005, Natanael Copa a commencé à discuter du lancement du projet, et comme BSD, Alpine est utilisé aussi bien sur des systèmes embarqués, des routeurs et des appareils mobiles que sur des serveurs généralistes et des postes de travail
  • Grâce à sa taille compacte et à ses dépendances limitées, il est aussi populaire comme base pour les conteneurs Linux
  • Un toolchain facile à exécuter dans chroot(8) est également fourni, ce qui le rend intéressant pour ceux qui utilisent largement les chroots(8) de NetBSD et les jails de FreeBSD

• Installation d’Alpine Linux

  • Il est proposé en plusieurs variantes, avec des builds pour ARM, PPC64, x86 et x86_64
  • Le processus d’installation est très simple : il suffit de se connecter en root dans l’environnement live puis d’exécuter setup-alpine
  • On répond à des questions de base sur le keymap, le réseau, le fuseau horaire, l’authentification root, etc., et il est même possible d’injecter des clés SSH dès le départ, ce qui est utile pour déployer des VM ou des ensembles de serveurs avec des outils d’orchestration, ou chez des hébergeurs qui ne fournissent pas de média
  • On peut choisir parmi plusieurs serveurs SSH et clients NTP, notamment l’OpenSSH préféré de l’auteur et openntpd, et le système identifie correctement qu’il tourne sous Xen
  • Il est aussi possible de configurer LVM, mais pour l’instant Alpine conserve sa partition standard sys en ext4

• Exploration après l’installation

  • Au premier démarrage d’Alpine, on comprend immédiatement une raison particulière : dmesg(1) indique qu’OpenRC est en cours d’exécution
  • C’est portable, petit, rapide, efficace, transparent et sûr
  • Cela paraît très familier aux utilisateurs BSD habitués à écrire des scripts rc
  • La présence de /etc/rc.conf et de crond(8) fait plaisir
  • Voir cela utilisé dans des distributions Linux comme Devuan, Gentoo ou Alpine est très réjouissant, et cela rend Linux à nouveau amusant
  • Avec OpenRC, musl et busybox sont fournis en bundle, ce qui réduit encore la taille du système de base et sa surface d’attaque
  • llvm est disponible, tout comme l’un des shells interactifs préférés de l’auteur, le MirBSD Korn Shell

• Paquets

  • Le gestionnaire de paquets par défaut d’Alpine est apk, et comme c’est courant sur Linux, il gère les mises à jour sans distinguer le système de base des autres paquets
  • L’auteur aimerait vérifier, comme sur BSD, s’il est possible d’exécuter une copie non privilégiée, mais ne l’a pas encore confirmé ; cela dit, pkgsrc est aussi disponible, donc ce n’est pas un problème
  • La configuration se trouve dans /etc/apk/repositories, et il est possible d’activer le dépôt community en décommentant la seconde URL fournie par l’installateur
  • Alpine dispose aussi d’un dépôt testing, et il est possible d’ajouter ses propres dépôts
  • L’utilisation est simple, mais par vieille habitude l’auteur tape encore par erreur apt install au lieu de apk add
  • Une interface web officielle existe, et les dépôts Alpine sont référencés sur pkgs.org
  • Le paquet zfs est ce qui l’a le plus surpris : il n’a fallu que deux commandes pour installer et charger le module noyau (même si faire tourner le root sur ZFS serait plus complexe)

• Conclusion

  • Ce n’est encore qu’un survol, mais il y a déjà suffisamment de bonnes raisons pour envisager sérieusement d’en faire sa principale distribution Linux pour les tests et les serveurs
  • L’auteur apprécie le fait que htop(1) et lsof(1) n’affichent qu’une petite liste de processus reconnaissables, qu’OpenRC soit utilisé, que la gestion des paquets semble simple, et que la configuration soit très épurée
  • Il se demandait à quoi pourrait ressembler un « Linux d’Occam » moderne et fonctionnel, et c’est exactement cela
  • S’il faut davantage que busybox, l’auteur aimerait voir si uutils fonctionne, même s’il en doute pour un serveur

L’avis de GN⁺

• Alpine Linux est optimisé pour les déploiements basés sur des conteneurs, et il est largement utilisé sur des plateformes de conteneurs comme Docker. C’est une distribution à envisager lors de la mise en œuvre d’architectures microservices s’appuyant sur les conteneurs.

• L’utilisation de musl libc par défaut peut être à la fois un avantage et un inconvénient. musl est plus léger que glibc et présente des atouts en matière de sécurité, mais peut poser des problèmes de compatibilité avec certaines applications. Il est donc préférable de vérifier à l’avance la compatibilité des applications visées.

• L’utilisation de ash comme shell par défaut est également un point particulier. ash offre moins de fonctionnalités que bash, mais c’est un shell très léger et rapide, utile dans des environnements à ressources limitées comme les systèmes embarqués. En revanche, cela peut être un peu moins confortable pour l’utilisateur général.

• Pour les personnes qui utilisent principalement des OS de la famille BSD, Alpine Linux peut sembler attrayant car il fournit un environnement familier. En revanche, la prise en charge de l’environnement de bureau semble encore insuffisante, ce qui en fait une option plus adaptée aux usages serveur ou embarqués.

• Dans l’ensemble, Alpine Linux semble avoir une vraie place en tant que distribution légère et optimisée pour la sécurité. Il faut toutefois garder à l’esprit que son écosystème reste relativement limité, et que le support communautaire peut donc être un peu insuffisant en cas de problème. Mais avec le temps, on peut s’attendre à ce qu’Alpine Linux attire de plus en plus d’utilisateurs grâce à ses atouts.

[GN⁺]

Avis sur Hacker News

Résumé :

• Les binaires Linux sont compilés en PIE (Position Independent Executable), ce qui améliore la sécurité

• GLIBC dispose de l’implémentation du tas la plus durcie, avec davantage de mécanismes d’atténuation contre les vulnérabilités du tas comme le double free

• Alpine utilise musl, donc sa sécurité est inférieure à celle de GLIBC. Un système petit et facile à comprendre aide toutefois la sécurité

• Illumos (OpenSolaris) devient plus simple sur tous les plans après des décennies d’utilisation de Linux

• La plupart de ce qui fonctionnait sur Solaris 10 reste applicable aujourd’hui avec quelques légères modifications

• Les zones sont 10 fois supérieures aux conteneurs Docker, avec prise en charge intégrée de ZFS

• Gestion des services avec SMF. Le seul inconvénient est la configuration en XML

• Partage d’expérience sur l’utilisation de serveurs OmniOS et SmartOS

• En tant qu’utilisateur de BSD, premier essai d’Alpine dans bhyve

• Grâce à sa base busybox, les utilitaires de /bin et /sbin n’ont pas besoin d’être des binaires séparés, ce qui réduit l’espace utilisateur et accélère le démarrage

• Avec tmux et zsh, c’est suffisant pour la plupart des usages Unix

• Il a fallu installer beaucoup de paquets apk, mais dans l’ensemble c’était la meilleure expérience Linux jusqu’ici

• Ce serait bien d’avoir ZFS intégré et la prise en charge des bindings virtio pour bhyve

• Void Linux est aussi recommandé aux utilisateurs BSD. Créé par un développeur NetBSD, il existe en versions glibc et musl. Il utilise runit comme système d’init

• xbps-src permet de compiler des paquets depuis les sources

• L’absence de pages man par défaut dans Alpine dissuade de l’utiliser

• Quelqu’un se demande s’il existe une option pour installer automatiquement la documentation lors de l’installation des paquets

• Il y a eu des billets sur les performances d’Alpine dans Docker. Recommandation d’utiliser Debian/Ubuntu

  • Pourquoi Alpine est plus lent : baisse des performances de Python, 50 % plus lent qu’une image Ubuntu
  • Billet en défense d’Alpine : benchmark comparatif avec Debian

• Certains se demandent si cela est toujours d’actualité

• On ne voit pas bien ce qui rend OpenRC et consorts attractifs. Les options basées sur la supervision semblent préférables à la gestion par fichiers PID

• On reconnaît toutefois que l’absence de redémarrage automatique peut être un avantage

• La forte dépendance à syslog relève aussi d’une technologie des années 80

• Accord sur la nécessité d’améliorer une vue centralisée pour connaître l’ordre des événements entre plusieurs outils

• Avantage d’Alpine : gestion déclarative des paquets possible sans Nix en modifiant /etc/apk/world, puis avec apk fix

• Slackware est un compromis entre BSD et Linux. C’est Unix-like sans être complexe. Slackbuilds fournit un arbre de ports riche

• musl ne prend pas en charge pthread_attr_setaffinity_np, ce qui empêche l’exécution de certains logiciels comme PyTorch