L'état du sandboxing dans les logiciels open source

Le sandboxing, c'est une technique qui sert à restreindre comment les applis interagissent avec le système. L'idée, c'est d'empêcher les programmes d'accéder à plus de ressources que ce dont ils ont besoin, en suivant le principe du "moindre privilège". En gros, si une appli a juste besoin de faire quelques trucs, elle ne devrait pas être autorisée à tout faire. Les sandboxes font office de barrières qui limitent ce qu'un programme peut faire, ce qui aide à protéger le système des actions nuisibles.

#Importance du Sandboxing

On peut pas toujours faire confiance aux logiciels pour bien se comporter. Parfois, des attaquants exploitent des failles dans les programmes pour prendre plus de contrôle sur un système. Les sandboxes aident à réduire ce risque en s'assurant que les programmes tournent avec le minimum de permissions nécessaires. Par exemple, si un programme ne devrait pas pouvoir accéder à certains fichiers ou fonctionnalités réseau, la sandbox bloquera cet accès.

Dans le monde des logiciels open-source, le sandboxing est super important. Les systèmes open-source sont construits en combinant divers paquets logiciels, et s'assurer que ces paquets fonctionnent ensemble en toute sécurité est crucial. Même si la plupart des systèmes d'exploitation actuels proposent une forme de sandboxing, il n'y a pas beaucoup de standardisation. Chaque système d'exploitation a son propre ensemble d'outils de sandboxing, ce qui peut compliquer la tâche aux développeurs.

#Le Défi du Sandboxing

Bien que le sandboxing soit important, l'utilisation effective des mécanismes de sandboxing dans les paquets de logiciels open-source est étonnamment faible. Des recherches ont montré que moins de 1% des paquets logiciels utilisent directement ces mécanismes, mais beaucoup de paquets peuvent quand même dépendre d'autres qui le font.

Pour comprendre comment les développeurs utilisent le sandboxing, on a regardé plusieurs systèmes d'exploitation différents. Chaque système d'exploitation a ses propres outils de sandboxing uniques :

• Linux utilise des outils comme Seccomp et Landlock.
• FreeBSD propose Capsicum.
• OpenBSD a Pledge et Unveil.

#Questions de Recherche

Cette étude a cherché à répondre à quelques questions clés concernant l'utilisation du sandboxing dans les paquets logiciels :

1. Dans quelle mesure les mécanismes de sandboxing sont-ils utilisés dans différents systèmes d'exploitation ?
2. Comment ces mécanismes se comparent-ils en termes de complexité et de sécurité pour sécuriser le même paquet logiciel à travers divers systèmes d'exploitation ?

#Résultats sur l'Utilisation du Sandboxing

L'enquête a révélé que bien que de nombreux paquets dépendent d'autres qui utilisent le sandboxing, le nombre de paquets qui utilisent directement les APIs de sandboxing est faible dans tous les systèmes. On a découvert des cas où les développeurs simplifiaient leur mise en œuvre du sandboxing, choisissant des méthodes moins complexes au lieu d'utiliser pleinement les capacités d'outils plus avancés.

Utiliser le sandboxing nécessite que les développeurs modifient leur code pour répondre à certaines exigences. Fait intéressant, les méthodes de sandboxing plus simples, comme celles offertes par Pledge d'OpenBSD, peuvent parfois entraîner des restrictions plus strictes que des méthodes plus complexes comme Seccomp.

#Vue d'Ensemble des Mécanismes de Sandboxing

#Seccomp

Seccomp, qui signifie "secure computing," a été introduit dans Linux en 2005. Il permet aux développeurs de limiter les appels système que leurs applis peuvent faire. En créant une liste d'appels système autorisés ou refusés, les développeurs peuvent contrôler ce que leurs programmes sont autorisés à faire.

