Les sandbox Linux et Fil-C

• La sécurité mémoire et le sandboxing sont deux concepts de sécurité indépendants, et il faut disposer des deux pour mettre en place une défense robuste
• Fil-C est une implémentation à sécurité mémoire de C/C++, qui garantit cette sécurité jusqu’au niveau des appels système Linux et peut être utilisée même dans des composants système comme OpenSSH
• Lors du portage du sandbox basé sur seccomp-BPF d’OpenSSH vers Fil-C, les principaux défis ont porté sur les limites de création de threads et l’ajustement du filtre seccomp
• Pour la gestion des threads d’arrière-plan du runtime Fil-C, l’API zlock_runtime_threads() a été ajoutée afin de contrôler le comportement des threads à l’intérieur du sandbox
• Fil-C applique de façon synchronisée les appels prctl à tous les threads du runtime, afin que no_new_privs et le filtre seccomp soient appliqués de manière cohérente à l’ensemble du processus

---

Relation entre sécurité mémoire et sandboxing

• La sécurité mémoire et le sandboxing sont deux couches de sécurité distinctes, et l’une seule ne fournit pas une protection complète
  • Exemple de programme sûr en mémoire mais non sandboxé : un programme Java qui peut écraser un fichier via une entrée utilisateur
  • Exemple de programme sandboxé mais non sûr en mémoire : un programme écrit en assembleur avec des privilèges limités
• En pratique, un sandbox présente des failles structurelles, comme l’autorisation de communication avec un processus broker
• Il est donc préférable de combiner sécurité mémoire et sandboxing

Combinaison de Fil-C et du sandbox OpenSSH

• Fil-C est une implémentation à sécurité mémoire de C/C++, qui conserve cette sécurité au niveau des appels système Linux
  • Le runtime Fil-C peut fonctionner même dans des composants système de bas niveau comme init ou udevd
  • OpenSSH fonctionne normalement avec Fil-C et utilise un sandbox seccomp-BPF
• Sous Linux, OpenSSH construit son sandbox avec les outils suivants
  • chroot pour restreindre l’accès au système de fichiers
  • Exécution sous l’utilisateur/groupe sshd
  • setrlimit pour limiter l’ouverture de fichiers et la création de processus
  • Filtre seccomp-BPF pour n’autoriser que les appels système permis
• Fil-C prend en charge chroot et le changement d’utilisateur par défaut, mais setrlimit et seccomp-BPF peuvent entrer en conflit avec le fonctionnement du runtime, ce qui demande des ajustements supplémentaires

Contrôle des threads dans le runtime Fil-C

• Le runtime Fil-C utilise des threads d’arrière-plan pour le garbage collection, qu’il suspend et relance automatiquement si nécessaire
• Le sandbox setrlimit d’OpenSSH vise à interdire la création de nouveaux processus, et la création de threads par le runtime peut donc enfreindre cette règle
• Pour résoudre ce problème, l’API zlock_runtime_threads() a été ajoutée à <stdfil.h>
  • Le runtime crée immédiatement les threads dont il a besoin, puis désactive leur arrêt automatique par la suite
  • L’appel est effectué dans la fonction ssh_sandbox_child d’OpenSSH avant setrlimit ou seccomp-BPF

Ajustement du filtre seccomp d’OpenSSH

• Après l’application de zlock_runtime_threads(), la plupart des fonctions du sandbox continuent de fonctionner telles quelles
• Les changements suivants ont été apportés au filtre seccomp
  • En cas de violation, réglage sur SECCOMP_RET_KILL_PROCESS afin de terminer aussi les threads d’arrière-plan de Fil-C
  • Ajout de MAP_NORESERVE à la liste des autorisations, pour permettre l’utilisation de l’allocateur mémoire de Fil-C
  • Autorisation de l’appel sched_yield, utilisé dans l’implémentation des verrous de Fil-C
• Les appels futex utilisés par Fil-C pour la synchronisation étaient déjà autorisés, donc aucun changement supplémentaire n’était nécessaire

Mise en œuvre de prctl dans Fil-C

• OpenSSH utilise deux appels prctl lors de l’installation du filtre seccomp
  • PR_SET_NO_NEW_PRIVS pour empêcher l’acquisition de privilèges supplémentaires
  • PR_SET_SECCOMP, SECCOMP_MODE_FILTER pour activer le filtre
• Le problème est que prctl ne s’applique qu’au thread appelant, ce qui laisse le risque que d’autres threads du runtime Fil-C restent sans filtre
• Pour éviter cela, Fil-C utilise l’API filc_runtime_threads_handshake() afin d’appliquer la configuration de manière synchronisée à tous les threads du runtime
  • Elle garantit que chaque thread exécute le même appel prctl
  • En présence de plusieurs threads utilisateur, elle déclenche une erreur de sûreté Fil-C pour renforcer la protection

Conclusion

• La combinaison de la sécurité mémoire et du sandboxing constitue l’approche de sécurité la plus solide
• Fil-C intègre complètement le sandbox basé sur seccomp d’OpenSSH tout en préservant la sécurité mémoire sans réduire le niveau de protection
• Dans un environnement Linux, Fil-C permet d’obtenir à la fois une sécurité au niveau système et une sûreté au niveau du langage