10.12 Sierra Prog téléchargé refusé

Celtia

Membre actif
11 Mars 2014
570
24
Bonjour à tous. Depuis peu sur Sierra, je télécharge de temps à autre quelques incontournables style Audacity. Mais quand je veux l'ouvrir, une fenêtre apparaît avec :
"Audacity" ne peut être ouvert car l'identité du développeur ne peut être confirmée." :meh:
Et on m'annonce qu'il y un truc avec les Préférences de Sécurité :shy:. Comment contourner ou tout simplement régler ce problème ?
 
Aller dans pref system / onglet sécurité et confidentialité / confidentialité et là vous devez trouver l'appli qui est supposé être installée
Cliquer sur ouvrir quand même, le mot de passe devra être rentré........
(je ne connais pas la manière pour que ce soit définiif.... si maco passait par là :coucou:)
 
C'est "clic droit" sur l'icône de l'application puis faire Ouvrir

Autrement Préférences Système / Sécurité et confidentialité / Général et cocher "Autoriser les applications téléchargées de : Mac App store et dev identifiés.
 
:coucou: peyret

je ne connais pas la manière pour que ce soit définiif.... si maco passait par là :coucou:

C'est la commande :
Bloc de code:
sudo spctl --master-disable
dans le «Terminal».

Son effet graphique est de restaurer dans le panneau Sécurité et confidentialité > Général > Autoriser les applications téléchargées de : l'affichage de l'option (pré-cochée) :

⦿ N'importe tout
 
le prefixe "sudo" n'a pas demandé mon mot de passe , est-ce normal ?

La cde a fonctionné en tous cas, si j'en juge ma copie d'écran

Capture d’écran 2017-08-31 à 19.54.43.png
 
Dernière édition:
le prefixe "sudo" n'a pas demandé mon mot de passe , est-ce normal ?

Normal : non. Avantageux : oui (si ça se poursuit). Une raison pourrait être l'attachement du setuid_bit sur l'exécutable sudo (astucieuse façon d'utiliser sudo sans jamais avoir besoin de s'authentifier).

Si tu veux le vérifier > passe la commande :
Bloc de code:
ls -al /usr/bin/sudo

  • qui retourne les permissions sur l'utilitaire sudo

=> tu n'as qu'à poster ici cette ligne pour vérification.
 
Voici le résultat :
Bloc de code:
imac-de-lucien:~ lucienpeyret$ ls -al /usr/bin/sudo
-r-s--x--x  1 root  wheel  369648 29 avr 02:30 /usr/bin/sudo

Que vient faire la date "29 avr 02:30" ?
 
Je trouve que cocher "n'importe où" n'est pas une bonne idée (du moins pour monsieur-tout-le-monde), voire est une vraie, mauvaise, idée.
 
Je trouve que cocher "n'importe où" n'est pas une bonne idée (du moins pour monsieur-tout-le-monde), voire est une vraie, mauvaise, idée.

Le vertueux Sly n'a encore rien vu --> cf. ce qui suit
361608_original.png


@peyret

Énigme résolue : tu as bien le setuid_bit (set_user_id_bit) attaché à l'exécutable sudo. Ce que montre cette ligne de permissions :
Bloc de code:
-r-s--x--x  root  wheel

Le - initial signale que l'objet est un fichier.

Ensuite > tu as les 3 triplettes de permissions affectées dans l'ordre à l'user > primary group > secondary group. Ce qui donne ici :

  • r-s pour l'user = root
  • --x pour le primary group = wheel
  • --x pour le secondary group = eveyone (toujours implicite)

Normalement > le maximum des permissions possibles pour chaque accédant sur un objet est rwx (read_write_execute : lire > écrire > exécuter). Les 2 groupes n'ont qu'une permission d'exécution x sur le fichier sudo > sans lecture ni écriture.

Si tu examines le cas de root à présent (l'user) : ses permission réglementaires sur le fichir sudo sont : r-x (lecture > pas d'écriture > exécution). Mais dans ton cas de figure > tu t'aperçois que le symbole x (= executable_bit) a été remplacé par s (= setuid_bit).

Le setuid_bit remplaçant l'executable_bit de l'user sur un fichier exécutable dont l'user est root a la signification suivante : l'identité de l'utilisateur initiataire de l'exécution du fichier dans un Terminal sera automatiquement substituée par l'identité exécutive de l'user root. Ainsi, si l'utilisateur peyret appelle sudo dans un Terminal > le setuid_bit fera que l'identité exécutive du processus sera automatiquement root. Ainsi, aucune demande d'authentification n'est requise.

