sudo

[bompi]

Bonjour,

un petit retour sur sudo et son bug.

La commande sudo a plein d'options auxquelles on ne prête pas attention. L'une d'elle est désactivée par défaut par Apple dans Mac OS X : tty_tickets. Depuis que je suis sur mac OS X ça me tracasse et je trouve que c'est une faille de sécurité importante (j'y ai déjà fait allusion par le passé).

Pour faire simple : vous ouvrez un Terminal et créez un deuxième onglet (ou fenêtre, peu importe).
Vous tapez dans le premier onglet

sudo ls

et ça vous demande votre mot de passe puis exécute la commande.
Vous tapez derechef la commande dans le second onglet et là, paf! ça s'exécute sans rien demander.

Si on active l'option tty_tickets, la deuxième fois le mot de passe sera de nouveau demandé. En clair : le ticket obtenu n'est valable que dans le shell (plus exactement : le TTY ou terminal) pour lequel il a été obtenu.

Comme par défaut cette option est désactivée, cela signifie que si vous utilisez sudo dans un shell, pendant cinq minutes, n'importe quelle application pourra passer en douce une commande en mode administrateur. Pratique...

Ce n'est pas une faille per se mais un fonctionnement. Simplement il est risqué

Par ailleurs, activer l'option permet apparemment d'éviter le bug en cours : en tout cas, mes petits tests me le font penser.
Bien entendu la modification est à faire avec prudence (garder une copie de secours du fichiers /etc/sudoers) : elle consiste à ajouter la ligne

Defaults        tty_tickets

dans le fichier. Utiliser la commande visudo pour effectuer la modification.

---------- Nouveau message ajouté à 18h42 ---------- Le message précédent a été envoyé à 18h23 ----------

Flûte. Je conseille toujours la modification pour le fonctionnement général, mais pour le bug cité, ce n'est pas mieux (c'est idiot : les fichiers par TTY restent présents au lieu d'être supprimés, tsss...)
Cf. la discussion ici.

 

[geranium]

Merci pour l'info. Espérons une mise à jour rapide de la part d'Apple.

Ce bug concerne t-il aussi les autres Unix/Linux ?

 

[edd72]

Ce n'est pas un bug, c'est juste un choix d'option implicite par défaut (pas forcément bienvenu mais c'est le choix d'Apple), qui peut être différents dans les autres Unix (Solaris, AIX, HP-UX, BSD) ou dans les diverses distributions GNU/Linux.

 

[ntx]

Ce bug concerne t-il aussi les autres Unix/Linux ?

J'ai lu par ailleurs que ce "bug", disons plutôt "faille", concernait aussi certains Linux.

 

[bompi]

Histoire de bien être précis, on a :

a) la configuration de sudo [un sujet qui me titille depuis Panther] : il vaudrait mieux qu'Apple la revoit pour améliorer la sécurité de son système, où l'utilisateur usuel (le premier utilisateur du système) est un sudoer.
l'autre méthode sera de n'utiliser par défaut qu'un compte non sudoer comme Apple le conseille par ailleurs.

b) une faille dans sudo [objet du papier de MacG] : où revenir à EPOCH est dangereux parce que le programme est un peu léger sur la gestion de ses tickets.

 

[Membre supprimé 1060554]

@bompi.

Ne penses-tu pas que, dans les 'Sudoers Options', ramener le paramètre timestamp_timeout (lequel, par défaut, établit à 5' le délai avant lequel sudo passera une nouvelle demande de 'passwd') à 0', pourrait corriger la faille, en ce qu'un nouveau passwd serait exigé chaque fois?

<encore faudrait-il que cette préférence ne soit rétro-éditable par aucun autre sudoer sauf l'admin 'ab_origène' (lui seul 'rootable' par ailleurs), ni qu'elle ne soit surpassée par une manipulation de l'horloge rétablissant l'epoch d'UNIX - comme raconté dans la page dont tu as fourni le lien, ce qui paraît opérer comme si le paramètre booléen du timestamp_timeout avait été établi en-dessous de 0 à une valeur négative, de manière à ce que sudo ne passe plus de demande de passwd>

L'inconvénient étant que la réitération de la demande de passwd pour un sudoer peut rapidement s'avérer 'gavante' - pour moi, par exemple, qui ai un mot-de-passe admin alphanumérique de 33 caractères

 

[bompi]

Oui, c'est sûrement le mieux pour obvier à l'erreur en attendant mieux (de la part d'Apple). Mais pour le coup, ce n'est vraiment plus très pratique, sauf à faire un sudo -s une bonne fois.
C'est de fait ce que je suis amené à faire à l'occasion En fait je suis sous une session non-admin et j'ai :
- un shell loggé sur l'administrateur dans lequel j'utilise sudo à plein
- traficoté sudoers pour autoriser mon compte à exécuter quelques commandes inoffensives (certaines sans mot de passe... oups!)

On peut, aussi bien, installer une version à jour de sudo, bien entendu.