Avec Seccomp, les développeurs peuvent spécifier quels appels système sont permis et définir des actions pour quand des appels restreints sont faits. Par exemple, un programme peut être configuré pour se terminer s'il essaie de faire un appel système non autorisé. Les développeurs peuvent aussi utiliser une bibliothèque appelée libseccomp, qui facilite l'utilisation de Seccomp sans avoir besoin d'écrire du code complexe.

#Landlock

Landlock est arrivé en tant que module de sécurité Linux en 2017. Il permet aux développeurs de définir des règles d'accès pour les fichiers et répertoires. Avec Landlock, les développeurs peuvent restreindre l'accès à certaines parties du système de fichiers ou limiter les actions à des lectures uniquement. Comme Seccomp, Landlock hérite des restrictions des processus parents.

#Pledge et Unveil

OpenBSD propose Pledge et Unveil, qui sont des systèmes de sandboxing plus simples par rapport à Seccomp et Landlock. Pledge permet aux développeurs de déclarer que leur appli va uniquement utiliser certaines fonctionnalités. Si un programme essaie d'effectuer des actions en dehors de ses promesses définies, il va se terminer.

Unveil fonctionne avec Pledge en limitant les applis à des répertoires spécifiques avec certaines permissions. Si une appli essaie d'accéder à des fichiers ou répertoires pour lesquels elle n'a pas reçu de permission, elle sera stoppée.

#Capsicum

FreeBSD utilise Capsicum, qui permet aux développeurs de contrôler l'accès en fonction des descripteurs de fichiers. Cela signifie que les développeurs peuvent définir ce qu'un programme peut ou ne peut pas accéder en fonction de fichiers ou ressources spécifiques. Une fois qu'un programme entre en mode de capacité, il ne peut pas accéder au système plus large, ce qui en fait un outil utile pour le sandboxing.

#L'Étude de l'Utilisation des Paquets

Pour avoir une image plus claire de la façon dont le sandboxing est adopté dans différents systèmes d'exploitation, on a analysé le code source de divers dépôts. On s'est concentrés sur des systèmes open-source populaires comme Debian et Fedora, ainsi que FreeBSD et OpenBSD. En examinant leurs paquets, on voulait comprendre combien et lesquels utilisent le sandboxing.

Les paquets qui utilisent des mécanismes de sandboxing ont été identifiés en recherchant des appels spécifiques liés au sandboxing dans le code. On a pris des mesures pour s'assurer que nos résultats étaient précis, en filtrant les instances non pertinentes où le sandboxing n'était présent que dans le code de test.

#Pourcentage de Paquets Utilisant le Sandboxing

Malgré l'examen de milliers de paquets, le nombre de ceux utilisant directement des mécanismes de sandboxing était très faible dans tous les systèmes d'exploitation. Dans de nombreux cas, les paquets qui semblaient avoir du code sandboxé dépendaient en fait d'autres paquets qui utilisaient des mécanismes sandbox. Par conséquent, comprendre si un programme est vraiment sandboxé peut être complexe, car il peut dépendre de plusieurs dépendances.

#Types d'Applications Qui Utilisent le Sandboxing

Quand on a regardé les types d'applications qui utilisent des mécanismes de sandboxing, on a remarqué une différence claire entre les systèmes d'exploitation. Pour Linux, la plupart des paquets sandboxés appartenaient aux catégories de développement et de bibliothèques. En revanche, FreeBSD et OpenBSD avaient un plus grand nombre d'applications réseau et utilitaires utilisant le sandboxing.

Les outils réseau sont particulièrement de bons candidats pour le sandboxing puisque ils interagissent souvent avec des utilisateurs externes. OpenBSD se démarque avec un pourcentage bien plus élevé de paquets réseau utilisant le sandboxing comparé aux distributions Linux.

#Que Fait le Code Sandboxé ?

