10.13 High Sierra Attention la root est ouverte

D

Deleted member 1099514

Invité
Salut à toutes et tous.

Je vous signale ceci :
http://www.macg.co/os-x/2017/11/macos-high-sierra-la-root-est-ouverte-tous-une-solution-100551

Un énorme bug (un de plus) de High Sierra.
Je ne m'étends pas sur le sujet, il est suffisamment détaillé.;)

Une solution très simple pour les terminalistes :D: donner un mot de passe à notre ami root par la commande :
sudo passwd root
un premier mot de passe vous est demandé pour la commande sudo. C'est le mot de passe administrateur.
Ensuite du classique pour le compte root.
Entrez un mot de passe et ensuite le confirmer.
Tous ces mots de passe se tapent en "aveugle" pour la sécurité (ils y ont pensé chez Apple).:D
 
  • J’aime
Réactions: Madalvée

guytoon48

Membre actif
1 Novembre 2011
817
81
65
Lozère
Bonsoir,
Mais quel besoin de relayer cette info avant même qu’Apple l’ait colmatée ??
 

guytoon48

Membre actif
1 Novembre 2011
817
81
65
Lozère
1er !!! Plus on ébruite le problème, plus on va tenter les malandrins. Çà aurait très bien pu être fait après. L’info a tout prix, pffft....
Et avec mode d’emploi...
 

guytoon48

Membre actif
1 Novembre 2011
817
81
65
Lozère
Réfléchir est aussi un effet de mode?
 

Fullcrum

OS Collector
Club MacG
5 Janvier 2016
4 180
1 059
Dole 39

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
86 354
26 242
Forêt de Fontainebleau
Personnellement parlant (càd. envisagé à mon échelle d'utilisateur et d'utilisation) : c'est le type de nouvelle dont je me bats l'œil (pour ne pas dire : me tamponne le coquillard).

Parce qu'au fond c'est mon imagination seule qui se trouve aiguillonnée : on lui demande d'envisager qu'un malandrin fantôme pourrait faire irruption dans mon domicile, en tombant par chance sur mon ordinateur allumé et ma session ouverte sans verrouillage d'écran en cas de mise-en-sommeil, pour aller tripoter les préférences-Système de mon OS. Bien curieux ce malandrin : il aurait à sa disposition l'espace de ma session avec mes données en accès libre mais la seule chose qui lui importerait, serait d'aller déverrouiller le panneau des Utilisateurs et groupes grâce à un bogue de root. Et pour faire quoi ? Pour se créer un compte personnel ? Lui permettant de modifier des réglages de l'OS ?

Comme ce scénario n'est qu'une mise-en-scène imaginaire (je le répète : à mon échelle d'utilisateur et d'utilisation - vu qu'aucun malandrin ne viendra s'immiscer dans ma session ouverte à tous les vents dans l'espace de mon domicile) - je dois dire que je n'« éprouve » rien de spécial en lisant ce genre de nouvelles. Et n'étant donc en proie à aucune combinaison d'imagination et de sentiment, je garde une parfaite neutralité d'esprit.

La seule chose qui serait intéressante, serait de se demander « théoriquement » quel fonctionnement logique permet de déverrouiller le panneau des Utilisateurs et groupes avec la saisie seule du nomcourt (root) du System Administrator sans accompagnement d'un mot-de-passe.

----------

Le Super-Administrateur existe pour le Système, en cela comme tous les autres utilisateurs personnels, parce qu'il possède une carte d'identité à son nom dans la base de données des utilisateurs de l'Open Directory (le service d'annuaire des utilisateurs). Cette base de données est le sous-dossier localisé at: /private/var/db/dslocal/nodes/Default/users. Ce sous-dossier users ne doit pas être confondu avec le répertoire /Users des comptes d'utilisateurs. Car dans users il n'y a que des fichiers plist définissant des existences d'utilisateurs pour le Système. Par exemple, supposons qu'un utilisateur toto existe, il n'existe pour le Système que parce qu'un fichier toto.plist (at: /private/var/db/dslocal/nodes /Default/users/toto.plist) le fait exister logiquement. Il en va de même pour root de ce point de vue : root n'existe logiquement comme utilisateur pour le Système, que parce qu'il existe un fichier "carte-d'identité" root.plist at: /private/var/db/dslocal/nodes/Default/users/root.plist.

