Domanda:
Come eseguire un LaunchAgent che esegue uno script che causa errori a causa della protezione dell'integrità del sistema
Channing Walton
2018-10-01 13:56:42 UTC
view on stackexchange narkive permalink

Dopo l'aggiornamento a Mojave, il mio script di backup basato su rsync eseguito tramite un agente di avvio in ~ / Library / LaunchAgents, non poteva più leggere alcune directory in ~ / Library.

Possibile duplicato di [Cosa e come implementa macOS Mojave per limitare l'accesso delle applicazioni ai dati personali?] (Https://apple.stackexchange.com/questions/332673/what-and-how-does-macos-mojave-implement-to-restrict-application-access-to-pers)
Questo non è davvero un duplicato.Il problema specifico è l'esecuzione di script avviati da launchd tramite un agente di avvio.Scoprirai che non è semplice scoprire cosa è necessario inserire in Accesso completo al disco o come avviare correttamente lo script.
Domanda correlata: https://apple.stackexchange.com/questions/341958/full-disk-access-for-backup-tool-running-as-cron-job - dopo molti ritocchi, sono d'accordo che entrambi sono fondamentalmentediverso da https://apple.stackexchange.com/questions/332673/what-and-how-does-macos-mojave-implement-to-restrict-applications-access-to-pers
Quello che stai affrontando è * non * Protezione dell'integrità del sistema.Se fossi incappato in System Integrity Protection, la soluzione, e * l'unica * soluzione, al di fuori della modifica dello script, sarebbe disabilitare System Integrity Protection.
Sette risposte:
#1
+5
Channing Walton
2018-10-01 13:56:42 UTC
view on stackexchange narkive permalink

Ho risolto il problema come segue:

Consenti a Bash di avere accesso completo al disco

  1. Apri Preferenze
  2. Vai a Preferenze di sicurezza &
  3. Seleziona Accesso completo al disco nell'elenco a sinistra
  4. Fai clic sul lucchetto per apportare modifiche
  5. Fai clic sul pulsante + nell'elenco a destra
  6. Passa alla directory principale del tuo HD
  7. Premi CMD + Maiusc +. per mostrare tutti gli elementi nascosti
  8. Seleziona / bin / bash
  9. Esci da Preferenze
  10. Riavvia il Mac (non sono sicuro che sia davvero necessario)

Esegui correttamente lo script

L'errore che ho fatto è stato che l'agente di lancio ha eseguito lo script in questo modo:

  <key>ProgramArguments< / key>
<array>
    <string> / Users / channing / bin / backup.sh< / string>
< / array>
 

Fallo invece

  <key>ProgramArguments< / key>
<array>
    <string> / bin / bash< / string>
    <string> / Users / channing / bin / backup.sh< / string>
< / array>
 

Riavvia il tuo agente:

  launchctl scarica ~ / Library / LaunchAgents / backup.plist
launchctl carica ~ / Library / LaunchAgents / backup.plist
 

Rallegrati.

Non è una "soluzione", che ha fatto un grande buco nelle protezioni.Non si limita a far funzionare lo script, ma consente a tutto ciò che può ottenere un prompt della shell di fare quello che vuole.
@MarcWilson è corretto.Questa soluzione è come bombardare a tappeto una città perché vuoi rinnovare la tua cucina.
Sì, lo so che non è l'ideale.Allora qual è la soluzione?
Stai risolvendo il problema sbagliato.Qual è l'obiettivo reale?
Per eseguire periodicamente il backup della mia directory home con rsync.Faccio anche il backup con Backblaze.Time Machine ha fallito una volta di troppo perché me ne fidi (corruzione).
Ho avuto un problema simile dopo l'aggiornamento alla 10.14.Aveva un LaunchAgent personalizzato che chiamava `tmutil` per richiedere l'ultimo backup di Time Machine riuscito e fare varie cose in base a quello.Lo script ha iniziato a fallire con autorizzazioni insufficienti dopo Mojave.Niente che potessi fare per aggirare il problema, ho finito per usare l'approccio a mazza di @Channing Walton per ora.
Abbiamo bisogno di un modo per fidarci di uno script.
@MarcWilson Per quanto riguarda me e altri ricercatori, questa _è_ una soluzione.La FDA non è una "caratteristica" ben documentata - e con le operazioni critiche sui file che nel frattempo falliscono, questa è una buona soluzione finché non siamo in grado di capire cosa sta succedendo.
#2
+5
user13569
2019-07-01 11:50:23 UTC
view on stackexchange narkive permalink

La risposta attualmente accettata è un po 'difficile da seguire con tutti i suoi aggiornamenti.Ecco un breve riepilogo di ciò che attualmente funziona e cosa non funziona, più un nuovo suggerimento.

L'aggiunta di script o binari all'elenco "Accesso completo al disco" non funziona più.L'unica cosa che funziona è l'aggiunta di una vera app macOS.Come afferma Channing, Automator.app, Script Editor o Platypus possono essere utilizzati per crearne uno.

Suggerimento: la whitelist si applica a qualsiasi script o binario all'interno della directory dell'app.Quindi, non è necessario avviare l'app direttamente.In effetti, l'app stessa è completamente irrilevante: funge semplicemente da contenitore per la whitelist.Puoi copiare il tuo script in un'app arbitraria, inserire tale app nella whitelist, quindi eseguire lo script.L'unica avvertenza è che devi rimuovere e aggiungere nuovamente l'app alla whitelist ogni volta che modifichi lo script o il file binario al suo interno.

#3
+3
pyrrrat
2018-10-31 01:47:30 UTC
view on stackexchange narkive permalink

Modifica:

Ho fatto altri test e non riesco più a dare a nessun programma normale † l'accesso completo al disco. Ho scritto uno script di shell minimo [1], un binario minimo che chiama quello script di shell [2] e un binario che cerca di accedere a una posizione sicura [3]. Ho quindi fornito a tutti questi script / eseguibili l ' Accesso completo al disco e anche a / bin / sh per buona misura. Chiamare uno qualsiasi di questi direttamente tramite la shell mi dà un errore.

Poi sono incappato in una discussione nei forum degli sviluppatori Apple sulle regole per l'accesso completo al disco. Sembra che tu abbia bisogno di un app bundle per concedere le autorizzazioni di Accesso completo al disco , il che spiega perché la concessione dell'accesso completo al disco a un'app terminale consente a tale app di chiamare ls ~ / Library / Mail con successo.
Tuttavia not spiega perché puoi concedere l'accesso a / bin / bash e quindi usarlo nel tuo file launchd.plist per avere accesso completo al disco nel tuo script di shell.

† binario semplice, non un App Bundle presente in /Applications

[1] /Users/me/access-test.sh :

  #! / bin / sh
ls / Users / me / Library / Mail
 

[2] /Users/me/access-test.c :

  #include <unistd.h>

int main (int argc, char * const argv []) {
    const char * file = "/Users/me/access-test.sh";
    return execvp (file, argv);
}
 

[3] /Users/me/access-test-2.c :

  #include <stdio.h>
#include <dirent.h>

int main (void) {
    DIR * dp;
    struct dirent * ep;

    dp = opendir ("/ Users / me / Library / Mail");
    if (dp == NULL) {
        perror ("Impossibile aprire la directory");
        ritorno 1;
    } altro {
        while ((ep = readdir (dp))) {
            mette (ep->d_name);
        }
        closedir (dp);
    }
}
 

La mia risposta iniziale, che si è rivelata sbagliata:

Consenti allo script di backup l'accesso completo al disco.

Vai a Preferenze di Sistema Sicurezza & Privacy Privacy Accesso completo al disco .Quindi fai clic sul lucchetto per apportare modifiche, fai clic sul pulsante + e aggiungi lo script.

La prossima volta che launchd avvierà lo script, avrà accesso completo al disco e passerà queste autorizzazioni a tutti i processi secondari che genera, come rsync nel tuo caso.

/ p>

Funziona con qualsiasi eseguibile che desideri avviare utilizzando un agente di avvio.Aggiungi semplicemente l'eseguibile (dato come valore per <key>Program< / key> o il primo valore di <key>ProgramArguments< / key> nella tua lista di file )programmi con accesso completo al disco .

La semplice aggiunta della sceneggiatura non ha funzionato per me.
@ChanningWalton Hai ragione!Apparentemente l'ho fatto funzionare nel modo in cui l'ho descritto, ma ora sto avendo di nuovo lo stesso problema e non riesco a farlo funzionare.Presumo durante il test in giro ad un certo punto ho usato un terminale e / o una shell con accesso completo senza accorgermene.
#4
+3
n8henrie
2018-11-20 22:06:28 UTC
view on stackexchange narkive permalink

Ho passato alcune settimane a cercare di risolvere questo problema. Sono d'accordo che la risposta attualmente accettata non sia davvero una soluzione: non è molto meglio che disabilitare del tutto SIP.

La mia soluzione è una soluzione alternativa totalmente hacker, ma non richiede l'inserimento completo di bash nella whitelist. Update: Soluzione leggermente meno complicata di seguito.

Update 20190226: Come descritto in dettaglio nel problema Restic collegato di seguito, sembra che abbia smesso di funzionare. I binari originali che ho creato con questo metodo continuano a funzionare senza errori per qualche strana ragione, ma non posso dare accesso a nuovi binari direttamente utilizzando questo metodo.

Panoramica

  1. Creare un pacchetto di un'applicazione MacOS standard che esegue uno script (uno script bash nel mio caso, che a sua volta configura un ambiente ed esegue un binario separato che richiede FDA)
  2. Aggiungi tale applicazione alla FDA
  3. Esegui l'applicazione aprendo .app (facendo doppio clic tramite GUI o apri /path/to/MyApp.app ma non utilizzando direttamente l'eseguibile memorizzato in MyApp .app / Contents / Resources / )

