seccomp_filter permet à une application de dire au noyau : "à partir de maintenant, je n'ai plus besoin de l'appel système ; si je l'appelle par mégarde (par erreur ou parce qu'un utilisateur malicieux me pousse à le faire), interdis-le s'il te plaît, pour m'empêcher de faire des bêtises". En fait c'est plus fin que ça, il peut dire "je vais utiliser cet appel mais seulement sous telle et telle condition, le reste tu me l'interdis".
C'est le développeur de l'application qui insère ces appels à seccomp, donc qui décide d'abandonner certains de ses privilèges. S'il se trompe et en fait l'application avait bien besoin de cet appel, l'appli va planter; mais ça c'est un bug qu'il va (on espère) repérer pendant le développement. Dans le cas normal, les droits sont limités mais personne ne s'en rend compte, puisque l'application n'essaie pas de les utiliser de toute façon. Et si on repère un bug ou une faille de sécurité dans le logiciel après cet abandon, on a une meilleure idée de ce qui peut se passer, et surtout de ce qui ne peut pas se passer : une tranche entière de "mauvais comportement" est exclue. Par exemple si l'application abandonne son droit à lire le système de fichier (sauf /tmp), on sait que le bug n'autorisera pas un attaquant à lire mes fichiers de configuration.
L'utilisateur lambda n'a même pas besoin de savoir que cette protection existe. Il en entendra seulement parler quand il lira "une faille a été détectée dans libpng, sous Windows elle permet l'exécution de code arbitraire, mais sous Linux ou FreeBSD elle est inoffensive car à cet instant le processus de rendu n'a plus aucun droit".
[^] # Re: euh je ne suis pas certain d'avoir compris
Posté par gasche . En réponse à la dépêche Sandboxing fin dans le noyau linux : la saga des filtres seccomp. Évalué à 6.
seccomp_filterpermet à une application de dire au noyau : "à partir de maintenant, je n'ai plus besoin de l'appel système ; si je l'appelle par mégarde (par erreur ou parce qu'un utilisateur malicieux me pousse à le faire), interdis-le s'il te plaît, pour m'empêcher de faire des bêtises". En fait c'est plus fin que ça, il peut dire "je vais utiliser cet appel mais seulement sous telle et telle condition, le reste tu me l'interdis".C'est le développeur de l'application qui insère ces appels à seccomp, donc qui décide d'abandonner certains de ses privilèges. S'il se trompe et en fait l'application avait bien besoin de cet appel, l'appli va planter; mais ça c'est un bug qu'il va (on espère) repérer pendant le développement. Dans le cas normal, les droits sont limités mais personne ne s'en rend compte, puisque l'application n'essaie pas de les utiliser de toute façon. Et si on repère un bug ou une faille de sécurité dans le logiciel après cet abandon, on a une meilleure idée de ce qui peut se passer, et surtout de ce qui ne peut pas se passer : une tranche entière de "mauvais comportement" est exclue. Par exemple si l'application abandonne son droit à lire le système de fichier (sauf /tmp), on sait que le bug n'autorisera pas un attaquant à lire mes fichiers de configuration.
L'utilisateur lambda n'a même pas besoin de savoir que cette protection existe. Il en entendra seulement parler quand il lira "une faille a été détectée dans libpng, sous Windows elle permet l'exécution de code arbitraire, mais sous Linux ou FreeBSD elle est inoffensive car à cet instant le processus de rendu n'a plus aucun droit".