Tout solution qui est construite en supposant qu’on peut faire confiance au code du noyau, en particulier si elle repose sur des logiques compliquées en interne, est fondamentalement limitée à cause de ça.
C’est certain, mais après ce n’est pas une raison pour ne pas se baser dessus, faute de mieux.
Je veux dire, tout OS généraliste n’a pas une sécurité garantie, pourtant les bonnes pratiques (à raison) exploitent au mieux les mécanismes qu’ils proposent car ne pas les utiliser sous prétexte que l’OS n’est pas assez sûr est pire que de se reposer dessus.
Je ne pense pas qu’on puisse sérieusement espérer faire de l’isolation sécurisée avec les cgroups (les développeurs noyaux sont lucides, ils n’osent même pas monter un filesystem sans les droits root), la plupart des designs de conteneurs souffrent de ce problème.
Les conteneurs ne sont pas une sécurité absolue également parce qu’elles n’ont pas été conçues dans l’optique de la sécurité. Les conteneurs offrent surtout une abstraction de la machine, en permettant de l’isoler du reste de l’environnement pour simplifier son administration, son contrôle tout en protégeant contre les erreurs accidentelles (donc résister à un bogue, pas à une personne malveillante).
Et elles remplissent très bien ce rôle. Ce n’est pas totalement satisfaisant car on voudrait de la sécurité en plus mais cela demande du travail en plus.
Les LSMs genre SELinux et AppArmor sont un peu entre les deux (moins fourre-tout et cassés que les cgroups, mais plus compliqués et donc moins robustes que seccomp)
Tu compares des choux et des carottes. Les cgroups ne vise absolument pas le même rôle que les LSM ou Seccomp. De même que Seccomp et LSM sont complémentaires.
Le but de seccomp est que le développeur de l’application réduise au maximum la surface d’attaque aux fonctions dont il a réellement besoin en interne. Mais cela implique que le développeur l’utilise correctement.
LSM permet à l’administrateur de définir une politique de sécurité sur sa machine. Cela permet de pallier à l’absence (ou une mauvaise utilisation de celui-ci) d’usage de seccomp d’une application. Mais aussi à appliquer une politique de sécurité à une application dont tu n’as pas confiance. C’est-à-dire que si je n’ai pas confiance en Firefox (ou une application proprio dont on a pas le code source), je peux lui appliquer des contraintes fortes sans changer quoique ce soit au binaire.
Ce sont donc des mécanismes complémentaires, qui n’offrent pas la même possibilité et qui ne s’adressent pas aux mêmes personnes (l’un est plus pour le développeur, l’autre pour l’administrateur).
mais à ma connaissance on a encore beaucoup, beaucoup de mal à les déployer en pratique sur des machines utilisateurs (sans admin système expert qui les administre), et par ailleurs elles ne changent pas la façon dont on écrit les applications par-dessus (contrairement à seccomp), donc personnellement je pense que c’est impasse sur le long terme.
SELinux est utilisé par défaut dans tous les système Android vendus dans le commerce aujourd’hui. Les distributions comme Fedora, CentOS ou Red Hat s’en servent également par défaut. AppArmor pour Ubuntu.
Pourtant tous ces systèmes sont utilisables sans que l’utilisateur lambda n’ait à s’en préoccuper. Et cela rend bien des services.
Comme je l’ai dit, je pense qu’il est surtout illusoire de croire qu’il y a une manière ultime de faire de la sécurité. La sécurité doit reposer sur un ensemble de mécanismes de protections, potentiellement redondants mais surtout complémentaires, pour que si un maillon de la chaîne casse le reste ne soit pas pour autant compromis.
Si tu combines les cgroups avec une couche de seccomp, SELinux, un pare-feu, etc. par dessus, tu aboutis à une pile de sécurité ou d’isolation qui devient difficilement exploitable (il faudrait potentiellement plusieurs failles séparées pour en venir à bout).
Le risque 0 n’existant pas, je pense qu’on a pas des masses le choix de ce côté là. La seule solution ultime serait la preuve des programmes qui pourrait obtenir des garanties fortes de ce côté, mais tu le sais bien que cela n’est pas réaliste pour nos applications du quotidien.
parce que la surface d’attaque est trop importante et la méthodologie de développement pas assez rigoureuse, la seule solution pour offrir de la sécurité en pratique c’est de faire la course contre les méchants : tous les mois ils trouvent des failles, on essaie de les trouver aussi vite qu’eux ou plus vite et de les corriger rapidement.
Tu auras ce problème quelle que soit ta stratégie de sécurité. La sécurité parfaite n’existe pas, même les logiciels les mieux conçus peuvent avoir des failles.
Ce qui n’existe pas, c’est un système sécurisé par construction qui soit utilisable par le grand public.
Le problème est là, le grand public.
La sécurité par essence restreint les possibilités et ajoute de la complexité d’usage. Si pour avoir une sécurité absolue tu ne peux rien faire, personne n’en voudra. Il faut un compromis.
Je me souviens par exemple d’un Français qui avait écrit un noyau compatible POSIX en grande partie pour le fun qui était par essence très sécurisée car toutes les applications étaient naturellement isolées. Par design, impossible d’y échapper.
La contrainte était que vim ne pouvait pas éditer des fichiers crées par Firefox par exemple. Vim ne pouvait pas appeler non plus un shell quelconque pour certaines choses. Car l’isolation était réellement totale.
Du coup la sécurité était sans doute assez bonne mais pour un usage quotidien c’est impossible de s’en servir. Et je pense vraiment que si tu veux une sécurité par construction absolue, tu aboutiras à ce genre de choses. Ce qui n’est pas satisfaisant non plus.
)