Dans un fichier plist d'utilisateur, il y a une série de clés (ou rubriques) dont voici un résumé : gid (groupe d'appartenance) > home (adresse du dossier de compte d'ouverture de session) > jpegphoto (icône de login) > realname (Nom Complet ou Long Name) > name (Nom de Compte ou Short Name) > shell (/bin/bash par défaut) > uid (501 si 1er admin ; 0 si root). Une de ces clés est : passwd (mot-de-passe) qui peut se trouver associée à deux valeurs possibles (dans la chaîne associée à la clé) -->

soit :
Bloc de code:
<key>passwd</key>
    <array>
        <string>********</string>
    </array>
si un mot-de-passe existe pour l'utilisateur ;

soit :
Bloc de code:
<key>passwd</key>
    <array>
        <string>*</string>
    </array>
si aucun mot-de-passe n'existe pas pour l'utilisateur.

Il s'agit ici de désignations symboliques d'existence ou de non-existence d'un mot-de-passe - aucun mot-de-passe n'étant stocké en tant que tel dans un fichier plist d'identité d'utilisateur.

Par défaut > dans le fichier root.plist la situation est la suivante :
Bloc de code:
<key>passwd</key>
    <array>
        <string>*</string>
    </array>
càd. qu'aucun mot-de-passe ne se trouve défini pour l'utilisateur root.

Voici un bref aperçu de la carte d'identité root.plist : gid = 0 (groupe wheel) > uid = 0 > home = /private/var/root (dossier de compte) > realname = System Administrator > name = root > shell = /bin/sh > passwd = * (pas de mot-de-passe).

Il s'ensuit que l'utilisateur root existe a priori pour le Système sans mot-de-passe (*) --> la seule différence introduite par la définition d'un mot-de-passe pour root (********) étant la possibilité d'ouvrir une session graphique sur le dossier de compte localisé at : /private/var/root.

root ne se trouve donc nullement "activé" en tant qu'utilisateur par la définition d'un mot-de-passe > puisque root existe de par un fichier plist d'utilisateur indépendamment d'un mot-de-passe inexistant par défaut (*). La seule chose qu'active la définition d'un mot-de-passe root (********) est la possibilité d'ouverture d'une session graphique sur le dossier de compte de root at: /private/var/root. Et par extension la possibilité de renseigner une identité d'utilisateur graphique dans des panneaux d'authentification affichés par le Finder. C'est donc un avatar d'utilisateur graphique de root qui se trouve activé avec la définition d'un mot-de-passe root.

Il est évident que lorsqu'un panneau d'authentification est affiché par le Finder > le nom et le mot-de-passe renseignés sont comparés par le Système aux paradigmes du fichier plist de l'utilisateur. En cas d'astérisque simple * à la clé passwd dans le fichier plist - comme c'est le cas par défaut pour root - càd. absence de mot-de-passe > le Système doit retourner un échec d'authentification.

Il serait intéressant ici que des ingénieurs informaticiens (ce que je ne suis pas) expliquent en quoi le protocole de vérification du Système s'est trouvé pris en défaut par un bogue dans High Sierra > en ne retournant pas un échec d'authentification en cas de non saisie d'un mot-de-passe (blanc) pour le nom root, alors même que dans le fichier root.plist ce n'est pas un mot-de-passe vide existant qui se trouve a priori défini > mais une absence de mot-de-passe (*). Ce qui n'est pas le même chose.

----------

Pour terminer par un peu de technique :

Une commande
Bloc de code:
sudo defaults read /private/var/db/dslocal/nodes/Default/users/root.plist passwd
lit la valeur actuellement associée à la clé passwd dans le fichier root.plist. Si elle retourne un :
Bloc de code:
(
    "********"
)
c'est qu'un mot-de-passe d'utilisateur graphique a été défini pour root ; si elle retourne un :
Bloc de code:
(
    "*"
)
c'est qu'aucun mot-de-passe d'utilisateur graphique n'est actuellement défini pour root (situation par défaut).

Pour quelqu'un qui veut définir un mot-de-passe d'utilisateur graphique pour root > l'utilitaire spécialisé à cette fin est dsenableroot (directory_service_enable_root : habiliter root dans le service d'annuaire). Voici la syntaxe de la commande :
Bloc de code:
dsenableroot -u username -p userpassword -r rootpassword

  • l'option -u (user = utilisateur) étant accompagnée de la saisie du nomcourt ou nomdecompte de l'utilisateur > l'option -p (password ou mot-de-passe) étant accompagnée de la saisie de son mot-de-passe (privilège admin requis) > l'option -r (root) étant accompagnée de la saisie du mot-de-passe choisi pour root. Tout s'affichant en clair à l'écran.

