Bac à sable (sandbox) d’une application Xamarin.Mac

Cet article traite du bac à sable (sandbox) d’une application Xamarin.Mac pour la publication sur l’App Store. Il couvre tous les éléments qui passent en bac à sable (sandboxing), tels que les répertoires de conteneurs, les droits, les autorisations déterminées par l’utilisateur, la séparation des privilèges et l’application du noyau.

Vue d’ensemble

Lorsque vous utilisez C# et .NET dans une application Xamarin.Mac, vous avez la même possibilité de bac à sable (sandbox) d’une application que lorsque vous travaillez avec Objective-C ou Swift.

Dans cet article, nous allons aborder les principes de base de l’utilisation du bac à sable dans une application Xamarin.Mac et tous les éléments qui passent en bac à sable (sandbox) : répertoires de conteneurs, droits, autorisations déterminées par l’utilisateur, séparation des privilèges et application du noyau. Il est fortement suggéré que vous travaillez tout d’abord dans l’article Hello, Mac , en particulier les sections Introduction to Xcode and Interface Builder et Outlets and Actions , car elle couvre les concepts et techniques clés que nous utiliserons dans cet article.

Vous pouvez également examiner les classes /méthodes C# exposantes dans Objective-C la section du document interne Xamarin.Mac , ainsi que les RegisterExport attributs utilisés pour connecter vos classes C# à des objets et des Objective-C éléments d’interface utilisateur.

À propos du bac à sable d’application

Le bac à sable d’application offre une défense forte contre les dommages qui peuvent être causés par une application malveillante exécutée sur un Mac en limitant l’accès qu’une application a aux ressources système.

Une application non bac à sable dispose des droits complets de l’utilisateur qui exécute l’application et peut accéder ou faire tout ce que l’utilisateur peut. Si l’application contient des trous de sécurité (ou toute infrastructure qu’elle utilise), un pirate peut potentiellement exploiter ces faiblesses et utiliser l’application pour prendre le contrôle du Mac sur lequel il s’exécute.

En limitant l’accès aux ressources par application, une application en bac à sable fournit une ligne de défense contre le vol, la corruption ou l’intention malveillante d’une application s’exécutant sur l’ordinateur de l’utilisateur.

Le bac à sable d’application est une technologie de contrôle d’accès intégrée à macOS (appliquée au niveau du noyau) qui fournit une stratégie à deux volets :

1. Le bac à sable d’application permet au développeur de décrire comment une application interagit avec le système d’exploitation et, de cette façon, elle reçoit uniquement les droits d’accès requis pour effectuer le travail, et plus encore.
2. Le bac à sable d’application permet à l’utilisateur d’accorder en toute transparence l’accès au système via les boîtes de dialogue Ouvrir et Enregistrer, les opérations de glisser-déplacer et d’autres interactions utilisateur courantes.

Préparation à l’implémentation du bac à sable d’application

Les éléments du bac à sable d’application qui seront abordés en détail dans l’article sont les suivants :

• Répertoires de conteneurs
• Droits
• Autorisations déterminées par l’utilisateur
• Séparation des privilèges
• Application du noyau

Après avoir compris ces détails, vous pourrez créer un plan pour adopter le bac à sable d’application dans votre application Xamarin.Mac.

Tout d’abord, vous devez déterminer si votre application est un bon candidat pour le bac à sable (la plupart des applications sont). Ensuite, vous devez résoudre les incompatibilités d’API et déterminer les éléments du bac à sable d’application dont vous aurez besoin. Enfin, examinez l’utilisation de Privilege Separation pour optimiser le niveau de défense de votre application.

Lors de l’adoption du bac à sable d’application, certains emplacements de système de fichiers que votre application utilise sont différents. En particulier, votre application aura un répertoire de conteneurs qui sera utilisé pour les fichiers de prise en charge de l’application, les bases de données, les caches et tous les autres fichiers qui ne sont pas des documents utilisateur. MacOS et Xcode prennent en charge la migration de ces types de fichiers à partir de leurs emplacements hérités vers le conteneur.

Démarrage rapide du bac à sable

