Si tu as selinux, alors dhclient va juste avoir le droit de faire ce que la policy dit de faire, ce qui a des chances de grandement limiter les dégats. j'ai pas regardé en détail, mais de ce que je vois aprés 5 minutes d'analyses, c'est quand même limité.
va lister les domaines vers lesquelles dhcp_t peut faire une transition.
sesearch --allow -s dhcpc_t | grep execute
va lister les types que dhclient a le droit d'executer, la majorité sans avoir des droits différents de dhclient lui même ( vu qu'ils sont pas dans la première liste ).
Un rapide examen montre que dhcpc va écrire des fichiers d'un certain type, mais n'a le droit d'execution sur aucun de ceux qu'il va écrire. Donc ça bloque déjà les exploits à base de wget basique. Tu peux sans doute faire un truc avec wget + un interpreteur de commande ceci dit, mais tu sera toujours limité à ce que dhclient peut faire.
A vue de nez, le truc le plus prometteur serait insmod_t, mais je pense que insmod_t ne va pas charger n'importe quel fichier, et surtout pas un fichier que dhclient va écrire, pour cause de mauvais label.
Ensuite, je voit qu'un script pourrait couper le firewall, ce qui est un souci. Le reste, c'est de la manipulation de réseau, ce qui est chiant, mais dans la mesure ou ça implique un dhcp rogue, je pense qu'on peux supposer que le réseau n'a pas besoin d'une faille pour être modifier de façon créative.
Donc voila, je pense que selinux va bloquer assez efficacement la majorité des soucis, même si j'exclue pas qu'un truc passe à travers, ou qu'on puisse enchainer.
Quand à ssh, ça va marcher si le serveur ssh est openssh ou similaire, ie, un serveur ssh avec un shell. Je sais pas ce que ça donnerais sur les implémentations customs d'un serveur pour des besoins spécifiques ( genre github a son propre serveur git en ruby, si je me souviens bien, et ils semblent dire que leur service n'est pas vulnérable https://github.com/blog/1893-security-vulnerability-in-bash-addressed donc je suppose que c'est pareil pour ssh ). Mais je suppose aussi que ce genre d'infrastructure est l'exception plus que la norme.
[^] # Re: Il est urgent de mettre à jour
Posté par Misc (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 10.
Si tu as selinux, alors dhclient va juste avoir le droit de faire ce que la policy dit de faire, ce qui a des chances de grandement limiter les dégats. j'ai pas regardé en détail, mais de ce que je vois aprés 5 minutes d'analyses, c'est quand même limité.
sesearch -T --allow -s dhcpc_t | grep type_transition | grep process
va lister les domaines vers lesquelles dhcp_t peut faire une transition.
sesearch --allow -s dhcpc_t | grep execute
va lister les types que dhclient a le droit d'executer, la majorité sans avoir des droits différents de dhclient lui même ( vu qu'ils sont pas dans la première liste ).
Un rapide examen montre que dhcpc va écrire des fichiers d'un certain type, mais n'a le droit d'execution sur aucun de ceux qu'il va écrire. Donc ça bloque déjà les exploits à base de wget basique. Tu peux sans doute faire un truc avec wget + un interpreteur de commande ceci dit, mais tu sera toujours limité à ce que dhclient peut faire.
A vue de nez, le truc le plus prometteur serait insmod_t, mais je pense que insmod_t ne va pas charger n'importe quel fichier, et surtout pas un fichier que dhclient va écrire, pour cause de mauvais label.
Ensuite, je voit qu'un script pourrait couper le firewall, ce qui est un souci. Le reste, c'est de la manipulation de réseau, ce qui est chiant, mais dans la mesure ou ça implique un dhcp rogue, je pense qu'on peux supposer que le réseau n'a pas besoin d'une faille pour être modifier de façon créative.
Donc voila, je pense que selinux va bloquer assez efficacement la majorité des soucis, même si j'exclue pas qu'un truc passe à travers, ou qu'on puisse enchainer.
Quand à ssh, ça va marcher si le serveur ssh est openssh ou similaire, ie, un serveur ssh avec un shell. Je sais pas ce que ça donnerais sur les implémentations customs d'un serveur pour des besoins spécifiques ( genre github a son propre serveur git en ruby, si je me souviens bien, et ils semblent dire que leur service n'est pas vulnérable
https://github.com/blog/1893-security-vulnerability-in-bash-addressed donc je suppose que c'est pareil pour ssh ). Mais je suppose aussi que ce genre d'infrastructure est l'exception plus que la norme.