10.13 High Sierra Apple et la sécurité : préférer utilisateur standard?

[Remords Sincères]

Salut

Suite à ... encore... une énorme bourde de sécurité, 2eme énorme en l'espace de quelques semaines sur macOS, est-il devenu préférable de renoncer à une session Administrateur et préférer plutôt une sessions Utilisateur Standard pour l'usage de tous les jours, de façons à ce qu'une faille de sécurité puisse faire moins de dégâts qu'en étant loggé en Admin

Moi je commence à me poser sérieusement la question à savoir si renoncer aux droits d'Admin pour l'utilisation courante est pas plus judicieux vu qu'Apple a de très sérieux problèmes de sécurité ...

Z'en pensez quoi?

 

[ntx]

Depuis l'invention d'Unix (dont un des rejetons est Mac OSX), il a toujours été très très imprudent de travailler en permanence sous une session Admin. Je n'ai jamais compris pourquoi Apple ne met pas en garde ses utilisateurs pour qu'ils créent systématiquement une session avec un utilisateur standard.

 

[Remords Sincères]

Depuis l'invention d'Unix (dont un des rejetons est Mac OSX), il a toujours été très très imprudent de travailler en permanence sous une session Admin. Je n'ai jamais compris pourquoi Apple ne met pas en garde ses utilisateurs pour qu'ils créent systématiquement une session avec un utilisateur standard.

Ils le conseillent en fait, même dans leurs guides de sécurité, et ce depuis plus de 10 ans https://www.apple.com/support/security/guides/docs/SnowLeopard_Security_Config_v10.6.pdf (page 124)
ou ici https://support.apple.com/kb/PH25108?locale=fr_FR&viewlocale=fr_FR
Mais ces pages n'ont aucune visibilité si on ne les cherchent pas.
Peut être est-ce mentionné dans le mode emploi qu'ils donnent avec les macs?

Mais ouais, ça commence à se voir qu'il peut être dangereux d'être en permanence sous session Administrateur. Si Apple continue de coder son OS façon fromage Emmental avec des trous partout, ça va devenir fâcheux.

 

[litobar71]

salut,

la faille de root fonctionne avec une session standard également.

 

[Moonwalker]

D’un autre côté, si tu es l’administrateur de ton Macintosh, même sur une session standard, ça ne te prend pas des plombes de saisir ton login et ton mdp, et donc de faire n’importe quoi.

Que ce soit sur la session admin ou la standard, il n’y a rien qui s’installe ou se fasse sans la volonté de l’utilisateur.

Pour le bug de l’autre soir, moins de 24 heures et déjà le correctif (et le correctif du correctif), session admin ou standard ça n’avait aucune incidence.

Standard ou admin ça n’a d’incidence que sur la portée de certains softs. Et encore, avec le sandboxing, Gatekeeper, le SIP, il y a de moins en moins de répertoires qui restent accessibles en écriture sans une gymnastique avec l’interface.

L’important est de faire bien attention à ce qu’on installe du moment où cela réclame un mot de passe, qu’on soit sur une session admin ou non.

 

[Remords Sincères]

salut,

la faille de root fonctionne avec une session standard également.

Sans aucun doute !
Mais là il est question de limiter ses droits par rapport aux failles laissées régulièrement par Apple.
Si ton mot de passe vient à être corrompu sur une session admin, t'es foutu, le mec peut faire de ton mac ce qu'il veut.
Si t'es en utilisateur standard et qu'il a ton mot de passe, bah il a pas ton identifiant pour passer Admin et faire de gros dégâts sur le système, donc c'est une protection bien plus importante.

Après, le truc chiant, c'est que des mises à jour d'applis genre Chrome font chier quand on n'est pas admin.

 

[Moonwalker]

Tu te fais un cinéma. Sur une session standard le mot de passe local ne sert quasiment à rien. Il ouvre la session, il contrôle le trousseau local. So what ?

Le mot de passe utile est toujours administrateur. C’est celui-là qui est demandé, pas les autres. Si tu fais du travail d’administration (installer une application, modifier des réglages réseau ou de sécurité) tu peux le faire aussi bien de la session locale que de la session administrative. Il n’y a que sudo qui réclame une session administrative.