Dans cette section, nous allons créer une application Xamarin.Mac simple qui utilise une vue web (qui nécessite une connexion réseau limitée sous bac à sable (sauf demande spécifique) comme exemple de prise en main du bac à sable d’application.

Nous allons vérifier que l’application est réellement en bac à sable et apprendre à résoudre les erreurs courantes du bac à sable d’application.

Création du projet Xamarin.Mac

Procédons comme suit pour créer notre exemple de projet :

1. Démarrez Visual Studio pour Mac et cliquez sur le lien Nouvelle solution.

2. Dans la boîte de dialogue Nouveau projet, sélectionnez Application Cocoa Mac>App :>

   

3. Cliquez sur le bouton Suivant , entrez MacSandbox le nom du projet et cliquez sur le bouton Créer :

   

4. Dans le Panneau Solution, double-cliquez sur le fichier Main.storyboard pour l’ouvrir pour la modification dans Xcode :

   

5. Faites glisser un affichage web sur la fenêtre, dimensionez-le pour remplir la zone de contenu et définissez-la pour augmenter et réduire avec la fenêtre :

   

6. Créez un point de sortie pour la vue web appelée webView:

   

7. Revenez à Visual Studio pour Mac et double-cliquez sur le fichier ViewController.cs dans le Panneau Solution pour l’ouvrir pour modification.

8. Ajoutez l’instruction using suivante : using WebKit;

9. Faites en sorte que la ViewDidLoad méthode ressemble à ce qui suit :

   public override void AwakeFromNib ()
   {
       base.AwakeFromNib ();
       webView.MainFrame.LoadRequest(new NSUrlRequest(new NSUrl("http://www.apple.com")));
   }
   

10. Enregistrez vos modifications.

Exécutez votre application et vérifiez que le site web Apple s’affiche dans la fenêtre comme suit :

Signature et approvisionnement de l’application

Avant de pouvoir activer le bac à sable d’application, nous devons d’abord provisionner et signer notre application Xamarin.Mac.

Procédez comme suit :

1. Connectez-vous au portail des développeurs Apple :

   

2. Sélectionnez certificats, identificateurs et profils :

   

3. Sous Applications Mac, sélectionnez Identificateurs :

   

4. Créez un ID pour l’application :

   

5. Sous Profils d’approvisionnement, sélectionnez Développement :

   

6. Créez un profil et sélectionnez Développement d’applications Mac :

   

7. Sélectionnez l’ID d’application que nous avons créé ci-dessus :

   

8. Sélectionnez les développeurs pour ce profil :

   

9. Sélectionnez les ordinateurs pour ce profil :

   

10. Donnez un nom au profil :

    

11. Cliquez sur le bouton Terminé.

Important

Dans certains cas, vous devrez peut-être télécharger directement le nouveau profil d’approvisionnement à partir du portail des développeurs d’Apple, puis double-cliquez dessus pour l’installer. Vous devrez peut-être également arrêter et redémarrer Visual Studio pour Mac avant de pouvoir accéder au nouveau profil.

Ensuite, nous devons charger le nouvel ID d’application et le nouveau profil sur l’ordinateur de développement. Procédons comme suit :

1. Démarrez Xcode et sélectionnez Préférences dans le menu Xcode :

   

2. Cliquez sur le bouton Afficher les détails... :

   

3. Cliquez sur le bouton Actualiser (dans le coin inférieur gauche).

4. Cliquez sur le bouton Terminé .

Ensuite, nous devons sélectionner le nouvel ID d’application et le profil d’approvisionnement dans notre projet Xamarin.Mac. Procédons comme suit :

1. Dans le Panneau Solution, double-cliquez sur le fichier Info.plist pour l’ouvrir pour modification.

2. Vérifiez que l’identificateur de bundle correspond à notre ID d’application que nous avons créé ci-dessus (exemple : ) : com.appracatappra.MacSandbox

   

3. Ensuite, double-cliquez sur le fichier Entitlements.plist et assurez-vous que notre magasin de clés-valeurs iCloud et les conteneurs iCloud correspondent tous à notre ID d’application que nous avons créé ci-dessus (exemple : ) : com.appracatappra.MacSandbox

   

4. Enregistrez vos modifications.

5. Dans le panneau Solution, double-cliquez sur le fichier projet pour ouvrir ses options de modification :

   

6. Sélectionnez Signature Mac, puis case activée signer le bundle d’applications et signer le package d’installation. Sous Profil d’approvisionnement, sélectionnez celui que nous avons créé ci-dessus :

   

7. Cliquez sur le bouton Terminé.

Important

Vous devrez peut-être quitter et redémarrer Visual Studio pour Mac pour l’obtenir pour reconnaître le nouvel ID d’application et le profil d’approvisionnement installés par Xcode.

Résolution des problèmes d’approvisionnement

À ce stade, vous devez essayer d’exécuter l’application et vous assurer que tout est signé et approvisionné correctement. Si l’application s’exécute toujours comme avant, tout est bon. En cas d’échec, vous pouvez obtenir une boîte de dialogue comme celle suivante :

Voici les causes les plus courantes de l’approvisionnement et des problèmes de signature :

• L’ID d’offre groupée d’applications ne correspond pas à l’ID d’application du profil sélectionné.
• L’ID du développeur ne correspond pas à l’ID de développeur du profil sélectionné.
• L’UUID du Mac testé sur n’est pas inscrit dans le cadre du profil sélectionné.

Dans le cas d’un problème, corrigez le problème sur le portail des développeurs Apple, actualisez les profils dans Xcode et effectuez une build propre dans Visual Studio pour Mac.

Activer le bac à sable d’application

Vous activez le bac à sable d’application en sélectionnant une boîte de réception case activée dans vos options de projets. Effectuez les actions suivantes :

1. Dans le panneau Solution, double-cliquez sur le fichier Entitlements.plist pour l’ouvrir pour modification.

2. Vérifiez les droits d’utilisation et activez le bac à sable d’application :

   

3. Enregistrez vos modifications.

À ce stade, vous avez activé le bac à sable d’application, mais vous n’avez pas fourni l’accès réseau requis pour la vue web. Si vous exécutez l’application maintenant, vous devez obtenir une fenêtre vide :

Vérification que l’application est en bac à sable (sandbox)

Outre le comportement de blocage des ressources, il existe trois façons principales de savoir si une application Xamarin.Mac a été correctement bac à sable (sandbox) :

1. Dans Finder, case activée le contenu du ~/Library/Containers/ dossier - Si l’application est en bac à sable, il y aura un dossier nommé par exemple l’identificateur de bundle de votre application (par exemple : ) : com.appracatappra.MacSandbox

   

2. Le système voit l’application en bac à sable dans le Moniteur d’activité :

   • Lancer le moniteur d’activité (sous /Applications/Utilities).
   • Choisissez Afficher les>colonnes et vérifiez que l’élément de menu Bac à sable est case activée ed.
   • Vérifiez que la colonne bac à sable lit Yes pour votre application :

   

3. Vérifiez que le fichier binaire de l’application est en bac à sable :

   • Démarrez l’application Terminal.
   • Accédez au répertoire des applications bin .
   • Exécutez cette commande : codesign -dvvv --entitlements :- executable_path (où executable_path se trouve le chemin d’accès à votre application) :

   

Débogage d’une application en bac à sable

Le débogueur se connecte aux applications Xamarin.Mac via TCP, ce qui signifie que, par défaut, lorsque vous activez le bac à sable, il ne peut pas se connecter à l’application. Par conséquent, si vous essayez d’exécuter l’application sans les autorisations appropriées activées, vous obtenez une erreur « Impossible de se connecter au débogueur ».

L’autorisation Autoriser le réseau sortant Connecter ions (client) est celle requise pour le débogueur, ce qui permet de déboguer normalement. Étant donné que vous ne pouvez pas déboguer sans celui-ci, nous avons mis à jour la CompileEntitlements cible pour msbuild ajouter automatiquement cette autorisation aux droits d’une application qui est en bac à sable pour les builds de débogage uniquement. Les builds de mise en production doivent utiliser les droits spécifiés dans le fichier des droits d’utilisation, non modifiés.

Résolution d’une violation de bac à sable d’application

Une violation de bac à sable d’application se produit si une application Xamarin.Mac en bac à sable a essayé d’accéder à une ressource qui n’a pas été explicitement autorisée. Par exemple, notre affichage web ne peut plus afficher le site Web Apple.

La source la plus courante des violations de bac à sable d’application se produit lorsque les paramètres de droits spécifiés dans Visual Studio pour Mac ne correspondent pas aux exigences de l’application. Là encore, revenez à notre exemple, les droits de Connecter ion réseau manquants qui empêchent l’affichage web de fonctionner.

Détection des violations de bac à sable d’application

Si vous soupçonnez qu’une violation de bac à sable d’application se produit dans votre application Xamarin.Mac, le moyen le plus rapide de découvrir le problème consiste à utiliser l’application console .

Effectuez les actions suivantes :

1. Compilez l’application en question et exécutez-la à partir de Visual Studio pour Mac.

2. Ouvrez l’application console (à partir de )./Applications/Utilties/

3. Sélectionnez Tous les messages dans la barre latérale et entrez sandbox dans la recherche :

   

Pour notre exemple d’application ci-dessus, vous pouvez voir que le Kernal bloque le network-outbound trafic en raison du bac à sable de l’application, car nous n’avons pas demandé ce droit.

Résolution des violations du bac à sable d’application avec les droits

Maintenant que nous avons vu comment trouver des violations de bac à sable d’application, voyons comment elles peuvent être résolues en ajustant les droits de notre application.

Effectuez les actions suivantes :

1. Dans le panneau Solution, double-cliquez sur le fichier Entitlements.plist pour l’ouvrir pour modification.

2. Dans la section Droits d’utilisation, case activée la case activée boîte de réception Autoriser les Connecter ions réseau sortantes (client) :

   

3. Enregistrez les modifications apportées à l’application.

Si nous procédons comme indiqué ci-dessus pour notre exemple d’application, générez-la et exécutez-la, le contenu web s’affiche désormais comme prévu.

Bac à sable d’application en profondeur

Les mécanismes de contrôle d’accès fournis par le bac à sable d’application sont peu et faciles à comprendre. Toutefois, la façon dont le bac à sable d’application sera adopté par chaque application est unique et basée sur les exigences de l’application.

Compte tenu de votre meilleur effort pour protéger votre application Xamarin.Mac contre l’exploitation par du code malveillant, il n’existe qu’une seule vulnérabilité dans l’application (ou l’une des bibliothèques ou infrastructures qu’elle consomme) pour contrôler les interactions de l’application avec le système.

Le bac à sable d’application a été conçu pour empêcher la prise de contrôle (ou limiter les dommages qu’elle peut causer) en vous permettant de spécifier les interactions prévues de l’application avec le système. Le système accorde uniquement l’accès à la ressource dont votre application a besoin pour accomplir son travail et rien de plus.

Lorsque vous concevez pour le bac à sable d’application, vous concevez pour un scénario pire. Si l’application est compromise par du code malveillant, elle est limitée à l’accès uniquement aux fichiers et ressources du bac à sable de l’application.

Droits d’utilisation et accès aux ressources système

Comme nous l’avons vu ci-dessus, une application Xamarin.Mac qui n’a pas été en bac à sable reçoit les droits complets et l’accès de l’utilisateur qui exécute l’application. Si elle est compromise par du code malveillant, une application non protégée peut agir en tant qu’agent pour un comportement hostile, avec un large potentiel de préjudice.

En activant le bac à sable d’application, vous supprimez tout mais un ensemble minimal de privilèges, que vous réactivez ensuite uniquement à l’aide des droits de votre application Xamarin.Mac.

Vous modifiez les ressources de bac à sable d’application de votre application en modifiant son fichier Rightss.plist et en case activée ou en sélectionnant les droits requis dans les zones de liste déroulante des éditeurs :

Répertoires de conteneurs et accès au système de fichiers

Lorsque votre application Xamarin.Mac adopte le bac à sable d’application, elle a accès aux emplacements suivants :

• Répertoire du conteneur d’applications : lors de la première exécution, le système d’exploitation crée un répertoire de conteneurs spécial où toutes ses ressources vont, qu’il ne peut accéder qu’à elle. L’application dispose d’un accès en lecture/écriture complet à ce répertoire.
• Répertoires de conteneurs de groupe d’applications : votre application peut avoir accès à un ou plusieurs conteneurs de groupe partagés entre les applications du même groupe.
• Fichiers spécifiés par l’utilisateur : votre application obtient automatiquement l’accès aux fichiers qui sont explicitement ouverts ou déplacés vers l’application par l’utilisateur.
• Éléments connexes : avec les droits appropriés, votre application peut avoir accès à un fichier portant le même nom, mais une autre extension. Par exemple, un document qui a été enregistré en tant que .txt fichier et un .pdf.
• Répertoires temporaires, répertoires d’outils en ligne de commande et emplacements accessibles en lecture mondiale spécifiques : votre application a différents degrés d’accès aux fichiers dans d’autres emplacements bien définis, comme spécifié par le système.

Répertoire du conteneur d’applications

Le répertoire du conteneur d’applications d’une application Xamarin.Mac présente les caractéristiques suivantes :

• Il se trouve dans un emplacement masqué dans le répertoire d’accueil de l’utilisateur (généralement ~Library/Containers) et est accessible avec la NSHomeDirectory fonction (voir ci-dessous) dans votre application. Étant donné qu’il se trouve dans le répertoire d’accueil, chaque utilisateur obtient son propre conteneur pour l’application.
• L’application dispose d’un accès en lecture/écriture illimité au répertoire conteneur et à tous ses sous-répertoires et fichiers.
• La plupart des API de recherche de chemin d’accès de macOS sont relatives au conteneur de l’application. Par exemple, le conteneur aura sa propre bibliothèque (accessible via NSLibraryDirectory), les sous-répertoires Support et Préférences des applications.
• macOS établit et applique la connexion entre et l’application et son conteneur via la signature de code. Même s’il s’agit d’une autre application tente d’usurper l’application à l’aide de son identificateur de bundle, elle ne pourra pas accéder au conteneur en raison de la signature de code.
• Le conteneur n’est pas destiné aux fichiers générés par l’utilisateur. Au lieu de cela, il s’agit de fichiers utilisés par votre application, tels que des bases de données, des caches ou d’autres types de données spécifiques.
• Pour les types d’applications de boîte à chaussures (comme l’application Photo d’Apple), le contenu de l’utilisateur passe dans le conteneur.

Important

Malheureusement, Xamarin.Mac n’a pas encore de couverture d’API de 100 % (contrairement à Xamarin.iOS), car l’API NSHomeDirectory n’a pas été mappée dans la version actuelle de Xamarin.Mac.

En guise de solution de contournement temporaire, vous pouvez utiliser le code suivant :

[System.Runtime.InteropServices.DllImport("/System/Library/Frameworks/Foundation.framework/Foundation")]
public static extern IntPtr NSHomeDirectory();

public static string ContainerDirectory {
    get {
        return ((NSString)ObjCRuntime.Runtime.GetNSObject(NSHomeDirectory())).ToString ();
        }
}

Répertoire du conteneur du groupe d’applications

À compter de Mac macOS 10.7.5 (et versions ultérieures), une application peut utiliser le com.apple.security.application-groups droit d’accéder à un conteneur partagé commun à toutes les applications du groupe. Vous pouvez utiliser ce conteneur partagé pour du contenu non utilisateur tel que la base de données ou d’autres types de fichiers de support (tels que les caches).

Les conteneurs de groupe sont automatiquement ajoutés au conteneur de bac à sable de chaque application (s’ils font partie d’un groupe) et sont stockés à l’adresse ~/Library/Group Containers/<application-group-id>. L’ID de groupe doit commencer par votre ID d’équipe de développement et une période, par exemple :

<team-id>.com.company.<group-name>

Pour plus d’informations, consultez les informations de référence sur l’ajout d’une application à un groupe d’applications dans la référence de la clé de droit.

Accès au système de fichiers et powerbox en dehors du conteneur d’application

Une application Xamarin.Mac en bac à sable peut accéder aux emplacements du système de fichiers en dehors de son conteneur de la manière suivante :

• Dans la direction spécifique de l’utilisateur (via Open and Save Dialogs ou d’autres méthodes telles que glisser-déplacer).
• En utilisant des droits pour des emplacements de système de fichiers spécifiques (par /bin exemple, ou /usr/lib).
• Lorsque l’emplacement du système de fichiers se trouve dans certains répertoires lisibles dans le monde (tels que le partage).

Powerbox est la technologie de sécurité macOS qui interagit avec l’utilisateur pour développer les droits d’accès aux fichiers de votre application Xamarin.Mac en bac à sable (sandbox). Powerbox n’a pas d’API, mais est activé de manière transparente lorsque l’application appelle un NSOpenPanel ou NSSavePanel. L’accès Powerbox est activé via les droits que vous définissez pour votre application Xamarin.Mac.

Lorsqu’une application en bac à sable affiche une boîte de dialogue Ouvrir ou Enregistrer, la fenêtre est présentée par Powerbox (et non AppKit) et a donc accès à n’importe quel fichier ou répertoire auquel l’utilisateur a accès.

Lorsqu’un utilisateur sélectionne un fichier ou un répertoire dans la boîte de dialogue Ouvrir ou Enregistrer (ou fait glisser sur l’icône de l’application), Powerbox ajoute le chemin associé au bac à sable de l’application.

En outre, le système autorise automatiquement les éléments suivants à une application en bac à sable (sandbox) :

• Connecter ion à une méthode d’entrée système.
• Appelez les services sélectionnés par l’utilisateur dans le menu Services (uniquement pour les services marqués comme sécurisés pour les applications bac à sable par le fournisseur de services).
• Ouvrez les fichiers sélectionnés par l’utilisateur dans le menu Ouvrir récent .
• Utilisez Copier et coller entre d’autres applications.
• Lire des fichiers à partir des emplacements accessibles au monde suivants :
  • /bin
  • /sbin
  • /usr/bin
  • /usr/lib
  • /usr/sbin
  • /usr/share
  • /System
• Lire et écrire des fichiers dans les répertoires créés par NSTemporaryDirectory.

Par défaut, les fichiers ouverts ou enregistrés par une application Xamarin.Mac en bac à sable restent accessibles jusqu’à ce que l’application se termine (sauf si le fichier était toujours ouvert lors de la fermeture de l’application). Les fichiers ouverts seront automatiquement restaurés dans le bac à sable de l’application via la fonctionnalité de reprise macOS lors du prochain démarrage de l’application.

Pour fournir une persistance aux fichiers situés en dehors du conteneur d’une application Xamarin.Mac, utilisez des signets délimités par la sécurité (voir ci-dessous).

Éléments connexes

Le bac à sable d’application permet à une application d’accéder aux éléments associés qui ont le même nom de fichier, mais des extensions différentes. La fonctionnalité comporte deux parties : a) une liste d’extensions associées dans le fichier de Info.plst l’application, b) code pour indiquer au bac à sable ce que l’application fera avec ces fichiers.

