Seul root a le droit d'ouvrir un port < 1024. Dans la pratique je n'ai jamais, en 15 ans d'administration système, eu besoin d'ouvrir un port < 1024 pour utilisateur. Ce qui est fait en revanche, c'est que root lance un programme qui se sépare en deux pour gérer correctement la séparation de privilèges, avec d'un côté un programme qui gère le réseau et les appels systèmes en tout genre, et un programme qui n'a droit qu'à très peu de choses, avec un pledge qui lui coupe presque tout et est dans une racine séparée.
OpenBSD ne part pas du principe qu'on a le droit d'ignorer le code, le projet part au contraire du principe qu'il faut être très vigilent sur le programme qu'on écrit, qu'il faut faire activement des relectures même si on implémente des tas de parades dans le noyau pour contrer des attaques potentielles. Les deux sont complémentaires, et on ne peut pas prétendre gérer la sécurité si on ne fait pas les deux. S'il y a eu si peu de failles sur ce système en plus de 20 ans d'existence, ce n'est pas le fruit du hasard. Les mots clés sont : relecture et sécurité pro-active (séparation de privilèges, pledge, W^X, pageguard, diverses options de compilation...).
Si on a un programme dangereux à faire tourner, on peut toujours le mettre dans un chroot et le lancer via un autre utilisateur. On peut aussi s'amuser à lui créer une interface réseau pour qu'il fasse sa tambouille dessus, sous linux il faut voir les netns avec ip. Mais à aucun moment le réflexe est de lui donner tous les droits sur le système, il est contraint, au pire dans un sous-système minimaliste (vraiment minimaliste, un chroot n'a besoin de rien du tout, limite une copie de /etc/resolv.conf et peut-être un ou deux autres fichiers vite-fait).
Implémenter de la sécurité pro-active ne doit pas dispenser d'écrire du code en respectant les standards de sécurité. Et si on les respecte, il ne reste finalement que peu d'erreurs à intercepter, et elles resteront difficiles à analyser même avec votre solution. Donc oui c'est un complément, et le commentaire que je vous ai donné plus haut montre en quoi votre projet peut être intéressant (voir l'exemple de syntaxe pf adaptée à votre outil) avant tout pour voir ce qui se passe en historisant les appels système.
PS: Bon, mine de rien j'ai passé pas mal de temps à argumenter... donc soit on discute authorship soit je pars finir ma thèse ! :-D
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 3.
Seul root a le droit d'ouvrir un port < 1024. Dans la pratique je n'ai jamais, en 15 ans d'administration système, eu besoin d'ouvrir un port < 1024 pour utilisateur. Ce qui est fait en revanche, c'est que root lance un programme qui se sépare en deux pour gérer correctement la séparation de privilèges, avec d'un côté un programme qui gère le réseau et les appels systèmes en tout genre, et un programme qui n'a droit qu'à très peu de choses, avec un pledge qui lui coupe presque tout et est dans une racine séparée.
OpenBSD ne part pas du principe qu'on a le droit d'ignorer le code, le projet part au contraire du principe qu'il faut être très vigilent sur le programme qu'on écrit, qu'il faut faire activement des relectures même si on implémente des tas de parades dans le noyau pour contrer des attaques potentielles. Les deux sont complémentaires, et on ne peut pas prétendre gérer la sécurité si on ne fait pas les deux. S'il y a eu si peu de failles sur ce système en plus de 20 ans d'existence, ce n'est pas le fruit du hasard. Les mots clés sont : relecture et sécurité pro-active (séparation de privilèges, pledge, W^X, pageguard, diverses options de compilation...).
Si on a un programme dangereux à faire tourner, on peut toujours le mettre dans un chroot et le lancer via un autre utilisateur. On peut aussi s'amuser à lui créer une interface réseau pour qu'il fasse sa tambouille dessus, sous linux il faut voir les
netnsavecip. Mais à aucun moment le réflexe est de lui donner tous les droits sur le système, il est contraint, au pire dans un sous-système minimaliste (vraiment minimaliste, un chroot n'a besoin de rien du tout, limite une copie de/etc/resolv.confet peut-être un ou deux autres fichiers vite-fait).Implémenter de la sécurité pro-active ne doit pas dispenser d'écrire du code en respectant les standards de sécurité. Et si on les respecte, il ne reste finalement que peu d'erreurs à intercepter, et elles resteront difficiles à analyser même avec votre solution. Donc oui c'est un complément, et le commentaire que je vous ai donné plus haut montre en quoi votre projet peut être intéressant (voir l'exemple de syntaxe
pfadaptée à votre outil) avant tout pour voir ce qui se passe en historisant les appels système.PS: Bon, mine de rien j'ai passé pas mal de temps à argumenter... donc soit on discute authorship soit je pars finir ma thèse ! :-D