Linux port/socket pseudo ACLs

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
23
déc.
2001
Linux
Bien pratique, Linux port/socket pseudo ACLs permet entre autres d'autoriser le bind des ports réservés à root, pour des utilisateurs classiques. Les services qui sont susceptibles d'être défaillant sont ainsi un peu mieux protégés contre une quelconque faiblesse. Cela permet d'éviter de jongler avec les IPChains/Tables. Le patch kernel existe pour Linux 2.4.16/17, 2.2.19/20, 2.5.0/1.

Aller plus loin

  • # Question simple...

    Posté par  (site web personnel) . Évalué à 10.

     Pourquoi est-ce que on continue à bloquer les low ports pour tout le monde sauf root? Je pense que c'est pour des raisons historiques, sans doute obsoletes aujourd'hui dans la plupart des cas.


     Dès qu'un exploit est trouvé pour apache/wu-ftpd/obi-wan kenobi qui tournent en root, ça a beaucoup plus de consequences qu'un service qui tourne sur un high port.


     Ca serait pas mieux de rajouter un groupe (par ex. lowports ou meuble2jardin) qui aurait le droit de les ouvrir et de specifier les ports ouvrables par chacun de ses users? Ca permetterait de faire tourner les services low ports en users non-suid, ce qui serait à mon avis un gain de securité. Ce patch permet de faire plus ou moins la même chose et je ne vois pas de mal à ca. J'ai raison ou je raconte des niaiseries?

    • [^] # Re: Question simple...

      Posté par  . Évalué à 10.

      Je vois mal mon sshd tourner en user :)

      Apache par-contre peut très bien tourner en user (www-data, httpd), et y'a le daemon père qui tourne en root pour manager les requêtes qui arrivent sur le port 80 ..

      C'est pour quand l'intégration au kernel?

      • [^] # sshd en user

        Posté par  . Évalué à 10.

        sshd -f $HOME/sshd_config -p 6666

        ah oui, ça le fait...

        • [^] # Re: sshd en user

          Posté par  . Évalué à 10.

          AFAIK Il faut etre root pour utiliser les fonction PAM || lire /etc/shadow .. donc, ca te servira pas a grand chose.

          • [^] # sshd en user

            Posté par  . Évalué à 2.

            Il faut etre root pour utiliser les fonction PAM || lire /etc/shadow
            Y'a pas que linux dans la vie ...

            à l'occurence, ça me permet de déposer le sauvegardes de mes machines sur un serveur, dans des environnements totalement "étanche".

          • [^] # bah y'a moyen

            Posté par  . Évalué à 1.

            je suis en train en ce moment de me prendre le coux sur l'installation d'une BlackMailBox à base de fetchmail, procmail, cyrus-imapd et ssmtp.

            cyrusimapd utilise un service n'écoutant pas l'extérieur (evidemment) pwcheck qui run en root et s'occupe de l'authentification via les shadows ce qui lui permet d'être lancé en utilisateur cyrus.

            Une solution générique de cette solution serait-elle interessante, je me pose la question, ne l'ayant pas encore retouvrnée dans tous les sens... mmm

    • [^] # Re: Question simple...

      Posté par  . Évalué à 10.

      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é.

    • [^] # Followup: Question simple...

      Posté par  (site web personnel) . Évalué à 10.

      En fait moi je me demandais pourquoi, historiquement ou autrement, on bloquait les low ports pour tout le monde. Je suppose que c'est pour eviter que le user obiwan lance son apache sur la box comme ca. Je pense que si il y a pas (plus?) d'autres raisons concrètes pour bloquer, un truc plus simple, secure et pratique que d' avoir des papa-daemons ou des trucs qui tournent en root, ce qui me rend tjrs un peu mal à l'aise, ressemblerait à ça:

      #!/bin/sh
      adduser httpd lowports
      // le user httpd a le droit d'ouvrir tous les lowports

      ou encore mieux:

      #!/bin/sh
      echo "httpd 80" >> /etc/lowports
      // le user httpd a le droit d'ouvrir le lowport 80

      et supprimer les daemons pères qui à mon avis ne servent pas à grand chose. Un user ftpd par exemple serait echo "ftpd 20,21" >> /etc/lowports et utiliserait qqch genre login pour avoir les droits de l'user qui vient de se logger. Il y aurait plus besoin de suid les daemons, ce qui rendrait le serveur plus secure. C'es complètement farfelu ou pas si con?

      • [^] # Re: Followup: Question simple...

        Posté par  . Évalué à 10.

        > C'es complètement farfelu ou pas si con?

        c'est pas con et absolument pas farfelu mais quel services font en bénéficier ? httpd, ftpd .... ok mais sshd, telnetd, inetd vont rester en root et bien d'autres services encore car ils en ont besoin.

        Ne serait-ce pas beaucoup de code dans la couche de communication qui peut-être facilement contourner par les api setuid(), setguid() ?

        de mon point de vue, oui mais pour d'autres non (la preuve, l'existence de ce patch).

        désolé de ne pas donner de réponse franche car c'est presque de la religion à la vi vs emacs et je sens le troll venir (vite un nain et sa hache !).

        • [^] # Re: Followup: Question simple...

          Posté par  (site web personnel) . Évalué à 10.

          Ce qui est clair, c'est que ce problème ne pourra être complètement résolu qu'avec des systèmes de permissions comme celui du Hurd, où les processus ne sont pas tenus de perdre leurs droits pour devenir un utilisateur mais peuvent en gagner via un serveur. Tous les problèmes de sécurité étant concentrés au même endroit, on réduit d'autant les risques.

          En attendant (parce qu'il peut s'écouler un certain temps avant que les dolutions de ce type soient effectives), la solution de laisser un utilisateur non physique ouvrir un certain port me paraît sympathique, vu qu'elle ne change quasiment rien du point de vue pratique mais permet de gagner de la sécurité.

      • [^] # Re: Followup: Question simple...

        Posté par  . Évalué à 10.

        > En fait moi je me demandais pourquoi, historiquement ou autrement, on bloquait les low ports pour tout le monde.

        De mémoire (comprendre: je me trompe surement), les gens avait envie que certains services soient "surs". On a donc reservé les 1024 premiers ports a root pour être sur que les services associés soient bien censés être lancés.

        > C'es complètement farfelu ou pas si con?

        C'est pas con du tout mais je trouve un peu plus simple de faire un chgrp wheel sur l'executable,
        de le mettre en setuid et en execution par le groupe puis de mettre les personnes qui peuvent lancer le service dans le group wheel.

        • [^] # Re: Followup: Question simple...

          Posté par  . Évalué à 10.

          De mémoire (comprendre: je me trompe surement), les gens avait envie que certains services soient "surs". On a donc reservé les 1024 premiers ports a root pour être sur que les services associés soient bien censés être lancés.

          Je pense que c'est ça. Dans une machine utilisateur, éviter qu'il y ai un user (local, masi pas sur, comme on en trouve en école par exemple) qui lance un serveur telnet en 23, en enregistrant les mots de passes. Un telnet en 23, c'est moins louche qu'un telnet en 2023.

    • [^] # re : question simple

      Posté par  (site web personnel) . Évalué à 8.

      Pour des raisons de sécurité et d'usage, il est souhaitable que root maitrise les lowports... Si tous les utilisateurs peuvent ouvrir des lowports, et que l'un prend le port telnet pour une appli à lui, quand root veut ouvrir le service telnet, y'a un probleme !... De plus l'utilisateur peut installer un trojan sur port telnet, pour capturer les password des gens.

      Cependant c'est bien qu'il y ait une alternative. Ca peut toujours servir !

  • # achat de dvd

    Posté par  . Évalué à -10.

    perso, j'acheterai un lecteur DVD et des DVD lorsque:
    - ces @#{|[^] de zones n'existerons plus;
    - ils ne seront plus cryptés;
    - je pourrai utiliser un logiciel de lecture qui n'utilise pas un algo illégal dans certains (beaucoup) pays;
    - le prix sera à la portée de tout un chacun;
    - je pourrai me servir de DVD comme support de stockage, et ce pour un prix décent;

    Sur ce, en attendant, et pour bien montrer que je suis _contre_ ce système « venez à moi les billets », je continuerai à regarder des DivX téléchargés légalement ou illégalement.

    Qui a dit que j'etais pas pret d'avoir un lecteur DVD ? ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.