Lionel Debroux (./7379) :
En tout cas, mauvais point pour le langage d'implémentation: fournir une API externe en C reste bien sûr nécessaire pour des raisons d'interopérabilité, mais pour de nouvelles bases de code, continuer à tout écrire en C est de plus en plus inacceptable.

Pour moi, l'utilisation du C est un argument en faveur. Les alternatives n'ont pas la même efficacité en taille et en vitesse.

C'est triste que pour Linux, le mode principal d'introduction de sandboxing soit une approche de type containerisation avec un packaging à un format comme Docker, Snap ou Flatpak, autrement dit un gros paquet de nouilles, plutôt qu'une inclusion dans le code des programmes cibles.

En effet, j'ai horreur des conteneurs où il faut embarquer des copies de tout (bundling) et SELinux n'est pas non plus une solution (une base de données centrale qui contient les informations sur les permissions nécessaires pour tous les programmes, ce n'est absolument pas scalable), seccomp est clairement la bonne approche, mais a en effet besoin d'améliorations (notamment, il faudrait une manière raisonnable pour que les bibliothèques (libraries) puissent déclarer les permissions dont elles ont besoin, parce que le programme principal ne peut souvent pas deviner – la meilleure solution serait probablement une annotation dans une section ELF spéciale (comme pour l'annotation GNU_STACK) lue au chargement et immutable pendant toute l'exécution, pour garantir que du code exploit ne puisse modifier les permissions plus tard).