Habituellement, si tu veux un service qui tourne pas en root sur un port root, tu "downgrade" (dégrade ?) vers l'utilisateur voulu aprés avoir ouvert les ports désiré avec les droits "root".
ça marche bien mais il faut que le programmeur est prévu cette possibilité.
A part un choix de design un peu plus propre (enfin presque car c'est limité aux sockets), je me demande qu'elle est l'avantage de cette solution (les ACLs). En effet, ouvrir ces ports directement aux utilisateurs complique la gestion de la sécurité. Maintenant que je peux associer des droits d'accès à mon compte perso pour gérer des ports "root", la corruption de mon compte pourra corrompre des "ports" root.
Au final, la meilleur sécurité théorique est donc d'associer à chaque service un compte (et surtout pas un compte d'utilisateur <<physique>>) mais il est possible de le faire sans ACL.
Ainsi, à part pour des histoire de religion de sécurité, avoir des ACL sur les ports "root" n'améliore pas la sécurité.
[^] # Re: Question simple...
Posté par Schwarzy . En réponse à la dépêche Linux port/socket pseudo ACLs. Évalué à 10.
ça marche bien mais il faut que le programmeur est prévu cette possibilité.
A part un choix de design un peu plus propre (enfin presque car c'est limité aux sockets), je me demande qu'elle est l'avantage de cette solution (les ACLs). En effet, ouvrir ces ports directement aux utilisateurs complique la gestion de la sécurité. Maintenant que je peux associer des droits d'accès à mon compte perso pour gérer des ports "root", la corruption de mon compte pourra corrompre des "ports" root.
Au final, la meilleur sécurité théorique est donc d'associer à chaque service un compte (et surtout pas un compte d'utilisateur <<physique>>) mais il est possible de le faire sans ACL.
Ainsi, à part pour des histoire de religion de sécurité, avoir des ACL sur les ports "root" n'améliore pas la sécurité.