macOS Catalina : coup de mou pour la notarisation des applications
Le notaire d'Apple est un peu fatigué de tamponner toutes les nouvelles applications pour macOS. Plusieurs développeurs se plaignent sur Twitter que l'opération de certification de leurs apps (un processus à réaliser depuis Xcode) soit très long : cela peut demander plusieurs heures alors qu'habituellement, le processus est accompli en une heure tout au plus.
Il va falloir que le constructeur muscle sérieusement ses serveurs, car depuis macOS Catalina, toutes les apps distribuées en dehors du Mac App Store doivent avoir reçu leur estampille pour s'installer par défaut. Le processus permet de s'assurer que le logiciel ne contient pas de composants malveillants. Les apps disponibles dans la boutique d'Apple sont bien sûr certifiées.
La page de statut des services pour les développeurs confirme qu'il y a bien un problème avec la notarisation, le tuyau devrait donc être débouché sous peu. Les utilisateurs sûrs et certains de l'innocuité d'un logiciel non notarié peuvent toujours contourner cette protection (control-clic ou clic droit sur l'icône de l'app, puis sélectionnez Ouvrir).
Non mais l'un repose sur l’autre.
Gatekeeper ne mentionnait que les apps non signées. Là en l’occurence, Gatekeeper en détectant le ticket généré par la notarisation et attribué à l’app, pourra informer et rassurer l’utilisateur de l’absence de malware ou du risque à lancer l’app si elle n’a pas été notariée (même si le ticket est bon, Gatekeeper informe quand même de l’origine internet de l’application et si on veut l’ouvrir).
La stratégie anti-malware vaut ce qu’elle vaut, elle est faillible mais la notarisation a quand même le mérite d'offrir une sorte d’authentification à deux facteurs au cas où l’ID serait corrompue. Dans tous les cas, il faut qu’Apple s’assure que le checking soit rapide et que ça ne prenne pas des heures.
En terme de limite par rapport à la détection de malware, le cas le plus problématique à mon sens est la mise à jour d’une app (pas ton exemple alambiqué). Effectivement, une app peut être distribuée propre mais se voir gratifier d’une mise à jour automatique cochonnée, qui évidement échappe aux processus d’Apple.
Je ne sais pas si le scénario est alambiqué (je disais dès le départ que c'était un peu tiré par les cheveux), je voulais juste essayer de traduire concrètement ce que décrivait Byte-Order parce que visiblement vous ne vous compreniez pas tous les 2. Cela dit, on voit bien régulièrement des adwares être validés sur l'AppStore, donc pourquoi ne se feraient-ils pas notarier...
Concernant les mises à jour d'applications, elles doivent évidemment être également notariées. A chaque mise à jour il faut faire notarier l'utilitaire de mise à jour ET l'application dans sa nouvelle version, pour que les utilisateurs puissent lancer sur leur Mac l'updater, pour ceux ayant déjà l'application, ou l'application dans sa nouvelle version (pour ceux pour qui ceux qui téléchargent la nouvelle version complète). Ça risque de retarder les mises à jour si le processus n'est pas rapide.
Le principe de base de cette notarisation c'est de s'assurer que l'application lancée sur un Mac est bien strictement la même, à l'octet près, que celle qui a été soumise à Apple (pour éviter qu'une application vérolée soit utilisée). Il faut donc bien que le processus intégré chaque mise à jour "légitime" des applications notariées.
@SyMich ,
Non il ne me semble pas.
Les applications non sandboxées peuvent supprimer les attributs, dont ceux présents dans leur propre bundle. Par conséquent, une application téléchargée via internet peut télécharger une nouvelle version d’elle-même, enlever l’attribut quarantaine ajouté lors du téléchargement et ainsi ouvrir une nouvelle version en ayant outrepasser Gatekeeper.
Au final, une application initialement notariée et donc « clean » peut avoir le droit se lancer mais se mettre à jour ensuite avec une app cochonnée.
Non les applications mises à jour doivent également être notariées. Et heureusement, sinon c'est tout l'interet, en terme de sécurité, de ce processus qui disparaît!
Le Notaire de Catalina vérifie que l'application qui se lance est strictement celle que le développeur a soumis à Apple, à l'octet près, pour garantir qu'elle n'a subit aucun changement qui pourrait être le signe de l'inoculation d'un malware.
Bien non, c’est bien la limite du procédé :
Le développeur Jeff Johnson écrit :
« When you download a Mac app from the internet and open it for the first time, you see a macOS Gatekeeper dialog that asks "Are you sure you want to open it?" Have you ever noticed, though, that when you update the app to a new version using the app's built-in software update mechanism, you don't see a Gatekeeper dialog on first launch? This is because Gatekeeper only asks you about apps that are "quarantined". When you download a file from the internet, the web browser adds a com.apple.quarantine extended attribute to the file in the file system, and Gatekeeper checks for this attribute. Mac apps that aren't sandboxed have the ability to delete extended attributes on files, even extended attributes on their own app bundles. Therefore, a Mac app that you download from the internet has the ability to download a new version of itself, remove the quarantine on the new version, and then open the new version without a Gatekeeper dialog. This has been true for as long as Gatekeeper has existed.
The most widely used software update mechanism outside the Mac App Store is called Sparkle. Thousands of popular apps have adopted the Sparkle framework. If you look at the source code for Sparkle and search for "quarantine", you can see where Sparkle deletes the com.apple.quarantine extended attribute after it downloads the update. This is perfectly normal and expected, nothing underhanded or nefarious. In fact, Sparkle also checks the code signature of the downloaded update before opening it to make sure it has been signed with a valid Developer ID certificate, just as Gatekeeper does. Mac apps can also perform additional, custom validation checks relevant to their own specific situation to make sure that the update is authorized and hasn't been tampered with.
The ability of Mac apps to update themselves shows that the notarization malware scan is security theater. Apple's notarization service scans for malware, but malware authors don't need to submit malware to Apple! They can submit a perfectly innocent app for notarization, get the app notarized, and then flip a switch on their own server to download a malware software update when the victim opens the "innocent" notarized app. The downloaded malware update doesn't need to be notarized, because the software updater will delete the quarantine attribute, thus bypassing Gatekeeper. It's impossible for Apple to detect this beforehand, because the malware update won't be made available for download until after Apple notarizes the original app. »
Je suis surprise de ce qu'il décrit car ce n'est pas ce que j'ai compris des nouvelles contraintes que nous impose la notarisation. Ce qu'il décrit correspond au fonctionnement de GateKeeper et justement la notarisation doit apporter un niveau supplémentaire de vérification et empêcher une modification ultérieure des applications (que ce soit à l'initiative du développeur ou à son insu).
On verra à l'usage... mais si ce qu'il dit est vrai, alors cette notarisation n'apporte aucune sécurité alors qu'elle met des contraintes aux développeurs et développeurs.
Non pas complètement inutile car il permettrait d’empêcher un Apple ID d’être utilisé de manière non autorisée et serait donc une sorte d’authentification à deux facteurs.
Un développeur ne souhaitant pas avoir d'identifiant développeur chez Apple (ne serait-ce que parce que ça coûte 100$/an) peut faire notariser ses applications!
C'est l'application qui recoit un "certificat de bonne conduite". Ça n'a pas de lien avec l'appleID du développeur.
Si les mises à jour ne sont pas notarisees (mais j'ai compris l'inverse), le scénario que décrit Jeff Johnson est parfaitement possible et risque de faire des dégâts! Qui se méfiera d'une application dûment notarisee par Apple? On l'installera et on lui donnera tous les accès qu'elle demandera sans se méfier (ce n'est pas pour rien que les adwares et malwares qui apparaissent régulièrement sur l'AppStore sont des faux antivirus ou des faux anti malwares. On donne son mot de passe administrateur sans se méfier à ce genre d'utilitaires car ça leur est indispensable pour faire le boulot qu'ils prétendent faire)
Bien sûr que non, il faut un Developer ID pour notarier une application ! Le service de notarisation scanne l’app signée avec l’ID et fait le check de sécurité (puis attache un ticket qui est lu par Gatekeeper).
Apple décrit la fonction comme suit :
« Give users even more confidence in your software by submitting it to Apple to be notarized. The service automatically scans your Developer ID-signed software and performs security checks. When it’s ready to export for distribution, a ticket is attached to your software to let Gatekeeper know it’s been notarized. »
Ah oui exact... je ne suis pas concernée car j'ai mon développeur ID, mais je pensais qu'un développeur ne souhaitant pas dépenser 100$/an pouvait quand même faire notariser ses applications (je pense notamment à plusieurs développeurs qui diffusent des utilitaires gratuitement faisant cela sur leur temps libre ou par passion et n'en tirent aucun revenus).
@ byte_order
Donc tu réponds à un fait par de la spéculation? Bravo 👏
@bonnepoire
De quel "fait" vous parlez ?
Je rappelle aux naïfs béats que cette possibilité peut disparaitre - comme tant d'autres fonctionnalités de macOS - sur simple décision unilatérale d'Apple.
"peut disparaitre", pure spéculation.
@bonnepoire
Okay, vous avez répondu sur ce que vous considériez de la spéculation de ma part, très bien.
Je confirme qu'il s'agit bien de spéculation de ma part. Basée, toutefois, sur des précédents, quand même, mais oui, c'est spéculatif, n'ayant pas (ni vous) la possibilité de connaitre le futur par avance, c'est fatalement spéculatif.
Comme dans toute gestion de risque, vous noterez. Cela n’ôte pas l'importance de le faire ou d'en avoir conscience.
Par contre, j'affirme qu'il est factuel de dire qu'Apple *peut* le faire sur simple décision unilatérale de sa part. Je spécule juste qu'elle le fera à plus ou moins long terme, mais il est factuel qu'elle puisse le faire si cela lui chante, elle dispose suffisamment de contrôle après vente pour pouvoir le faire.
Bon, maintenant que vous avez répondu à côté de ma question, de quel "fait" auquel ma spéculation répond vous parlez ?
Et peut on faire ça en dehors de XCode ?
Au boulot on a une appli java wrappé avec une JRE (*)dans un .app, le tout est buildé depuis eclipse.
Ca me parait compliqué à notariser cette affaire...
Et non, hors de question de tout recoder pour mac en swift ou autre, c'est un produit legacy qui était autrefois dans une applet et qu'on a transformé en application.
Si un jour Mac OS ne permet plus de la faire tourner, ben les utilisateurs devront s'en passer ou passer sous Windows
*: J'en vois déjà dans le fond qui se levent pour dire "faut pas installer java c'est un nid à faille", je leur rappelerai que les failles java étaient dans le plugin permettant de lancer les applets depuis un navigateur (pas dans la JRE elle même) et que plus aucun navigateur ne supporte les applets (sauf IE sur windows)
Ça donne quoi Catalina sur un vieux MacBook Pro (2012)?
Mojave est une catastrophe pour la sotie de veille sur mon MacBook Pro
@romainB84
Aucun souci pour moi sur mon MacBook Pro 2012. Il tourne même mieux que Mojave qui fonctionné déjà très bien.
@Spike2311
Dans l’ensemble il marche pas trop mal, mais c’est vrai que la sortie de veille est calamiteuse !!!
Et pourtant j’ai un SSD et 16Go de ram... donc ça ne vient pas de ma machine ^^
@romainB84
Pareil SSD et 16Go de ram. Je n’ai pas constaté de problème en sortie de veille.
@Spike2311
Bah moi si 😅
A tel point que je suis obliger de l’éteindre régulièrement (tout les deux jours)!! Je ne l’étreignais que toute les 2-3 semaines avant ^^
Lorsqu'un ordinateur passe en veille prolongée, il enregistre le contenu de la RAM dans la mémoire de masse (HD ou SSD). Sur un disque dur encore plus que sur un SSD, avoir beaucoup de RAM n'est pas un gage de rapidité bien au contraire, car cela fait davantage de données à écrire dans le (au moment de la mise en veille) puis à relire du (au moment du réveil) stockage de masse !
Il arrive parfois que les paramètres de veille soient tels que l'ordinateur passe en veille prolongée à la moindre sollicitation d'une veille (là où une veille simple suffirait habituellement, la veille prolongée ne se déclenchant qu'au bout de nombreuses heures de veille).
Une restauration des paramètres par défaut permet de retrouver le comportement prévu par Apple (cela se passe dans les Préférences Système, panneau Économie d'énergie).
@skarel
Merci, c’est exactement ce que j’ai constaté chez moi. Mise en veille prolongée trop rapide uniquement sur batterie. Je vais restorer les réglages d’origine.
Bonsoir,
Pour revenir sur la "notarisation des applications", j'ai eu 2 alertes avec Luminar 3 et Luminar Flex, je ne sais pas si c'est lié mais les 2 applications réclamaient la permissions d'accéder à la frappe du clavier même "non utilisées" ?? étonnant non ? est-ce un bug ou Catalina joue son rôle et protégerait l'utilisateur d'un mouchard dans ... Luminar ! J'ai refusé la demande, les 2 applications fonctionnent parfaitement, étrange, non ? Je ne sais pas si cela a un lien mais c'est quand même très surprenant.
Les "alertes" de demande d'accès sont bien liées à Catalina, mais ça n'a rien à voir avec la notarisation. S'il y a un mouchard dans ces applications (un key logger?), votre exemple prouverait plutôt que la notarisation a pu se faire tout en laissant passer ce malware...
Pages