Le mot de passe admin n’est pas « corrompu », au pire il est contourné. Et là, session standard ou session admin, c’est du pareil au même.

La faille dangereuse ce n’est pas le dernier bug d’Apple qu’elle va s’empresser de corriger mais l’utilisateur, le mec qui clic à tout va et installe des logiciels dont il ne connaît ni la vraie nature ni l’origine. S’il est l’administrateur de la machine, rien ni personne ne pourra l’empêcher de mettre son système en danger.

La question n’est pas standard ou admin mais de savoir ce que l’on fait sur son Mac.

 

[Remords Sincères]

Tu te fais un cinéma. Sur une session standard le mot de passe local ne sert quasiment à rien. Il ouvre la session, il contrôle le trousseau local. So what ?

Le mot de passe utile est toujours administrateur. C’est celui-là qui est demandé, pas les autres. Si tu fais du travail d’administration (installer une application, modifier des réglages réseau ou de sécurité) tu peux le faire aussi bien de la session locale que de la session administrative. Il n’y a que sudo qui réclame une session administrative.

Le mot de passe admin n’est pas « corrompu », au pire il est contourné. Et là, session standard ou session admin, c’est du pareil au même.

La faille dangereuse ce n’est pas le dernier bug d’Apple qu’elle va s’empresser de corriger mais l’utilisateur, le mec qui clic à tout va et installe des logiciels dont il ne connaît ni la vraie nature ni l’origine. S’il est l’administrateur de la machine, rien ni personne ne pourra l’empêcher de mettre son système en danger.

La question n’est pas standard ou admin mais de savoir ce que l’on fait sur son Mac.

Bien sur que non c'est pas du pareil au même...
Sur une session locale, si le mot de passe local est contourné, le mec pourra rien faire de toutes façons sans l'id et mot de passe d'administration.
Si t'es sur une session administrateur, le type trouve ou contourne le mot de passe, il peut tout faire.
C'est une protection supplémentaire d'être en Standard, même Apple le dit. Et au vu des failles qu'ils laissent, c'est peut être pas incohérent de limiter son "pouvoir" en cas de gros problème.

Les types ont quand même réussi à dévoiler le mot de passe à la place de l'indice. Niveau conneries ça peut aller loin.

 

[Membre supprimé 1060554]

Les types ont quand même réussi à dévoiler le mot de passe à la place de l'indice

Il n'y a pas d'« indice » rempli pour le mot-de-passe root. Dans le fichier root.plist de l'utilisateur root (at: /private/var/db/dslocal/nodes/Default/users/root.plist) > la clé hint (indice) reste accompagnée d'une chaîne vide -->

<key>hint</key>
    <array>
        <string></string>
    </array>

parce que lors d'une définition de mot-de-passe pour root > il n'y a pas de possibilité offerte de remplir le champ d'un indice (aussi bien dans le panneau graphique de l'«Utilitaire d'annuaire» que dans une commande passwd ou dsenableroot du Terminal).

NB. Par contre, dans un fichier de type machin.plist de l'utilisateur machin localisé dans le même sous-dossier users > si l'utilisateur machin qui aurait choisi comme mot-de-passe clown > a jugé bon de remplir le champ de l'indice par un : "bouffon de cirque" > alors dans le fichier machin.plist > voici comment se présente le domaine de la clé hint :

<key>hint</key>
    <array>
        <string>bouffon de cirque</string>
    </array>

Il suffit d'une simple commande de lecture du fichier machin.plist comme :

sudo defaults read /private/var/db/dslocal/nodes/Default/users/machin.plist hint

pour que s'affiche l'indice du mot-de-passe de machin :

(
    "bouffon de cirque"
)

suite à quoi il ne faut pas être très malin pour essayer le mot clown comme mot-de-passe de machin. Un utilisateur soucieux de sécurité ne devrait jamais remplir le champ de l'indice pour son mot-de-passe > parce que la chaîne inscrite pour la clé hint dans son fichier machin.plist est lisible en clair par quiconque a un accès administrateur (ce qui est possible aussi bien en Single User ou dans le shell -bash-3.2# du Terminal d'une Recovery.

----------


