Discussion :

[Neckara]

Bonjour,

D'après ce que j'ai lu, l'attaque sushi consiste, à partir d'un exécutable appartement à root ayant le bit suid à 1, de créer un fichier shell avec un bit suid à 1 que tout le monde pourra modifier/exécuter.

Ainsi tout le monde pourra lancer un shell en tant que root.

Heureusement, il existe des mécanismes pour se protéger de cette attaque :
- quand un fichier est modifié par une autre personne que son propriétaire, le bit suid est mis à 0;
- lors de l'exécution de script, le bit suid est ignoré.

Mais quid de LD_LIBRARY_PATH ?
Si j'ai un exécutable avec le bit suid à 1, je peux modifier LD_LIBRARY_PATH et "remplacer" les fonctions appelée par mes propres fonctions grâce à l'édition des liens dynamiques (et donc exécuter ce que je veux avec les droits root).

Comment Linux fait-il pour se protéger de cela ? Quels autres mécanismes sont mis en jeux ?
Est-ce que les fichiers avec le suid à 1 sont trop "dangereux" ?


Existe-t-il un méthode plus "sûre" pour permettre à un utilisateur d'accéder de manière restreinte à une ressource uniquement accessible par le root ?

Exemple :
J'ai une liste et je ne veux que personne (à part le root) ne puisse le lire/écrire.
Mais je veux qu'un programme exécutable par tous puisse lire ce fichier pour par exemple produire un résultat différent selon l'utilisateur.

[disedorgue]

Bonjour,

Bonjour,
...
...
Mais quid de LD_LIBRARY_PATH ?
Si j'ai un exécutable avec le bit suid à 1, je peux modifier LD_LIBRARY_PATH et "remplacer" les fonctions appelée par mes propres fonctions grâce à l'édition des liens dynamiques (et donc exécuter ce que je veux avec les droits root).

Comment Linux fait-il pour se protéger de cela ? Quels autres mécanismes sont mis en jeux ?
Est-ce que les fichiers avec le suid à 1 sont trop "dangereux" ?

Si le setuid bit est positionné, le système ne prend pas en compte le LD_LIBRARY_PATH de l'utilisateur.

Existe-t-il un méthode plus "sûre" pour permettre à un utilisateur d'accéder de manière restreinte à une ressource uniquement accessible par le root ?

Exemple :
J'ai une liste et je ne veux que personne (à part le root) ne puisse le lire/écrire.
Mais je veux qu'un programme exécutable par tous puisse lire ce fichier pour par exemple produire un résultat différent selon l'utilisateur.

Pour ce genre de problème, tu as des commandes tel que sudo ou des concept de permission selon un certain contexte avec pam.

[Neckara]

Bonjour,

Merci pour votre réponse.
Donc comme le LD_PATH de l'utilisateur est ignoré, il est alors impossible d'effectuer un test avec valgrind sur un fichier ayant le bit setuid positionné si je comprend bien.

Pour ce genre de problème, tu as des commandes tel que sudo ou des concept de permission selon un certain contexte avec pam.

Utiliser sudo signifierait que que utilisateur connait ou peut connaitre le mot de passe root .
Pour PAM, j'ai du mal à comprendre, une fois l'utilisateur "authentifié" (ce qui au final n'est pas si utile vu qu'on souhaite que l'application puisse être lancé par tous et qu'on peut utiliser la commande "id" -?- au cas où on souhaiterait vérifier l'identité de l'utilisateur) il faudra bien faire une sorte "d'élévation de privilège" afin de pouvoir accéder à la ressource appartenant à root.

[disedorgue]

L'utilisation de sudo ne necessite en aucune manière que l'utilisateur connaisse le mot de passe de root.

Pour pam, tu as un module tels que pam-script mais il est vrai que se serait se compliquer la vie pour ton cas. Le sudo est amplement suffisant.

[Neckara]

L'utilisation de sudo ne necessite en aucune manière que l'utilisateur connaisse le mot de passe de root.

Tu veux dire qu'on pourrait rendre l'exécutable non lisible pour les utilisateurs et qu'on peut alors utiliser sudo et faire en sorte que l'exécutable entre lui-même le mot de passe utilisateur ? Ou modifier la "politique de sécurité" ?

[disedorgue]

Il n'y a pas de mot de passe à saisir, sudo permet d'executer une commande qui peut être un script avec les droit d'un autre utilisateur (même root), ceci se configure dans le sudoers. Mais, il faut bien faire attention au possibilité de la commande afin de ne pas créer une faille de sécurité.
Voir le man de sudoers pour plus de détails.

[Neckara]

Je suis sous Ubuntu donc pour moi sudo permet surtout de passer root (après je n'avais pas vu qu'il avait autant de fonctionnalité ).
Après, je ne sais pas si le mot de passe demandé est le mot de passe du root ou celui de l'utilisateur (vu que pour moi c'est le même... ).

Donc ce que tu me conseille, c'est un peu ce qui est écrit ici dans le man :

dgb boulder = (operator) /bin/ls, /bin/kill, /usr/bin/lprm

The user dgb may run /bin/ls, /bin/kill, and /usr/bin/lprm -- but only
as operator. E.g.,

$ sudo -u operator /bin/ls

Dans mon cas, l'utilisateur devra alors entrer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
sudo maCommande // si la ressource appartient à root
//ou dans le cas général
sudo -u maCommande

Par contre, il existe une option pour conserver l'environnement avec sudo.
Dans ce cas là, LD_LIBRARY_PATH sera aussi ignoré ?

[disedorgue]

Oui, l'exemple est pertinant...

Par contre, concernant l'env de l'utilisateur, celui-ci peut-être conservé sauf pour des variables sensibles tel que LD_LIBRARY_PATH (c'est écrit dans le man )

[Neckara]

Merci pour ta réponse,

Je pense que je peux mettre le sujet en résolu.