Les développeurs que QEMU, LXC et vsftpd se sont déjà fait entendre sur seccomp_filter, donc je pense que le message est passé; de plus les communautés des couches supérieures sont relativement peu habituées à bosser avec le noyau ou sur les points de sécurité, donc ils ne sont sans doute pas trop au courant de ce qui se discute et des avantages que ça pourrait leur apporter.
Au niveau de la "compatibilité" Capsicum, ça n'est pas envisagé pour l'instant. Les gens qui poussent seccomp_filter ont fait le choix explicite de ne pas parler de Capsicum, parce qu'un port Capsicum serait trop invasif et que les devs kernel (à raison) sont très conservateurs. Ils préfèrent pousser des amélioration incrémentales des mécanismes existants pour obtenir quelque chose d'intégré, et faire valider chaque étape. Quand on voit le mal qu'ils ont à avancer sur une fonctionnalité plus modeste, on se dit que c'était le bon choix.
La question de la compatibilité pourrait être intéressante, mais le mieux pour l'instant c'est d'espérer que les fonctionnalités soient là, quelle que soit l'interface. De toute façon, adapter son code de sécurité aux différentes interfaces des différents OS, les devs Chromium par exemple sont déjà obligés de le faire aujourd'hui. Le travail sur seccomp_filter ne peut qu'améliorer leur situation -- il vaut mieux avoir avoir à maintenir deux codes différents de 100/200 lignes, plutôt qu'un code de 100 lignes et un code à 11 000.
[^] # 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é à 6.
Les développeurs que QEMU, LXC et vsftpd se sont déjà fait entendre sur
seccomp_filter, donc je pense que le message est passé; de plus les communautés des couches supérieures sont relativement peu habituées à bosser avec le noyau ou sur les points de sécurité, donc ils ne sont sans doute pas trop au courant de ce qui se discute et des avantages que ça pourrait leur apporter.Au niveau de la "compatibilité" Capsicum, ça n'est pas envisagé pour l'instant. Les gens qui poussent
seccomp_filteront fait le choix explicite de ne pas parler de Capsicum, parce qu'un port Capsicum serait trop invasif et que les devs kernel (à raison) sont très conservateurs. Ils préfèrent pousser des amélioration incrémentales des mécanismes existants pour obtenir quelque chose d'intégré, et faire valider chaque étape. Quand on voit le mal qu'ils ont à avancer sur une fonctionnalité plus modeste, on se dit que c'était le bon choix.La question de la compatibilité pourrait être intéressante, mais le mieux pour l'instant c'est d'espérer que les fonctionnalités soient là, quelle que soit l'interface. De toute façon, adapter son code de sécurité aux différentes interfaces des différents OS, les devs Chromium par exemple sont déjà obligés de le faire aujourd'hui. Le travail sur
seccomp_filterne peut qu'améliorer leur situation -- il vaut mieux avoir avoir à maintenir deux codes différents de 100/200 lignes, plutôt qu'un code de 100 lignes et un code à 11 000.