Il n'y a pas eu non plus de « dévoilement » du mot-de-passe root. Comme j'ai tenté de l'expliquer dans un message récent rendant compte d'expérimentations (ici ☞La root est ouverte, message #33☜ ) --> l'utilisateur root possède toujours un mot-de-passe (même s'il est inconnu d'aucun utilisateur du Mac) > mais ce mot-de-passe peut se trouver associé à 2 valeurs symboliques dans le fichier root.plist qui est la carte d'identité de root -->

soit :

(
    "*"
)

càd. un astérisque simple > qui signifie qu'un mot-de-passe est défini pour root > mais avec la restriction associée suivante : ce mot-de-passe ne permet pas l'ouverture d'une session graphique sur le dossier de compte /private/var/root > mais permet par contre le passage dans un shell root# dans le Terminal ou le déverrouillage de panneaux des Préférences Système

soit :

(
    "********"
)

càd. 8 astériques > qui signifie que le mot-de-passe défini pour root se trouve implémenté de la permission d'ouvrir une session graphique sur le dossier de compte /private/var/root en plus des autres privilèges de ce mot-de-passe.

Il semble que la faille pour le mot-de-passe root intervenait en cas de valeur symbolique :

(
    "*"
)

dans le fichier root.plist > càd. dans le cas de figure où le mot-de-passe n'était pas implémenté de la permission d'ouvrir une session graphique. La saisie itérée (dans 2 panneaux d'authentification à la file du panneau Utilisateurs et groupes des Préférences Système) du nom d'utilisateur root sans saisie d'un mot-de-passe > déclenchait une erreur dans le protocole d'authentification qui équivalait à la saisie d'un mot-de-passe valide.

Pour autant > jamais le mot-de-passe root existant ne se trouvait exposé en clair à aucun moment.

 

[Remords Sincères]

Non mais là moi je parle du sketch avec le mot de passe de l'utilitaire de disque sur les volumes APFS.

 

[Membre supprimé 1060554]

Non mais là moi je parle du sketch avec le mot de passe de l'utilitaire de disque sur les volumes APFS.

Je ne comprends pas de quoi tu parles.

 

[Remords Sincères]

Je ne comprends pas de quoi tu parles.

De ça https://www.macg.co/os-x/2017/10/hi...mot-de-passe-des-volumes-apfs-chiffres-100019
Des bugs, glitchs, failles ou quelle que soit la façon dont on appelle ça, c'est simplement grotesque.
Et là, rebelote avec le compte root.
Donc quand tu vois que chez Apple ils ont visiblement des carences pour les trucs les plus élémentaires..

 

[Moonwalker]

Non mais tu n’as pas bien compris.

Ici on est dans les forums techniques, pas les réactions au news. On poste sérieux, concret, surtout dans le domaine de la sécurité.

Ça n’existe pas :

Sur une session locale, si le mot de passe local est contourné, le mec pourra rien faire de toutes façons sans l'id et mot de passe d'administration.
Si t'es sur une session administrateur, le type trouve ou contourne le mot de passe, il peut tout faire.

Il n’y a personne qui trouve ton mot de passe.

Les failles qui permettent un « gain de privilèges » visent les droits administrateurs ou root. Qu’importe la nature de la session par où elles s’incrustent.

Si par exemple, tu visites un site piégé qui permet à un attaquant un accès en root sur ta machine, que tu sois en standard ou admin ne changera rien à l’affaire. Il exploite une faille et tu es tombé dans le piège.

A partir du moment où tu es en possession du mot de passe administrateur, tu restes l’administrateur, même si tu opères depuis un compte standard. Quand un logiciel demandera ton mot de passe, il te suffira de remplir les deux cases avec les identifiants du compte administrateur et zooo.

Là où tu vas gagner en protection, c’est par exemple avec les scripts shell, car sudo ne peut opérer qu'à partir d’un compte muni des droits d’administration.

La faille qui est la plus exploitée sur le système est l’utilisateur et pas les bugs rocambolesques de Cupertino.

Combien de Macs compromis par la faille du compte root. Combien d’images disques chiffrées violée par la faille de l’APFS ? Aucun à ma connaissance.

Combien de personnes installent des adwares par inadvertance chaque jour ? Innombrables. On n’en a plein le forum. C’est à désespérer de lire des rapports EtreCheck.

 

[subsole]

Je plussois, autrement dit, c'est l'interface entre le clavier et la chaise qui est en cause.

 

[Moonwalker]

Avec un « s » à « violée » pour faire l’accord en nombre cela aurait été mieux. :oops:

Ce que je voudrais que comprenne bien Remords Sincères c’est que compte « standard » ou compte « admin » il ne s’agit que de l’environnement dans lequel vont s’exécuter les applications lancées par l’utilisateur. Un logiciel malveillant n’est qu’un logiciel conçu avec de mauvais objectifs. Alors, certes, son pouvoir de nuisance sera limité aux répertoires accessibles par le compte, et limité aux données personnelles pour un compte standard, mais justement c'est ce type de données qui est actuellement visé par ce genre de logiciels. Par exemple, un ransomware peut très bien ne chiffrer que le contenu du compte standard si l’utilisateur l’a installé.

Il n’est pas besoin d’être administrateur pour installer une application sur son Macintosh. Une application telle que Firefox se lance aussi bien depuis le bureau que depuis le répertoire /Applications et n’importe quel utilisateur peut créer un répertoire Applications qui lui soit personnel.

Un bon unixien, on ne devrait utiliser le compte administrateur qu’à des fins d’administration. Ceci est le principe. Dans les faits, sur macOS, on se retrouve tous avec un compte administrateur qui devient notre compte principal dès le premier jour d’utilisation, sans qu’on soit capable d’en estimer les enjeux.

C’est aussi pour cela qu’Apple a mis d’autres garde-fous tels que Gatekeeper pour trier, avec plus ou moins de succès, les applications sûres et le S.I.P. qui limite les accès à des répertoires très sensibles à l’administrateur lui-même.

 

[bompi]

Sur le plan des sessions et des droits, on peut remarquer incidemment que macOS se comporte comme Linux : on n'utilise pas root mais sa session a sudo à partir d'une session nominative (celle de la personne qui a installé ou activé le système).

J'ai essayé le billard à deux bandes : une session normale (la mienne) sans droits d'administration et une session pour l'administration. Tout en laissant root désactivé parce qu'ouvrir une session root directe ne présente aucun intérêt.

Le résultat est que cela n'apporte pas grand-chose en terme de sécurité puisque, comme @Moonwalker le fait justement remarquer, ce qui est risqué, c'est d'installer quelque chose en tant qu'administrateur et quelle que soit la configuration le résultat est le même...
Par ailleurs, ça a plutôt tendance à embrouiller les choses quand on souhaite utiliser des systèmes de paquetages supplémentaires, tel l'excellent Homebrew.

Bref, c'est le bon sens qui prime : il faut être prudent et faire confiance à bon escient (on est toujours obligé de faire confiance à quelqu'un, sauf à n'utiliser que de l'Open Source et passer des heures à vérifier toutes les lignes de code !)

Quant aux récentes bévues de macOS, elles font un peu "amateur" : c'est le côté grand public d'Apple, qui les empêche de pousser suffisamment à fond les tests (qui deviennent de plus en plus difficiles et longs). Mais ils ont réagi assez vite, avec pas mal d'à-propos.
Il va de soi que si on travaille dans un environnement requérant un haut niveau de sécurité, ce n'est pas sur macOS qu'il faut travailler.

PS : quand on a du temps et que l'on aime l'expérimentation, on peut utiliser des machines virtuelles, afin de tester l'innocuité d'une application, contrôler ses flux, ses accès disques etc.
De toute façon, on s'achemine vers des systèmes avec des containers bien étanches : macOS et iOS utilisent déjà des pseudo-containers, sous Linux on a des expérimentations intéressantes (par exemple Qubes OS, ou l'utilisation de Docker, etc.)

 

[Moonwalker]

J’en profite pour rappeler l’existence d’un petit logiciel très bien pour explorer les paquets d’installation : Suspicious Package.

Cela vous indique quoi s’installe où. Les .pkg comportent souvent des scripts shell ou autres, certains légitimes, d’autres beaucoup moins. N’oubliez pas que vous ouvrez les portes de votre système à chaque fois que vous saisissez votre mot de passe administrateur.