Avec des outils de sandboxing comme Seccomp, les développeurs ont la capacité de contrôler les appels système et de restreindre les actions basées sur les arguments fournis. Beaucoup de programmes vont au-delà de simplement autoriser ou refuser des appels système ; ils limitent comment ces appels sont exécutés. Cela implique souvent d'écrire des filtres complexes qui peuvent être difficiles à créer.

Fait intéressant, notre étude a montré qu'un grand nombre de développeurs choisissaient de mettre en œuvre des sandboxes plus complexes même quand des options plus simples étaient disponibles. Cela suggère que de nombreux développeurs sont intéressés à créer des applications sécurisées, malgré les défis impliqués.

#Comparaison du Sandboxing entre Systèmes

On a aussi regardé comment différents systèmes mettent en œuvre le sandboxing pour la même application. En faisant cela, on a découvert que Seccomp permettait des sandboxes très détaillées comparées à Pledge. Par exemple, en examinant une application spécifique appelée arping, on a trouvé que sa sandbox dans Linux était beaucoup plus stricte que ses versions dans d'autres systèmes d'exploitation.

D'un autre côté, certaines applications n'ont pas pleinement profité des capacités offertes par Seccomp. Dans un tel cas, le paquet xwallpaper a implémenté Seccomp non pas pour améliorer la sécurité, mais simplement pour reproduire ce qui avait déjà été réalisé avec Pledge.

#Sandboxing au Démarrage

Quand on a examiné les processus qui se lancent juste après le démarrage du système, on a observé des tendances intéressantes. OpenBSD affichait une avance claire avec un nombre notable de processus utilisant Pledge ou Unveil. En revanche, Fedora et Debian avaient moins de processus utilisant leurs mécanismes de sandboxing.

Ces observations mettent en lumière que bien qu'un petit nombre de paquets invoquent directement les APIs de sandboxing, beaucoup d'entre eux dépendent d'autres qui le font. La véritable portée de l'utilisation du sandboxing peut souvent être masquée par ces dépendances, rendant difficile une évaluation précise de la sécurité.

#Barrières à l'Adoption du Sandboxing

Malgré la disponibilité de mécanismes de sandboxing, il y a encore des obstacles qui empêchent une adoption plus large. Un défi est que les développeurs doivent avoir une compréhension approfondie de leurs applications et des appels système utilisés. Cela peut être intimidant pour de grands programmes complexes.

Déboguer des applications sandboxées peut aussi être délicat. Si un programme essaie d'effectuer une action en dehors de son champ permis, il va se terminer. Les développeurs doivent alors analyser l'erreur pour déterminer ce qui a mal tourné.

#Solutions Potentielles

Pour encourager l'utilisation du sandboxing, il pourrait aider que les langages de programmation intègrent des mesures de sécurité par défaut. En obligeant les développeurs à demander explicitement des permissions pour certaines actions, la pression pour adopter des pratiques de sécurité devient plus significative.

De plus, développer des outils qui peuvent aider à surveiller les applications pour des permissions excessives pourrait améliorer la situation. En offrant des aperçus sur la façon dont les programmes utilisent les ressources, les développeurs seront plus enclins à adopter des mécanismes de sandboxing.

#Conclusion

Bien que le sandboxing soit une partie cruciale pour assurer la sécurité dans les logiciels, les niveaux d'adoption actuels dans les écosystèmes open-source sont faibles. Même si certains paquets emploient des mécanismes de sandboxing, beaucoup d'autres dépendent d'une utilisation indirecte via des dépendances. Le paysage du sandboxing varie significativement entre différents systèmes d'exploitation et applications, et comprendre comment les développeurs abordent ces mécanismes sera essentiel pour améliorer leur adoption.

Alors que les préoccupations de sécurité continuent d'augmenter, trouver des moyens de simplifier l'implémentation du sandboxing et de renforcer son importance sera essentiel. Grâce à une meilleure compréhension et un meilleur soutien, on peut aider à favoriser un environnement logiciel plus sécurisé dans les écosystèmes open-source.