Je sais bien que la sécurité absolue, ça n'existe pas, je sais bien qu'il y aura
toujours des trous de sécurité. Je sais bien qu'on ne peut pas être sûr que les
mesures de sécurité mises en place ne seront pas détournée.
Ce que je cherche, ce n'est pas la sécurité absolue: la sécurité informatique
absolue, c'est de ne pas avoir d'ordinateur. Ce que je cherche, c'est comment
microsoft, apple ou redhat peut s'arranger pour rendre son système plus sûr
de façon notable sans faire chier le client. Car la sécurité, c'est avant tout
quelque chose de chiant et de pénible car c'est avant tout quelque chose qui
contrôle et qui interdit.
Je pars du constat qu'une machine windows non administrée se retrouve vite
bourrée de spywares, virii et autres. Si on excepte les virus de macro et les
chevaux de troye, ce genre de chose existe parce que du code à pu s'exécuter
sans que cela ait été voulu. Pour se protéger de ce genre de chose, il faut donc
éviter qu'un bug puisse conduire à l'execution arbitraire de code. Une première
approche consiste à empêcher cette exécution très tôt (W^X, malloc
randomisé, etc...). Maix comme tu le dis si bien, il se peut qu'un attaquant
arrive quand-même à faire exécuter son programme. Or l'une des premières
choses que l'attaquant va essayer de faire, c'est rendre cet exécution pérène.
Si un simple reboot permet de virer tous les spywares et tous les virus,
l'attaquant n'a pas gagné grand chose. Pour péréniser son attaque, il doit
pouvoir écrire sur le disque des informations. De plus, ces informations doivent
être exécutée de façon automatique. Ce que je propose a pour but de rendre
cette seconde étape plus difficile.
Si toutes les partitions sur lequel un utilisateur peut écrire sont montées en
noexec, c'est déjà un premier pas. Cependant, comme l'attaquant est fourbe,
il va trouver une faille de sécurité et arriver à devenir root. Dans ce cas, il
peut écrire dans /etc/rc2.d pour que son truc se lance au démarrage. Si
on s'arrange pour que root ne puisse pas écrire dans /bin /sbin /usr /lib...
et qu'un programme doive faire partir d'un de ces répertoires pour être lancé,
la tâche de l'attaquant devient plus dur: il doit trouver le moyen pour rendre
à root les droits d'écriture aux endroits ou il ne les a plus.
Evidemment, ce n'est pas complètement sûr mais ça complique la tâche de
l'attaquant.
[^] # Re: Bof
Posté par fmaz fmaz . En réponse au journal Espoir, quand tu nous tiens!. Évalué à 1.
Je sais bien que la sécurité absolue, ça n'existe pas, je sais bien qu'il y aura
toujours des trous de sécurité. Je sais bien qu'on ne peut pas être sûr que les
mesures de sécurité mises en place ne seront pas détournée.
Ce que je cherche, ce n'est pas la sécurité absolue: la sécurité informatique
absolue, c'est de ne pas avoir d'ordinateur. Ce que je cherche, c'est comment
microsoft, apple ou redhat peut s'arranger pour rendre son système plus sûr
de façon notable sans faire chier le client. Car la sécurité, c'est avant tout
quelque chose de chiant et de pénible car c'est avant tout quelque chose qui
contrôle et qui interdit.
Je pars du constat qu'une machine windows non administrée se retrouve vite
bourrée de spywares, virii et autres. Si on excepte les virus de macro et les
chevaux de troye, ce genre de chose existe parce que du code à pu s'exécuter
sans que cela ait été voulu. Pour se protéger de ce genre de chose, il faut donc
éviter qu'un bug puisse conduire à l'execution arbitraire de code. Une première
approche consiste à empêcher cette exécution très tôt (W^X, malloc
randomisé, etc...). Maix comme tu le dis si bien, il se peut qu'un attaquant
arrive quand-même à faire exécuter son programme. Or l'une des premières
choses que l'attaquant va essayer de faire, c'est rendre cet exécution pérène.
Si un simple reboot permet de virer tous les spywares et tous les virus,
l'attaquant n'a pas gagné grand chose. Pour péréniser son attaque, il doit
pouvoir écrire sur le disque des informations. De plus, ces informations doivent
être exécutée de façon automatique. Ce que je propose a pour but de rendre
cette seconde étape plus difficile.
Si toutes les partitions sur lequel un utilisateur peut écrire sont montées en
noexec, c'est déjà un premier pas. Cependant, comme l'attaquant est fourbe,
il va trouver une faille de sécurité et arriver à devenir root. Dans ce cas, il
peut écrire dans /etc/rc2.d pour que son truc se lance au démarrage. Si
on s'arrange pour que root ne puisse pas écrire dans /bin /sbin /usr /lib...
et qu'un programme doive faire partir d'un de ces répertoires pour être lancé,
la tâche de l'attaquant devient plus dur: il doit trouver le moyen pour rendre
à root les droits d'écriture aux endroits ou il ne les a plus.
Evidemment, ce n'est pas complètement sûr mais ça complique la tâche de
l'attaquant.