Comment exécuter un LaunchAgent qui exécute un script qui provoque des défaillances à cause de la protection de l'intégrité du système.

J'ai passé quelques semaines à essayer de résoudre ce problème. Je reconnais que la réponse actuellement acceptée n'est pas vraiment une solution - ce n'est pas beaucoup mieux que de désactiver complètement le SIP.

Ma solution est une solution de contournement totalement bidon, mais ne nécessite pas de liste blanche. bash entièrement. Mise à jour : Une solution un peu moins compliquée est proposée ci-dessous.

Mise à jour 20190226 : Comme détaillé dans le problème Restic lié ci-dessous, cela semble avoir cessé de fonctionner. Les binaires originaux que j'ai créés avec cette méthode continuent de fonctionner sans erreur pour une raison étrange, mais je ne peux pas donner accès aux nouveaux binaires directement en utilisant cette méthode.

Vue d'ensemble

1. Empaqueter une application MacOS standard qui exécute un script (un script bash dans mon cas, qui à son tour configure un environnement et exécute un binaire séparé qui nécessite FDA).
2. Ajouter cette application à la FDA
3. Exécutez l'application en ouvrant le fichier .app (soit en double-cliquant sur l'interface graphique, soit en cliquant sur l'icône de l'application). open /path/to/MyApp.app mais pas en utilisant directement l'exécutable stocké dans par exemple MyApp.app/Contents/Resources/ )

Pour l'étape 1, vous pouvez facilement empaqueter votre script comme une application en utilisant des outils intégrés à MacOS tels que Automator.app ou script Editor, ou encore L'ornithorynque fonctionne également.

Un exemple de contenu d'une telle application pourrait être un simple AppleScript (dans l'éditeur script) tel que :

on run
    do shell script "/usr/local/bin/bash /path/to/myscript.sh"
end run

À partir de l'éditeur de script, utilisez la liste déroulante du menu d'enregistrement pour enregistrer comme une application, puis CLOSE script EDITOR .

Ajouter cette application à Full Disk Access par System Preferences -> Security & Privacy .

NB : Si vous n'avez pas sauvegardé et fermé le script Editor avant de l'ajouter à FDA comme indiqué, il semble qu'une sorte de processus invisible (sauvegardes automatiques en arrière-plan ?) change quelque chose (une sorte d'horodatage ou de hachage ?) qui est requis pour l'accès complet au disque, ce qui peut provoquer des erreurs intermittentes qui ont été un casse-tête majeur à comprendre. Donc, si vous n'avez pas fait cela, supprimez votre application de FDA, sauvegardez et fermez script Editor, puis ajoutez de nouveau à FDA.

Pour votre agent de lancement, utilisez quelque chose comme :

<string>/usr/bin/open</string>
<string>/path/to/MyApp.app</string>

Accès à la racine

Si votre script de sauvegarde a besoin d'un accès Root (par exemple pour sauvegarder des fichiers 0600 appartenant à Root), vous allez devoir faire face à une autre série de contournements, puisque /usr/bin/open ne semble pas pouvoir exécuter quoi que ce soit en tant que Root (même si vous spécifiez l'option UserName la clé dans un Root-owned /Library/LaunchDaemons/ plist. (Je serais heureux d'ouvrir cette question en tant que question distincte si nécessaire, car je pense que la solution de contournement ci-dessous laisse beaucoup à désirer).

Une option pour cela est d'ajouter with administrator privileges dans votre AppleScript, mais cela nécessite de taper manuellement votre mot de passe, ce qui va à l'encontre de l'objectif de la sauvegarde automatique. Ma solution actuelle est de :

1. sudo visudo et donner à mon utilisateur non privilégié la possibilité d'exécuter mon script de sauvegarde en tant que sudo avec NOPASSWD : (je spécifie également le hash du script pour espérer améliorer la sécurité, par ex. myuser ALL=(ALL) NOPASSWD: sha256:hashgoeshere /path/to/myscript.sh )
2. sudo chown root myscript.sh
3. sudo chmod 0740 myscript.sh (4 pour qu'il puisse encore être ajouté à VCS)
4. Changez l'AppleScript en do shell script "sudo -n /path/to/myscript.sh" et réenregistrer sous le nom de MyApp.app
5. Ajouter MyApp.app à la FDA
6. Changer mon launchd script pour ouvrir /path/to/MyApp.app
7. Rechargez launchd script avec launchctl et testez pour vous assurer que cela semble fonctionner.

Autres lectures / détails :

• https://github.com/restic/restic/issues/2051
• https://n8henrie.com/2018/11/how-to-give-full-disk-access-to-a-binary-in-MacOS-mojave/

UPDATE :

Après quelques tests préliminaires, il semble qu'une solution de contournement un peu moins pirate consiste à compiler un binaire (en utilisant un langage compilé) qui appelle votre script bash. Ajoutez ce binaire à FDA et cela semble fonctionner. Ajouter à la Root-owned /Library/LaunchDaemons plist, et vous avez un moyen de l'appeler à partir de root sans toutes les folies ci-dessus.

Exemple script en Go :

// Runrestic provides a binary to run my restic backup script in MacOS Mojave with Full Disk Access
package main

import (
    "log"
    "os"
    "os/exec"
    "path/filepath"
)

func main() {
    ex, err := os.Executable()
    if err != nil {
        log.Fatal(err)
    }
    dir := filepath.Dir(ex)
    script := filepath.Join(dir, "restic-backup.sh")
    cmd := exec.Command("/usr/local/bin/bash", script)
    if err := cmd.Run(); err != nil {
        log.Fatal(err)
    }
}

Par sécurité, je sudo chown root y sudo chmod 0700 le binaire résultant avant de l'ajouter à Full Disk Access (bien qu'il soit admis qu'un attaquant pourrait simplement changer le script bash script que cela appelle s'il était laissé sans protection).