Il existe deux scénarios dans lesquels cela est logique :

1. L’application doit pouvoir enregistrer une autre version du fichier (avec une nouvelle extension). Par exemple, l’exportation d’un .txt fichier vers un .pdf fichier. Pour gérer cette situation, vous devez utiliser un NSFileCoordinator pour accéder au fichier. Vous allez d’abord appeler la WillMove(fromURL, toURL) méthode, déplacer le fichier vers la nouvelle extension, puis appeler ItemMoved(fromURL, toURL).
2. L’application doit ouvrir un fichier principal avec une extension et plusieurs fichiers de prise en charge avec différentes extensions. Par exemple, un film et un fichier de sous-titres. Utilisez un NSFilePresenter élément pour accéder au fichier secondaire. Fournissez le fichier principal à la PrimaryPresentedItemURL propriété et le fichier secondaire à la PresentedItemURL propriété. Lorsque le fichier principal est ouvert, appelez la AddFilePresenter méthode de la NSFileCoordinator classe pour inscrire le fichier secondaire.

Dans les deux scénarios, le fichier Info.plist de l’application doit déclarer les types de documents que l’application peut ouvrir. Pour tout type de fichier, ajoutez le NSIsRelatedItemType (avec une valeur de YES) à son entrée dans le CFBundleDocumentTypes tableau.