Per il passaggio 1, puoi facilmente creare un pacchetto del tuo script come app utilizzando strumenti integrati in MacOS come Automator.app o Script Editor, oppure Platypus funziona anche.

Il contenuto di esempio di un'app di questo tipo potrebbe essere un semplice AppleScript (in Script Editor) come:

  in esecuzione
    esegui lo script di shell "/ usr / local / bin / bash /path/to/myscript.sh"
fine corsa
 

Da Script Editor, utilizza il menu a discesa nel menu di salvataggio per salvare come applicazione, quindi CLOSE SCRIPT EDITOR.

Aggiungi questa app all'accesso completo al disco tramite Preferenze di sistema -> Sicurezza & Privacy .

NB: Se non hai salvato e chiuso Script Editor prima di aggiungere a FDA come indicato, sembra che una sorta di processo invisibile (salvataggi automatici in background?) cambierà qualcosa (una sorta di timestamp o hash?) che è necessario per l'accesso completo al disco, che può risolvere alcuni errori intermittenti che erano un grosso problema. Quindi, se non l'hai fatto, rimuovi la tua app dalla FDA, salva e chiudi Script Editor, quindi aggiungila di nuovo alla FDA.

Per il tuo LaunchAgent, utilizza qualcosa come:

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

Accesso root