Le setuid_bit fixé sur le binaire sudo m'a toujours paru un acte humoristique. Car l'utilitaire sudo chargé de gérer l'authentification d'un utilisateur qui veut se faire passer pour root > se trouve circonvenu a priori dans cette gestion d'authentification et transformé en une espèce de serviteur obéissant simplement chargé de leurrer le Système (il y a des commandes où il faut mentionner sudo).

[En ce qui me concerne > je suis un adepte invétéré du setuid_bit et j'en ai bien évidemment un attaché à l'utilitaire sudo. Avoir à taper en aveugle un mot-de-passe de 32 caractères alpha-numériques à chaque sudo : c'est gonflant. Et même si ce n'était pas le cas : passer un sudo sans authentification sudo me met en joie chaque fois
361608_original.png
]
 
Dernière édition par un modérateur:
  • J’aime
Réactions: peyret
Le vertueux Sly n'a encore rien vu --> cf. ce qui suit
361608_original.png


[cut]

Et même si ce n'était pas le cas : passer un sudo sans authentification sudo me met en joie chaque fois
361608_original.png
]

Je t'imagine bien te roulant par terre à chaque fois que tu passes un petit coup d'aspirateur de sudo :D
 
Je pense que le 29 avr 02:30 est la date à laquelle le fichier a été modifié pour la dernière fois.

Peut-être par l'attachement du setuid_bit ? Car si tu n'as pas tort de dire :
Oups, c'est pas simple l'explication....
qui a donc instauré le setuid_bit sur le fichier sudo localisé at : /usr/bin/sudo ?

Car ce n'est pas moi qui l'ai fait chez toi (de cela je suis certain). Or le setuid_bit n'est jamais instauré sur le fichier sudo par le Système (ça paraît évident). Si c'est donc un utilisateur (toi ?) qui a instauré le setuid_bit > ça n'a pu être que par une commande sournoise appelant l'utilitaire chmod avec une option spéciale et ciblée sur l'adresse du fichier sudo.

On peut supposer alors que l'utilisateur qui opère ainsi sait ce qu'il fait, le faisant. Donc que la fonction du setuid_bit ne lui est pas étrangère (ce qui fait que mon explication était superflue). Mais peut-être y a-t-il dans ton OS plusieurs utilisateurs admin? Si ce n'est donc pas toi qui a attaché le setuid_bit au fichier sudo > cherche alors du côté d'un autre utilisateur admin animé par des intentions sournoises...
361608_original.png
 
Je suis le seul utilisateur "admin" et du "mac", mais je suis pas sûr de ne pas avoir tapé dans le terminal une commande qui va bien, et le 02 avril de quelle année en plus ? !!!!

Merci en tous cas pour tes réponses "maco" :merci::merci::merci: bonne nuit !
 
  • J’aime
Réactions: gmaa
Attention ! ceci est un exercice de malice
361608_original.png

je suis pas sûr de ne pas avoir tapé dans le terminal une commande qui va bien

Hé ! hé ! c'est forcément toi si tu es le seul admin du Mac (à moins que quelqu'un n'ait opéré à ton insu dans ta session).

Pour substituer le setuid_bit à l'executable_bit sur le binaire sudo [ou sur tout autre exécutable dont l'user est root] > une commande possible est :
Bloc de code:
sudo chmod u+s /usr/bin/sudo

  • sudo est appelé pour autoriser l'utilitaire chmod à neutraliser récursivement le protocole d'authentification sur le binaire sudo (ce que je trouve marrant)

Évidemment > un utilisateur malicieux commence toujours par établir un setuid_bit sur le binaire chmod par une commande du type :
Bloc de code:
sudo u+s /bin/chmod

ce qui fait que l'utilitaire chmod appelé dans un Terminal par l'utilisateur machin est automatiquement exécuté avec l'identité de root. Par suite > pour inscrire le setuid_bit sur le binaire sudo > il suffit de passer la commande simple :
Bloc de code:
chmod u+s /usr/bin/sudo
(et ainsi de suite pour tous les autres binaires envisagés) - puisque chmod étant exécuté automatiquement avec l'identité de root grâce au setuid_bit > il n'y a pas besoin de passer par une authentification sudo pour modifier les permissions de... sudo.