Ouvrir et enregistrer le comportement de boîte de dialogue avec des applications en bac à sable (sandbox)

Les limites suivantes sont placées sur l’application NSOpenPanel Xamarin.Mac en bac à sable (sandbox) :NSSavePanel

• Vous ne pouvez pas appeler par programme le bouton OK .
• Vous ne pouvez pas modifier par programmation la sélection d’un utilisateur dans un NSOpenSavePanelDelegate.

En outre, les modifications d’héritage suivantes sont en place :

• Application non bac à sable (sandbox) - NSOpenPanelNSSavePanel``NSPanel``NSWindow``NSResponder``NSObject``NSOpenPanel``NSSavePanel``NSObject``NSOpenPanel``NSSavePanel

Signets et accès aux ressources persistantes dans l’étendue de la sécurité

Comme indiqué ci-dessus, une application Xamarin.Mac en bac à sable peut accéder à un fichier ou une ressource en dehors de son conteneur par le biais d’une interaction directe de l’utilisateur (comme fourni par PowerBox). Toutefois, l’accès à ces ressources ne persiste pas automatiquement dans les lancements d’applications ou les redémarrages du système.

À l’aide de signets délimités par la sécurité, une application Xamarin.Mac en bac à sable peut conserver l’intention de l’utilisateur et maintenir l’accès aux ressources données après le redémarrage d’une application.

