Ça ne suffit pas : il faut en plus appliquer le principe d'autorité minimale. Ton client de conversation a beau juste être un client de conversation, il va quand même faire du parsing pour afficher les messages reçus du serveur. Le code de parsing en C est propice aux buffer overflow. Statistiquement, dans ton système, il a presque toujours du code qui tourne sous ton autorité et qui contient une faille de buffer overflow, "une seule chose bien" ou pas.
Une fois que tu as une faille, la question est de savoir ce que l'attaquant peut faire avec. Avec le système de sécurité UNIX classique basé sur les droits utilisateurs, un attaquant peut faire tout ce que l'utilisateur peut faire. Donc une faille dans le code de parsing de ton serveur de messagerie peut être exploitée pour lire tes fichiers, les effacer, envoyer des messages sur le réseau comme tu le fais, etc. C'est un défaut de sécurité immense qui touche tous les systèmes d'exploitation mainstream actuel, et que l'on essaie de tempérer de l'extérieur, avec des politiques systèmes pour créer des contextes d'exécution restreint.
Bref, ces deux aspects sont indépendants: ton idée de minimiser les fonctionnalités permet de réduire la surface de vulnérabilité (en ayant simplement moins de code), mais pas le danger lié à une vulnérabilité donnée (et comme ton système reste assez gros, tu es donc en danger); permettre aux applications d'abandonner les privilèges permet, à quantité de code potentiellement buggué constant, de diminuer le danger, donc la surface d'attaque effective.
Après le design UNIX dont tu parles revient à mettre en place une forme de compartementalisation. C'est bien, car il est plus facile ensuite d'abandonner des privilèges : quand le logiciel est bien conçu, il est découpé en parties indépendantes qui correspondent à la fois aux fonctionnalités et à l'autorité nécessaire pour le fonctionnement. Donc on peut juste dire "dans tel sous-programme je me contente de tels droits", et on obtient déjà un découpage assez fin (ce qui n'est pas forcément pas vrai pour du logiciel spaghetti ou le traitement de tel ou tel aspect est éparpillé tout au long du programme).
[^] # Re: Et la solution serait pas simplement...
Posté par gasche . En réponse à la dépêche Sandboxing fin dans le noyau linux : la saga des filtres seccomp. Évalué à 9.
Ça ne suffit pas : il faut en plus appliquer le principe d'autorité minimale. Ton client de conversation a beau juste être un client de conversation, il va quand même faire du parsing pour afficher les messages reçus du serveur. Le code de parsing en C est propice aux buffer overflow. Statistiquement, dans ton système, il a presque toujours du code qui tourne sous ton autorité et qui contient une faille de buffer overflow, "une seule chose bien" ou pas.
Une fois que tu as une faille, la question est de savoir ce que l'attaquant peut faire avec. Avec le système de sécurité UNIX classique basé sur les droits utilisateurs, un attaquant peut faire tout ce que l'utilisateur peut faire. Donc une faille dans le code de parsing de ton serveur de messagerie peut être exploitée pour lire tes fichiers, les effacer, envoyer des messages sur le réseau comme tu le fais, etc. C'est un défaut de sécurité immense qui touche tous les systèmes d'exploitation mainstream actuel, et que l'on essaie de tempérer de l'extérieur, avec des politiques systèmes pour créer des contextes d'exécution restreint.
Bref, ces deux aspects sont indépendants: ton idée de minimiser les fonctionnalités permet de réduire la surface de vulnérabilité (en ayant simplement moins de code), mais pas le danger lié à une vulnérabilité donnée (et comme ton système reste assez gros, tu es donc en danger); permettre aux applications d'abandonner les privilèges permet, à quantité de code potentiellement buggué constant, de diminuer le danger, donc la surface d'attaque effective.
Après le design UNIX dont tu parles revient à mettre en place une forme de compartementalisation. C'est bien, car il est plus facile ensuite d'abandonner des privilèges : quand le logiciel est bien conçu, il est découpé en parties indépendantes qui correspondent à la fois aux fonctionnalités et à l'autorité nécessaire pour le fonctionnement. Donc on peut juste dire "dans tel sous-programme je me contente de tels droits", et on obtient déjà un découpage assez fin (ce qui n'est pas forcément pas vrai pour du logiciel spaghetti ou le traitement de tel ou tel aspect est éparpillé tout au long du programme).