Évidemment (pour rester dans le sujet de ce fil) > il aurait suffi à l'avance d'inscrire un setuid_bit sur le binaire spctl par une commande de type :
Bloc de code:
chmod u+s /usr/sbin/spctl
(en supposant que chmod porte le setuid_bit pour opérer en root sans sudo) > et la commande de désactivation du sous-système policier de surveillance du Système aurait été simplement :
Bloc de code:
spctl --master-disable
(sans avoir besoin de requête à sudo).

Manifestement > la mode du temps actuel n'est guère à cette liberté de "désinvolture consciente" à l'égard des contraintes d'un Système (on ne parle plus partout que de "garanties" et de "protection" - le moindre gamin sur un vélo, par exemple, se trouve affublé d'un casque de vététiste en cloche à fromage et tutti quanti). Donc évidemment la politique de la  va dans le même sens d'un vissage logiciel : du kext_signing de l'OS «Yosemite» > au SIP de l'OS «El Capitan» ou «Sierra» > au SIP renforcé de l'OS «High Sierra».

Un des effets du SIP étant de verrouiller au chargement des répertoires du Système, les répertoires de binaires (comme /usr/bin ou /bin) tombent sous le SIP. Donc un utilisateur (comme toi) qui veut inscrire un setuid_bit sur sudo > doit commencer par aller désactiver le SIP dans le «Terminal» de la Recovery afin de déverrouiller le dossier /usr/bin et pouvoir modifier les permissions sur sudo.

J'en déduis qu'il t'a fallu être motivé à l'époque (si tu es dans un OS "avec SIP") pour modifier les permissions de sudo mais que par la suite... tu as oublié ta propre rouerie.

Je reconnais que tel est l'inconvénient de modifier (même légèrement) des fonctionnalités du Système de macOS : il faut constamment garder présent à l'esprit - jusque dans le moindre détail - tout ce qu'on a modifié > ce, afin de ne pas se trouver débordé par les conséquences de ce qu'on a implémenté. Modifier sudo en y attachant le setuid_bit implique de toujours garder présent à l'esprit que sudo va désormais toujours s'exécuter sans authentification - pof ! aussi directement qu'une commande ls de listage.

Si tu voulais résilier le setuid_bit sur sudo > la commande serait chez toi :
Bloc de code:
sudo chmod u-s /usr/bin/sudo
(commande sudo sans authentification grâce au setuid_bit sur sudo > pour retirer le setuid_bit de sudo et restaurer la demande d'authentification). À condition évidemment que le SIP ne verrouille pas les répertoires du Système au chargement car si c'est le cas > il te faut faire un détour par le «Terminal» Recovery pour y désactiver le SIP au préalable...
 
Dernière édition par un modérateur:
Bonjour,
Juste pour dire que peyret n'est pas le seul avec
"-r-s--x--x 1 root wheel 369648 29 avr 02:30 /usr/bin/sudo"
Tous mes macs (Sierra) l'ont...
Sur mon vénérable iBook (10.4.11) c'est
"-r-s--x--x 1 root wheel 104588 déc 20 2006 /usr/bin/sudo"

Et je ne me sens pas "coupable" d'une commande sournoise…
Ceci dit, de confirmer l'ouverture ne me gène pas outre mesure.
 
Dernière édition:
Alors si c'est la maj Sierra qui le permet !!! donc Sierra est le coupable :D
 
Dernière édition:
Et vous voudriez me faire croire que serait le Système lui-même l'origine de cet excès de permissivité : laisser tout un chacun passer en root sans authentification ? - et le fichier sudoers alors - il sert à quoi ? Le même Système qui serre la vis à coup de SIP > distribuerait le sudo automatique à tous comme des billets de tombola gratuite à la foire à neuneu...

Je n'en crois rien. Vous êtes des crypto-déviants qui avaient censuré le souvenir de votre faute-
361608_original.png
 
  • J’aime
Réactions: Locke
Et vous voudriez me faire croire que serait le Système lui-même l'origine de cet excès de permissivité : laisser tout un chacun passer en root sans authentification ? - et le fichier sudoers alors - il sert à quoi ? Le même Système qui serre la vis à coup de SIP > distribuerait le sudo automatique à tous comme des billets de tombola gratuite à la foire à neuneu...

Je n'en crois rien. Vous êtes des crypto-déviants qui avaient censuré le souvenir de votre faute-
361608_original.png
:D