Types de signets délimités par la sécurité

Lorsque vous utilisez des signets délimités par la sécurité et l’accès aux ressources persistantes, il existe deux cas d’usage de sistine :

• Un signet étendu à l’application fournit un accès persistant à un fichier ou dossier spécifié par l’utilisateur.

  Par exemple, si l’application Xamarin.Mac en bac à sable (sandbox) permet d’ouvrir un document externe à des fins de modification (à l’aide d’un NSOpenPanel), l’application peut créer un signet étendu à l’application afin qu’elle puisse accéder à nouveau au même fichier à l’avenir.

• Un signet délimité par un document fournit un accès persistant de document spécifique à un sous-fichier.

Par exemple, une application d’édition vidéo qui crée un fichier projet qui a accès aux images individuelles, aux clips vidéo et aux fichiers audio qui seront ensuite combinés dans un seul film.

Lorsque l’utilisateur importe un fichier de ressources dans le projet (via a NSOpenPanel), l’application crée un signet délimité par le document pour l’élément stocké dans le projet, afin que le fichier soit toujours accessible à l’application.

Un signet délimité par un document peut être résolu par n’importe quelle application qui peut ouvrir les données de signet et le document lui-même. Cela prend en charge la portabilité, ce qui permet à l’utilisateur d’envoyer les fichiers projet à un autre utilisateur et d’avoir tous les signets qui fonctionnent également pour eux.

