macOS Catalina peut bloquer certains exécutables UNIX par défaut
Apple a encore renforcé les mesures de sécurité par défaut de macOS Catalina. La dernière version de son système d’exploitation pour Mac empêche les apps d’enregistrer l’écran ou votre utilisation du clavier à votre insu, mais elle bloque aussi plus fermement l’accès à de nombreux dossiers, y compris votre bureau et les documents. Ces sécurités ne s’appliquent pas qu’aux apps, elles concernent aussi les outils UNIX, ceux que l’on exploite en passant par un terminal.
C’est ce qu’a découvert un développeur en notant que ses cron ne fonctionnaient plus après la mise à jour vers Catalina. Pour faire (très) simple, cron est un système d’automatisation qui permet d’activer des scripts ou des commandes de terminal à intervalles réguliers. C’est un outil extrêmement courant, surtout utilisé sur les serveurs, mais qui peut également servir sur macOS.
Avec Catalina, cron est soumis aux mêmes règles que les autres apps. Le système bloquera ainsi l’exécution d’un script Shell qui touche aux fichiers dans l’un des dossiers protégés, y compris vos documents. L’ajout de sudo, qui permet sur les systèmes UNIX d’obtenir les droits administrateur, n’y fera rien, c’est un blocage plus bas niveau qu’Apple impose. Fort heureusement, il existe des solutions pour contourner ces protections, même si le constructeur ne les met pas du tout en avant.
La plus radicale est de désactiver totalement SIP, auquel cas les commandes UNIX retrouvent toute leur liberté1. Faites attention toutefois, votre Mac sera alors plus largement ouvert, contre des logiciels malveillants et aussi contre les bourdes de certaines apps. C’est la mésaventure qui est arrivée récemment à certains utilisateurs de Chrome sur des Mac sans SIP, un bug dans le programme de mise à jour du navigateur effaçait des fichiers essentiels au bon fonctionnement de macOS.
Une solution plus raisonnable consiste à autoriser cron et les autres exécutables bloqués par Catalina. Pour ce faire, c’est exactement comme pour les apps : ouvrez les Préférences Système, puis le panneau « Sécurité et confidentialité ». Dans l’onglet « Confidentialité », choisissez « Accès complet au disque » sur le côté et ajoutez les exécutables en fonction de vos besoins. Dans le cas de cron, il faut ouvrir le dossier /usr/sbin/ pour l’ajouter à cette interface et débloquer son fonctionnement.
On comprend pourquoi Apple procède ainsi, notamment avec cron qui peut être un excellent moyen, pour un malware, de se réinstaller dans votre dos et à votre insu si vous le supprimez. Néanmoins, c’est aussi un outil utilisé par de nombreux utilisateurs, des développeurs en particulier. L’absence d’explications, ou ne serait-ce que d’un message d’erreur, est un problème, surtout pour un processus qui est censé tourner en arrière-plan et sans retour visible.
Pour terminer, rappelons que macOS dispose de son propre système équivalent à cron et qui n’est pas bloqué par macOS Catalina : launchd. La configuration est un petit peu plus complexe, mais si vous avez besoin d’exécuter régulièrement une commande sur votre Mac, c’est probablement la meilleure option.
-
Vous trouverez les informations pour désactiver ou réactiver SIP dans cet article. ↩
Personne ne rencontre le soucis du double écran sous Catalina ?...
Ce n'est pas le sujet ici. Ouvre un thread sur le forum.
Oui c'est vrai
👍 macg ! Merci.
Màj Catalina 15.1 ce matin et gros blocages : Musique ne répond plus, Mail idem, App Store idem. Même après redémarrage. Probablement encore la connexion WiFi qui défaille ?
@Mac Hiavel
Mac OS câlin 😑
Sinon ils peuvent carément enlever la partie unix et revenir a un noyau proprio façon macos 9, comme ça tranquille ...
C’est en train de devenir un unix de plus en plus castré, enfin dans la même logique que la connectique, l’upgradabilité du matériel ou certains utilitaires (utilitaire disque, utilitaire airport, ex utilitaire résezu, etc, etc...)
Y a intérêt a se faire un double boot Linux ou garder des anciens macOS en machines virtuelles quand on aime le shell !
Encore merci Cook de nous laminer le Mac un peu plus chaque année ...
@melaure
Suffit de désactiver SIP pour retrouver un mac à l’ancienne.
@reborn
Suffit de ne pas stériliser le bistouri pour se retrouver avec une septicémie à l’ancienne.
Comme au Moyen Âge.
@occam
Entre SIP et la liberté de faire ce que tu veux de macOS il faut choisir.
Un macOS sans SIP, c’est comme un linux.
Ici il veut même garder des anciens macOS qui disposent de plus de liberté. Le mieux à faire c’est de désactiver SIP pour se retrouver avec l’équivalent d’un OS X Yosemite.
Le S.I.P. est une fonction Unix.
Il n'y a rien à choisir. Comme le précise l'article, les commandes Unix sont parfaitement utilisables sous S.I.P. via une petite manipulation.
Le problème ici est un manque de documentation de la part d'Apple (une vieille habitude).
@Moonwalker
Il parle de manière générale de tous les ajouts sécuritaire de la part d’Apple (ras le bol)
Je lui donne la solution extreme déjà donné dans l’article pour retrouver un macOS d’antan. Je suis pas le seul à le dire le macOS d’antan avec un vrai utilisateur root c’est celui d’avant El Capitan qui n’était pas équipé des fonctionnalités SIP.
Si tu veux aller sur ce chemin, retournons ensemble sur Mac OS X Tiger, le "vrai" Mac OS X, non certifié Unix, sans les ACL, avec sa base NetInfo, son coupe-feu IPFW, son serveur Apache, et tutti quanti. C'était sympathique mais je préfère vivre avec mon temps.
@reborn
"macOS sans SIP c'est comme un Linux"
https://thehackernews.com/2019/10/linux-sudo-run-as-root-flaw.html
Et c'est joyeux.
@Moonwalker
D’où le SIP d’Apple, désactivable pour les power users qui maitrisent leur machine.
À chacun ses choix ;)
@ melaure : « Sinon ils peuvent carément enlever la partie unix et revenir a un noyau proprio façon macos 9, comme ça tranquille ... »
Ah ? Juste parce que les outils Unix sont traités à égalité avec les autres applications (et donc nécessitent le même octroi manuel de droits) ? Hé bé…
Moi, je trouve ça très bien comme ça. Ça limite l’usage de ces outils aux gens qui connaissent un minimum leur OS et son fonctionnement. ;-)
Précision : je parle du correctif 10.15 proposé hier soir et non de 10.15.1 qui est en bêta.
Problème iCloud ou WiFi ?
Bonjour Nicolas.
As-tu remarqué que depuis même Mojave, des utilitaires exécutables se trouvaient amputés d'options classiques (quoique leur man continuent de les documenter) ?
Par exemple : l'option -e (d'affichage des ACL) n'est plus supportée avec la commande ls (retour : ls: invalid option -- 'e'). De même les options de manipulations d'ACL (comme +a) pour la commande chmod. Je n'ai pas sous la main de liste de toutes les restrictions que j'ai pu noter au passage.
@ macomaniac :
Sous Mojave, je n’ai (heureusement) pas le souci que tu mentionnes.
Même en autorisant certains binaires il y a des ratés. Impossible de lancer un MariaDb (homebrew) via launchd.
J’ai pas encore trouvé la solution.
=> https://discussions.apple.com/thread/250719819
J’ai remarqué un soucis de droit lorsque je lance apache avec un vhost pointant sur un dossier sur mon bureau. Ça doit être la même logique que pour le cron. Je testerai...
Le problème quand même de ces restrictions, c'est que le développeur qui s'appuie sur certains de ces exécutables, va devoir demander aux utilisateurs de ses applications d'aller donner l'accès à tout le disque à ces exécutables, un par un (sachant que parcourir l'arborescence du système pour trouver l'emplacement de ces exécutables est tout sauf évident pour l'utilisateur novice qui va devoir le faire)
D'une part l'utilisateur novice peut inquiéter de devoir le faire (et rendre donc l'application en question beaucoup moins "user friendly") mais de plus si, par exemple, CRON est autorisé à accéder à tout le disque pour une application pour laquelle cet accès est légitime, CRON se retrouve autorisé pour toutes les apps l'utilisant (y compris pour celles pour laquelle c'est beaucoup moins légitime)
@ SyMich :
En effet, il serait malvenu qu’un application pousse un utilisateur à donner ce genre d’autorisation à cron.
Mais heureusement, le problème ne se pose pas vraiment, car un développeur d’application pour Mac est censé utiliser launchd et non cron, et il intègrera dans le paquet de son application les exécutables à lancer en fond, afin qu’ils profitent des autorisations d’accès accordées à l’application.
Du coup, du point de vue de l’utilisateur, il ne devrait y avoir qu’à régler les autorisations d’accès de l’application.
Sauf pour d’éventuels très rares cas de trucs sortant des sentiers battus mais s’adressant généralement à un public averti et capable de gérer ça.
Je citais cron juste parce que c'est l'exemple cité dans l'article. Mais ça fait un paquet d'année qu'Apple a demandé de passer à launchd...
Je n'arrive plus à utiliser une application qui semble être un exécutable UNIX.
Il s'agit d'IRAMUTEQ qui est un logiciel créé à l'université comme interface de R.
J'arrive à le lancer en passant par le logo de l'exécutable contenu dans un dossier en passant par le contenu du paquet du logiciel mais rien ne se passe si je clique directement sur le logo de l'application.
J'ai essayé d'ouvrir les droits (IRAMUTEQ et R) comme indiqué dans le fil de discussion mais ça ne fonctionne toujours pas.
Quelqu'un aurait-il une solution à ce problème ?