Bon alors je me suis un peu informé en cours de route et il s'avere que je me trompe un peu (enfin toujours si j'ai bien tout compris).
Donc en fait, avant chaque utilisateur avait ses "capabilities" (ce qu'il a le droit de faire en fait), comme pouvoir lancer des serveurs sur des ports < 1024, acceder aux interfaces réseau en raw, etc. Enfin en théorie du moins, en pratique, meme si linux etait censé le gérer, rien n'était vraiment fait pour et ca tenait du capharnaum, et c'etait par utilisateur.
La nouveauté ici c'est, en fait, qu'un processus peut modifier ses propres capabilities (et ceux de ses déscendants, à coup de fork() et exec() ), par contre, contrairement au hurd un processus ayant tous les droits ne peut pas ('fin de ce que j'ai lu, a priori en espace noyau ca a pas l'air bien compliqué à faire) donner ses droits à un autre processus.
En tout cas, cette amélioration est un gain nette en terme de sécurité:
Prenons le cas d'un serveur http qui écoute sur le port 80. Il n'a, a priori, aucune raison d'avoir de droits particuliers, sauf pour le port (pour les ports < 1024 faut avoir une "capability" qui va bien). Et donc jusqu'à aujourd'hui, il fallait lancer apache en root, qui apres avoir lancé la partie écoute du port 80, se mettait sous l'utilisateur apache, mais une faille de sécurité peut encore exister entrtre le lancement de l'écoute et le changement d'utilisateur !
Maintenant on pourra lancer apache directement sous l'utilisateur apache, avec le droit de lancer un serveur sur le port 80, donc on pourra inclure dans sysvinit un utilitaire de la forme launch_w_caps apache BIND_INF_1024 httpd, qui lancera httpd sous l'utilisateur apache directement, tout en lui gardant le droit de lancer un serveur sur le port 80 (et donc si y a une faille de sécu, elle pourra etre partagée entre tous les serveurs :) )
[^] # Re: Les bits de sécurité ?
Posté par Ph Husson (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 10.
Donc en fait, avant chaque utilisateur avait ses "capabilities" (ce qu'il a le droit de faire en fait), comme pouvoir lancer des serveurs sur des ports < 1024, acceder aux interfaces réseau en raw, etc. Enfin en théorie du moins, en pratique, meme si linux etait censé le gérer, rien n'était vraiment fait pour et ca tenait du capharnaum, et c'etait par utilisateur.
La nouveauté ici c'est, en fait, qu'un processus peut modifier ses propres capabilities (et ceux de ses déscendants, à coup de fork() et exec() ), par contre, contrairement au hurd un processus ayant tous les droits ne peut pas ('fin de ce que j'ai lu, a priori en espace noyau ca a pas l'air bien compliqué à faire) donner ses droits à un autre processus.
En tout cas, cette amélioration est un gain nette en terme de sécurité:
Prenons le cas d'un serveur http qui écoute sur le port 80. Il n'a, a priori, aucune raison d'avoir de droits particuliers, sauf pour le port (pour les ports < 1024 faut avoir une "capability" qui va bien). Et donc jusqu'à aujourd'hui, il fallait lancer apache en root, qui apres avoir lancé la partie écoute du port 80, se mettait sous l'utilisateur apache, mais une faille de sécurité peut encore exister entrtre le lancement de l'écoute et le changement d'utilisateur !
Maintenant on pourra lancer apache directement sous l'utilisateur apache, avec le droit de lancer un serveur sur le port 80, donc on pourra inclure dans sysvinit un utilitaire de la forme launch_w_caps apache BIND_INF_1024 httpd, qui lancera httpd sous l'utilisateur apache directement, tout en lui gardant le droit de lancer un serveur sur le port 80 (et donc si y a une faille de sécu, elle pourra etre partagée entre tous les serveurs :) )