Important

Un signet délimité par un document ne peut pointer qu’vers un seul fichier et non un dossier et ce fichier ne peut pas se trouver dans un emplacement utilisé par le système (par /private exemple, ou /Library).

Utilisation de signets délimités à la sécurité

L’utilisation de l’un ou l’autre type de signet délimité par la sécurité vous oblige à effectuer les étapes suivantes :

1. Définissez les droits appropriés dans l’application Xamarin.Mac qui doit utiliser des signets délimités par la sécurité : pour les signets délimités par l’application, définissez la com.apple.security.files.bookmarks.app-scope clé truede droit sur . Pour les signets délimités par le document, définissez la com.apple.security.files.bookmarks.document-scope clé truede droits sur .
2. Créez un signet délimité par la sécurité . Pour tout fichier ou dossier auquel l’utilisateur a fourni l’accès (par NSOpenPanel exemple), l’application a besoin d’un accès persistant. Utilisez la public virtual NSData CreateBookmarkData (NSUrlBookmarkCreationOptions options, string[] resourceValues, NSUrl relativeUrl, out NSError error) méthode de la NSUrl classe pour créer le signet.
3. Résolvez le signet délimité par la sécurité : lorsque l’application doit accéder à nouveau à la ressource (par exemple, après le redémarrage), il doit résoudre le signet en URL délimitée par la sécurité. Utilisez la public static NSUrl FromBookmarkData (NSData data, NSUrlBookmarkResolutionOptions options, NSUrl relativeToUrl, out bool isStale, out NSError error) méthode de la NSUrl classe pour résoudre le signet.
4. Informez explicitement le système que vous souhaitez accéder au fichier à partir de l’URL délimitée par la sécurité . Cette étape doit être effectuée immédiatement après avoir obtenu l’URL délimitée par la sécurité ci-dessus ou, lorsque vous souhaitez plus tard récupérer l’accès à la ressource après avoir annulé votre accès à celle-ci. Appelez la StartAccessingSecurityScopedResource () méthode de la NSUrl classe pour commencer à accéder à une URL étendue de sécurité.
5. Informez explicitement le système que vous avez terminé d’accéder au fichier à partir de l’URL délimitée par la sécurité . Dès que possible, vous devez informer le système lorsque l’application n’a plus besoin d’accéder au fichier (par exemple, si l’utilisateur le ferme). Appelez la StopAccessingSecurityScopedResource () méthode de la NSUrl classe pour arrêter l’accès à une URL étendue de sécurité.

Après avoir redéployé l’accès à une ressource, vous devez revenir à l’étape 4 pour rétablir l’accès. Si l’application Xamarin.Mac est redémarrée, vous devez revenir à l’étape 3 et résoudre à nouveau le signet.

Important

L’échec de la publication de l’accès aux ressources d’URL délimitées par la sécurité entraîne la fuite des ressources du noyau par une application Xamarin.Mac. Par conséquent, l’application ne pourra plus ajouter d’emplacements de système de fichiers à son conteneur jusqu’à ce qu’elle soit redémarrée.

Bac à sable d’application et signature de code

Après avoir activé le bac à sable d’application et activé les exigences spécifiques pour votre application Xamarin.Mac (via les droits d’utilisation), vous devez coder le projet pour que le bac à sable prenne effet. Vous devez effectuer la signature de code, car les droits requis pour le bac à sable d’application sont liés à la signature de l’application.

macOS applique un lien entre le conteneur d’une application et sa signature de code, de cette façon, aucune autre application ne peut accéder à ce conteneur, même s’il usurpe l’ID d’ensemble des applications. Ce mécanisme fonctionne comme suit :

1. Lorsque le système crée le conteneur de l’application, il définit une liste de contrôle d’accès (ACL) sur ce conteneur. L’entrée de contrôle d’accès initiale dans la liste contient l’exigence désignée (DR) de l’application, qui décrit comment les futures versions de l’application peuvent être reconnues (lorsqu’elles ont été mises à niveau).
2. Chaque fois qu’une application avec le même ID groupé démarre, le système case activée que la signature de code de l’application correspond aux exigences désignées spécifiées dans l’une des entrées de la liste de contrôle d’accès du conteneur. Si le système ne trouve pas de correspondance, il empêche le lancement de l’application.

La signature de code fonctionne de la manière suivante :

1. Avant de créer le projet Xamarin.Mac, obtenez un certificat de développement, un certificat de distribution et un certificat d’ID de développeur à partir du portail des développeurs Apple.
2. Lorsque l’App Store Mac distribue l’application Xamarin.Mac, elle est signée avec une signature de code Apple.