Exemple : supposons un utilisateur (admin) dont le nomcourt (ou nom de compte) soit toto > et dont le mot-de-passe soit toto > et que ce toto veuille définir pour root un mot-de-passe qui soit également root --> la commande devient :
Bloc de code:
dsenableroot -u toto -p toto -r root

toto devra renseigner en aveugle son mot-de-passe toto > et la validation de la commande est confirmée par :
Bloc de code:
dsenableroot:: ***Successfully enabled root user.
 
Dernière édition:

Spec

Membre actif
24 Août 2008
208
14
Juste une question depuis que j'ai essayé la faille, en ouverture de session j'ai un compte "autre" qui est apparu et impossible de l'enlever dans les préférences systèmes(utilisateurs et groupes) vu qu'il y a l'administrateur et invité mais pas "autre". Y'a une solution pour l'enlever ?
 
D

Deleted member 1099514

Invité
Juste une question depuis que j'ai essayé la faille, en ouverture de session j'ai un compte "autre" qui est apparu et impossible de l'enlever dans les préférences systèmes(utilisateurs et groupes) vu qu'il y a l'administrateur et invité mais pas "autre". Y'a une solution pour l'enlever ?
Tu es sur quelle version Mac os x?
Tu peux tenter la commande (dans le terminal) :
sudo fdesetup remove -user Guest
Ou :
sudo defaults write /Library/Preferences/com.apple.loginwindow SHOWOTHERUSERS_MANAGED -bool FALSE
 
Dernière édition par un modérateur:

Spec

Membre actif
24 Août 2008
208
14
Je suis sous H Sierra. J'ai réussi à l'enlever dans "Utilitaire d'annuaire" en désactivant le root. Mais en le désactivant ça peut être un problème ? Car perso j'avais jamais entendu "root" depuis hier soir....
 
Dernière édition:
D

Deleted member 1099514

Invité
Je suis sous H Sierra. J'ai réussi à l'enlever dans "Utilitaire d'annuaire" en désactivant le root. Mais en le désactivant ça peut être un problème ? Car perso j'avais jamais entendu "root" depuis hier soir....
Tu peux tenter avec la ligne de commande :
sudo passwd root
comme indiqué dans mon post #1
 

Spec

Membre actif
24 Août 2008
208
14
Ok merci je vais essayé.
 

jmtweb

Membre actif
15 Octobre 2015
515
102
"Attention la root est ouverte..."

La root est sacrément accidentée (miniature ci-dessous), vous en conviendrez.
Quand mon GPS me propose un itinéraire de délestage faisant gagner quelques minutes, je ne m'en prive pas.
Sierra est la voie de la sagesse en attendant que la voie principale soit correctement signalisée.

High Sierra.jpg
 
  • J’aime
Réactions: jeanjd63