Se il tuo script di backup richiede l'accesso come root (ad es. per eseguire il backup dei file 0600 di proprietà di root), sei pronto per un'altra serie di soluzioni alternative hacker, poiché / usr / bin / open non lo farà sembra eseguire qualsiasi cosa come root (anche se si specifica la chiave UserName in un plist / Library / LaunchDaemons / di proprietà di root (sarei felice di aprirlo come domanda separata, se appropriato, poiché penso che la soluzione alternativa di seguito lasci molto a desiderare.)

Un'opzione per questo è aggiungere con privilegi di amministratore in AppleScript, ma ciò richiede l'inserimento manuale della password, vanificando lo scopo del backup automatico. La mia soluzione attuale è:

  1. sudo visudo e offri al mio utente non privilegiato la possibilità di eseguire il mio script di backup come sudo con NOPASSWD: (Specifico anche l'hash dello script per migliorare la sicurezza, si spera, ad esempio mioutente ALL = (TUTTI) NOPASSWD: sha256: hashgoeshere /path/to/myscript.sh )
  2. sudo chown root myscript.sh
  3. sudo chmod 0740 myscript.sh (4 in modo che possa ancora essere aggiunto a VCS)
  4. Cambia AppleScript in esegui script di shell "sudo -n /path/to/myscript.sh" e salva di nuovo come MyApp.app
  5. Aggiungi MyApp.app alla FDA
  6. Cambia il mio script launchd per aprire /path/to/MyApp.app
  7. Ricarica lo script launchd con launchctl e verifica per assicurarti che sembri funzionare

Ulteriori letture / dettagli:

AGGIORNAMENTO:

Dopo alcuni test preliminari, sembra che una soluzione alternativa un po 'meno complicata sia compilare un binario (usando un linguaggio compilato) che richiami il tuo script bash. Aggiungi quel binario alla FDA e sembra funzionare. Aggiungi al plist / Library / LaunchDaemons di proprietà di root e hai un modo per chiamarlo da root senza tutta la follia di cui sopra.

Script di esempio in Go:

  // Runrestic fornisce un binario per eseguire il mio script di backup restic in MacOS Mojave con accesso completo al disco
pacchetto principale

importazione (
    "log"
    "os"
    "os / exec"
    "percorso / percorso file"
)

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)
    se err: = cmd.Run (); err! = nil {
        log.Fatal (err)
    }
}
 