Lors du test et du débogage, vous utiliserez une version de l’application Xamarin.Mac que vous avez signée (qui sera utilisée pour créer le conteneur d’applications). Par la suite, si vous souhaitez tester ou installer la version à partir de l’Apple App Store, elle sera signée avec la signature Apple et ne sera pas lancée (car elle n’a pas la même signature de code que le conteneur d’application d’origine). Dans ce cas, vous obtiendrez un rapport d’incident similaire à ce qui suit :

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)

Pour résoudre ce problème, vous devez ajuster l’entrée de liste de contrôle d’accès pour pointer vers la version signée Apple de l’application.

Pour plus d’informations sur la création et le téléchargement des profils d’approvisionnement requis pour le sandboxing, consultez la section Signature et approvisionnement de l’application ci-dessus.

Ajustement de l’entrée de liste de contrôle d’accès

Pour autoriser l’exécution de la version signée Apple de l’application Xamarin.Mac, procédez comme suit :

1. Ouvrez l’application Terminal (dans /Applications/Utilities).
2. Ouvrez une fenêtre Finder sur la version signée Apple de l’application Xamarin.Mac.
3. Tapez asctl container acl add -file la fenêtre terminale.
4. Faites glisser l’icône de l’application Xamarin.Mac à partir de la fenêtre Finder et déposez-la dans la fenêtre terminale.
5. Le chemin d’accès complet au fichier sera ajouté à la commande dans Terminal.
6. Appuyez sur Entrée pour exécuter la commande.

La liste de contrôle d’accès du conteneur contient désormais les exigences de code désignées pour les deux versions de l’application Xamarin.Mac et macOS autorisent désormais l’exécution de l’une ou l’autre version.

Afficher la liste des exigences de code ACL

Vous pouvez afficher la liste des exigences de code dans la liste de contrôle d’accès d’un conteneur en procédant comme suit :

1. Ouvrez l’application Terminal (dans /Applications/Utilities).
2. Tapez asctl container acl list -bundle <container-name>.
3. Appuyez sur Entrée pour exécuter la commande.

Il <container-name> s’agit généralement de l’identificateur de bundle pour l’application Xamarin.Mac.

Conception d’une application Xamarin.Mac pour le bac à sable d’application

Il existe un flux de travail courant qui doit être suivi lors de la conception d’une application Xamarin.Mac pour le bac à sable d’application. Cela dit, les spécificités de l’implémentation du bac à sable dans une application vont être uniques aux fonctionnalités de l’application donnée.

Six étapes pour l’adoption du bac à sable d’application

La conception d’une application Xamarin.Mac pour le bac à sable d’application se compose généralement des étapes suivantes :

1. Déterminez si l’application convient au bac à sable (sandbox).
2. Concevoir une stratégie de développement et de distribution.
3. Résolvez les incompatibilités d’API.
4. Appliquez les droits de bac à sable d’application requis au projet Xamarin.Mac.
5. Ajoutez une séparation des privilèges à l’aide de XPC.
6. Implémentez une stratégie de migration.

Important

Vous devez non seulement bac à sable (sandbox) l’exécutable principal dans votre offre groupée d’applications, mais également chaque application d’assistance ou outil inclus dans ce bundle. Cela est nécessaire pour toute application distribuée à partir du Mac App Store et, si possible, doit être effectuée pour toute autre forme de distribution d’application.

Pour obtenir la liste de tous les fichiers binaires exécutables dans le bundle d’une application Xamarin.Mac, tapez la commande suivante dans Terminal :

find -H [Your-App-Bundle].app -print0 | xargs -0 file | grep "Mach-O .*executable"

Où [Your-App-Bundle] se trouve le nom et le chemin d’accès à l’offre groupée de l’application.

Déterminer si une application Xamarin.Mac convient pour le bac à sable (sandbox)

La plupart des applications Xamarin.Mac sont entièrement compatibles avec le bac à sable d’application et conviennent donc au bac à sable (sandbox). Si l’application nécessite un comportement que le bac à sable d’application n’autorise pas, vous devez envisager une autre approche.

Si votre application nécessite l’un des comportements suivants, elle n’est pas compatible avec le bac à sable d’application :

• Services d’autorisation : avec le bac à sable d’application, vous ne pouvez pas utiliser les fonctions décrites dans la référence C des services d’autorisation.
• API d’accessibilité : vous ne pouvez pas bac à sable (sandbox) des applications d’assistance telles que des lecteurs d’écran ou des applications qui contrôlent d’autres applications.
• Envoyer des événements Apple à des applications arbitraires : si l’application requiert l’envoi d’événements Apple à une application inconnue et arbitraire, elle ne peut pas être en bac à sable. Pour obtenir une liste connue des applications appelées, l’application peut toujours être en bac à sable et les droits d’utilisation devront inclure la liste des applications appelée.
• Envoyer des dictionnaires d’informations utilisateur dans les notifications distribuées à d’autres tâches : avec le bac à sable d’application, vous ne pouvez pas inclure un userInfo dictionnaire lors de la publication dans un NSDistributedNotificationCenter objet pour la messagerie d’autres tâches.
• Charger des extensions de noyau : le chargement des extensions de noyau est interdit par le bac à sable d’application.
• Simulation de l’entrée utilisateur dans les boîtes de dialogue Ouvrir et Enregistrer : la manipulation par programmation de dialogues Ouvrir ou Enregistrer pour simuler ou modifier l’entrée utilisateur est interdite par le bac à sable de l’application.
• L’accès ou la définition des préférences sur d’autres applications : la manipulation des paramètres d’autres applications est interdite par le bac à sable d’application.
• La configuration du Paramètres réseau : la manipulation du Paramètres réseau est interdite par le bac à sable d’application.
• Fin d’autres applications : le bac à sable d’application interdit l’utilisation NSRunningApplication d’autres applications.

