• [^] # Re: L’avenir et le passé

    Posté par . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.

    mais que la liste des actions don't elle a besoin soit suffisamment spécifié pour pouvoir s'assurer qu'elle n'est pas corrompu.

    Ah, OK, je pensais que tu parlais d'autre chose : d'interdire des flux déclarés parce que quelqu'un (l'admin, qui n'a pas codé l'appli) estime qu'ils ne sont « pas légitimes » (vu en vrai !).

    Par contre, autoriser uniquement des flux spécifiés pour ton application, oui, et comme je disais c'est exactement pareil en IPv6 avec des connexions reçues/émises depuis/vers des IP diverses (que tu trouves « daubé »), et du Docker avec du mapping de port. Je persiste juste à dire que coder des prérequis applicatifs dans des éléments du réseau, c'est scléroser le réseau et perdre tous les avantages d'IPv6 (même si — encore une fois — c'est possible).

    Le contrôle du comportement d'un programme, c'est la base de la sécurité (ce que tu as avec les droits unix, avec les lsm, avec les gr security, avec seccomp, etc).

    Malheureusement, cette pratique dans le réseau fait qu'on mélange l'adressage — qui concerne la topologie du réseau — avec des besoins applicatifs et de « sécurité » codés dans le réseau plus ou moins en dur, et que cela va forcément entraîner une sclérose du schéma d'adressage qui ne sera plus changeable, et qu'on devra palier « en dessous » en rajoutant une couche de routage sous-jacente, c'est à dire des tunnels ou autre technologie de VPN/overlay/etc. Et on aura perdu les propriétés de malléabilité du réseau que permet IP.