Je pense qu'aujourd'hui la sécurité d'un système utilisateur est déplorable, en raison d'une combinaison de choix de conception (du contrôle d'accès) qui ne font de chaque possibilité d'exécuter du code arbitraire une faille de sécurité globale du système (tout ce qui est donnée utilisateur est compromis), et de choix techniques (utiliser le langage C) qui font qu'on continue à avoir plusieurs failles d'exécution de code arbitraire par semaine dans des programmes que tout le monde utilise. Le principe fondamental de "moindre privilège" n'est pas respecté et en plus les outils de développement favorisent les trous.
Capsicum permet d'améliorer la conception des programmes utilisateurs pour être plus comportementalisés, et de rendre (dans les processus qui ont abandonné leurs privilèges superflus) des exécutions de code arbitraire beaucoup moins efficaces, ou plutôt sensiblement plus difficiles à exploiter (il faut aussi une faille en espace noyau). Le problème est que "plus difficile" ne veut pas dire impossible et que le modèle d'attaque aujourd'hui (et dans le futur) est très différent de celui des années 90. Ce n'est plus deux virtuoses motivés qui veulent soit se marrer soit siphonner des numéros de carte bleue, mais des criminels très riches (forcément, ça rapporte) et des agences gouvernementales qui collectionnent les attaques dans une course à l'armement ou pour faire de l'espionnage de grande échelle.
Si tu veux un système le plus sûr, la seule approche raisonnable est de supposer qu'il y a des failles partout; le nombre de bugs/failles est en gros proportionnel au nombre de lignes de code, selon un facteur qui dépend du degré de qualité de l'application (et donc du temps et de l'argent investi). Plus un système est gros, plus il a de failles; un système aussi gros que le noyau Linux a mécaniquement un grand nombre de failles; sa "surface d'attaque" est très large.
Pour la réduire, deux solutions:
- diminuer la surface d'attaque : revoir la conception du système pour restreindre la taille de la partie privilégiée (la base de confiance)
- rendre plus robuste le code de la base de confiance : audit régulier, mais surtout méthodes formelles pour prouver l'absence de la plus grande classe de bugs possible et prouver les propriétés de correction les plus fortes possibles
Aujourd'hui l'argent qui va dans le développement du kernel Linux ne va (à ma connaissance) dans aucune de ces directions, et les bénévoles ne font pas grand chose non plus. Linux est un système non-sûr, et la dynamique semble indiquer qu'il va le rester pour un bon moment.
Capsicum reste, malgré tout cela, un gain mesurable en sécurité puisque ça permet de faire passer la surface d'attaque de "absolument titanesque" (tout le code qui tourne avec les droits utilisateurs et le droit (SELinux etc.) de lire ce qui est dans mon $HOME) à juste "complètement énorme" (le noyau Linux). En plus du gain immédiat de cette réduction de surface d'attaque, il pousse les développeurs d'application à réfléchir aux privilèges dont ils ont besoin, et ça c'est un changement de culture qui peut révolutionner la sécurité des applications userland.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 6.
Je pense qu'aujourd'hui la sécurité d'un système utilisateur est déplorable, en raison d'une combinaison de choix de conception (du contrôle d'accès) qui ne font de chaque possibilité d'exécuter du code arbitraire une faille de sécurité globale du système (tout ce qui est donnée utilisateur est compromis), et de choix techniques (utiliser le langage C) qui font qu'on continue à avoir plusieurs failles d'exécution de code arbitraire par semaine dans des programmes que tout le monde utilise. Le principe fondamental de "moindre privilège" n'est pas respecté et en plus les outils de développement favorisent les trous.
Capsicum permet d'améliorer la conception des programmes utilisateurs pour être plus comportementalisés, et de rendre (dans les processus qui ont abandonné leurs privilèges superflus) des exécutions de code arbitraire beaucoup moins efficaces, ou plutôt sensiblement plus difficiles à exploiter (il faut aussi une faille en espace noyau). Le problème est que "plus difficile" ne veut pas dire impossible et que le modèle d'attaque aujourd'hui (et dans le futur) est très différent de celui des années 90. Ce n'est plus deux virtuoses motivés qui veulent soit se marrer soit siphonner des numéros de carte bleue, mais des criminels très riches (forcément, ça rapporte) et des agences gouvernementales qui collectionnent les attaques dans une course à l'armement ou pour faire de l'espionnage de grande échelle.
Si tu veux un système le plus sûr, la seule approche raisonnable est de supposer qu'il y a des failles partout; le nombre de bugs/failles est en gros proportionnel au nombre de lignes de code, selon un facteur qui dépend du degré de qualité de l'application (et donc du temps et de l'argent investi). Plus un système est gros, plus il a de failles; un système aussi gros que le noyau Linux a mécaniquement un grand nombre de failles; sa "surface d'attaque" est très large.
Pour la réduire, deux solutions:
- diminuer la surface d'attaque : revoir la conception du système pour restreindre la taille de la partie privilégiée (la base de confiance)
- rendre plus robuste le code de la base de confiance : audit régulier, mais surtout méthodes formelles pour prouver l'absence de la plus grande classe de bugs possible et prouver les propriétés de correction les plus fortes possibles
Aujourd'hui l'argent qui va dans le développement du kernel Linux ne va (à ma connaissance) dans aucune de ces directions, et les bénévoles ne font pas grand chose non plus. Linux est un système non-sûr, et la dynamique semble indiquer qu'il va le rester pour un bon moment.
Capsicum reste, malgré tout cela, un gain mesurable en sécurité puisque ça permet de faire passer la surface d'attaque de "absolument titanesque" (tout le code qui tourne avec les droits utilisateurs et le droit (SELinux etc.) de lire ce qui est dans mon $HOME) à juste "complètement énorme" (le noyau Linux). En plus du gain immédiat de cette réduction de surface d'attaque, il pousse les développeurs d'application à réfléchir aux privilèges dont ils ont besoin, et ça c'est un changement de culture qui peut révolutionner la sécurité des applications userland.