Résolution des incompatibilités d’API

Lors de la conception d’une application Xamarin.Mac pour le bac à sable d’application, vous pouvez rencontrer des incompatibilités avec l’utilisation de certaines API macOS.

Voici quelques problèmes courants et les choses que vous pouvez faire pour les résoudre :

• Ouverture, enregistrement et suivi de documents : si vous gérez des documents à l’aide d’une technologie autre que NSDocumentcelle-ci, vous devez le basculer en raison de la prise en charge intégrée du bac à sable d’application. NSDocument fonctionne automatiquement avec PowerBox et fournit la prise en charge de la conservation des documents dans votre bac à sable si l’utilisateur les déplace dans Finder.
• Conserver l’accès aux ressources du système de fichiers : si l’application Xamarin.Mac dépend de l’accès persistant aux ressources en dehors de son conteneur, utilisez des signets délimités à la sécurité pour maintenir l’accès.
• Créez un élément de connexion pour une application - Avec le bac à sable d’application, vous ne pouvez pas créer d’élément de connexion à l’aide LSSharedFileList de l’état des services de lancement à l’aide LSRegisterURLde . Utilisez la SMLoginItemSetEnabled fonction comme décrit dans Apples Ajout d’éléments de connexion à l’aide de la documentation service Management Framework .
• Accès aux données utilisateur : si vous utilisez des fonctions POSIX telles que getpwuid pour obtenir le répertoire de base de l’utilisateur à partir des services d’annuaire, envisagez d’utiliser des symboles Cocoa ou Core Foundation tels que NSHomeDirectory.
• Accès aux préférences d’autres applications : étant donné que le bac à sable d’application dirige les API de recherche de chemins vers le conteneur de l’application, la modification des préférences se produit dans ce conteneur et l’accès à d’autres préférences d’applications dans non autorisées.
• Utilisation de la vidéo incorporée HTML5 dans les vues web : si l’application Xamarin.Mac utilise WebKit pour lire des vidéos HTML5 incorporées, vous devez également lier l’application à l’infrastructure AV Foundation. Le bac à sable d’application empêche CoreMedia de lire ces vidéos dans le cas contraire.

Application des droits de bac à sable d’application requis

Vous devez modifier les droits d’utilisation pour toute application Xamarin.Mac que vous souhaitez exécuter dans le bac à sable d’application et case activée la boîte de réception Activer le bac à sable d’application case activée box.

En fonction des fonctionnalités de l’application, vous devrez peut-être activer d’autres droits d’accès aux fonctionnalités ou ressources du système d’exploitation. Le bac à sable d’application fonctionne le mieux lorsque vous réduisez les droits que vous demandez au minimum requis pour exécuter votre application afin d’activer de façon aléatoire les droits.

Pour déterminer les droits requis par une application Xamarin.Mac, procédez comme suit :

1. Activez le bac à sable d’application et exécutez l’application Xamarin.Mac.
2. Exécutez les fonctionnalités de l’application.
3. Ouvrez l’application console (disponible dans /Applications/Utilities) et recherchez sandboxd les violations dans le journal Tous les messages .
4. Pour chaque sandboxd violation, résolvez le problème en utilisant le conteneur d’applications au lieu d’autres emplacements du système de fichiers ou appliquez les droits de bac à sable d’application pour activer l’accès aux fonctionnalités de système d’exploitation restreintes.
5. Réexécutez et testez à nouveau toutes les fonctionnalités de l’application Xamarin.Mac.
6. Répétez jusqu’à ce que toutes les sandboxd violations aient été résolues.

Ajouter une séparation des privilèges à l’aide de XPC

Lors du développement d’une application Xamarin.Mac pour le bac à sable d’application, examinez les comportements de l’application en termes de privilèges et d’accès, puis envisagez de séparer les opérations à haut risque en leurs propres services XPC.

Pour plus d’informations, consultez le Guide de programmation création de services XPC et daemons et services d’Apple.

Implémenter une stratégie de migration

Si vous publiez une nouvelle version en bac à sable d’une application Xamarin.Mac qui n’était pas précédemment en bac à sable, vous devez vous assurer que les utilisateurs actuels disposent d’un chemin de mise à niveau fluide.

Pour plus d’informations sur l’implémentation d’un manifeste de migration de conteneur, consultez la documentation d’Apple sur la migration d’une application vers un bac à sable .

Résumé

Cet article a examiné en détail le bac à sable (sandbox) d’une application Xamarin.Mac. Tout d’abord, nous avons créé une application Xamarin.Mac pour afficher les principes de base du bac à sable d’application. Ensuite, nous avons montré comment résoudre les violations de bac à sable. Ensuite, nous avons examiné en détail le bac à sable d’application et enfin, nous avons examiné la conception d’une application Xamarin.Mac pour le bac à sable d’application.

Liens associés

• Publication dans l’App Store
• À propos du bac à sable d’application
• Problèmes courants de bac à sable d’application