Per sicurezza, sudo chown root e sudo chmod 0700 il binario risultante prima di aggiungerlo a Accesso completo al disco (anche se è vero che un attaccante potrebbe basta cambiare lo script bash che questo chiama se non è stato protetto).

Grazie per aver dedicato del tempo a risolvere questo problema.Segnerò come risposta "corretta" perché è più sicura della mia.
Questa è la risposta / articolo più utile che ho trovato sull'argomento, tuttavia è stata aggiornata l'ultima volta 1 anno fa.Da allora ci sono stati miglioramenti nel flusso di lavoro?
@Superman.Lopez Sto ancora usando lo stesso processo.C'è un po 'più di discussione nella questione restic che ho collegato, ma nulla che abbia cambiato sostanzialmente il mio processo.
Ho appena scoperto che LaunchControl ha uno strumento di supporto per eseguire script launchd con autorizzazioni fda.Per il mio utilizzo questo è di gran lunga il modo più semplice e veloce per gestire le autorizzazioni.Consiglio vivamente l'applicazione LaunchControl e ha un prezzo ragionevole.
#5
+2
sander
2019-02-12 08:55:27 UTC
view on stackexchange narkive permalink

Ho riscontrato un problema simile.Per ora sembra che sono riuscito a far funzionare correttamente il mio script backup.sh tramite launchd rimuovendo l'estensione .sh e rendendo eseguibile lo script

  mv backup.sh backup
chmod + x backup
 

Quindi posso aggiungere lo script tramite la finestra di dialogo Accesso completo al disco.Dal file .plist chiamo direttamente / path / to / backup (cioè senza / bin / bash ).Non dimenticare di aggiungere #! / Bin / bash all'inizio dello script e di ricaricare il file .plist .

Interessante, ci proverò.
Questo non funziona per me.Sono in grado di aggiungere lo script all'elenco di accesso completo al disco come descrivi, ma quando lo eseguo tramite `launchd`, ricevo ancora errori` Operazione non consentita`.Questo è su Mojave, 10.14.5.
#6
+2
user13569
2020-06-10 07:41:42 UTC
view on stackexchange narkive permalink

Un nuovo modo per risolvere questo problema: LaunchControl ora viene fornito con un helper chiamato fdautil che puoi inserire nella whitelist e quindi eseguire comandi utilizzando fdautil exec .Consentirà solo i comandi che hai inserito nella whitelist tramite LaunchControl o fdautil set .

Ci sono un po 'di informazioni a riguardo su https://www.soma-zone.com/LaunchControl/FAQ.html e maggiori dettagli nella finestra della guida dell'app.

#7
  0
mlp
2018-10-12 20:43:33 UTC
view on stackexchange narkive permalink

Sto riscontrando lo stesso problema con alcune copie attivate tramite launchd che utilizzano idem.Provando anche alcuni test per vedere cosa posso aggiungere minimamente in Accesso completo al disco per farlo funzionare.Per gli script bash mi chiedo se potresti essere in grado di creare un'applicazione AppleScript e utilizzarla per concedere l'accesso e chiamare lo script.Potrebbe darti un modo per concedere l'accesso a quella specifica applicazione ed evitare di concedere l'accesso a tutte le cose che potresti eseguire tramite bash



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...