Se ultimamente l’installazione di un nuovo programma o l’utilizzo di uno già installato sul tuo Mac ti ha portato ad una schermata simile alla precedente e, schiacciando in essa il tasto “Consenti” non sia accaduto apparentemente nulla, sei anche su sulla stessa barca…
Con macOS High Sierra, Apple ha introdotto una novità (cfr. Technical Note TN2459 https://developer.apple.com/library/content/technotes/tn2459/_index.html e link relativi), piuttosto contestabile, per “aumentare” la sicurezza del suo sistema operativo. In sostanza, l’installazione di quei programmi che, per funzionare, debbano a loro volta installare un loro modulo addizionale (spesso un’estensione del kernel) all’interno del sistema, viene bloccata finché l’utente non dia il proprio assenso esplicito, appunto con il famoso tasto “Consenti” appena visto, situato nel modulo “Sicurezza” delle “Preferenze di Sistema”.
Se, da un lato, è vero che ciò impedisca ad eventuali programmi malvagi di installare liberamente un’estensione del kernel che pregiudichi il funzionamento sicuro del computer, dall’altro, è pur vero che non solo la maggior parte delle persone non dispone della preparazione tecnica per discernere le situazioni normali da quelle a rischio, ma anche che numerose installazioni devono essere ripetute proprio perché, a causa di questo blocco, non riescono ad andare a buon fine.
In particolare, con macOS 10.13.4 è stato fatto qualche cambiamento che ha ulteriormente complicato la situazione. Se infatti da un lato i produttori software hanno aggiornato i loro programmi d’installazione per dialogare con questa nuova caratteristica (spesso direzionando automaticamente l’utente alla schermata “Sicurezza” per schiacchiare il fatidico tasto “Consenti”), purtroppo, per alcune ragioni che probabilmente sono dovute a qualche errore in fase di programmazione, lo schiacciamento del tasto “Consenti” sembra non comportare alcun effetto!
Andando ad analizzare la questione, abbiamo simulato il problema, installando la versione di prova di un applicativo molto diffuso (e recentemente aggiornato proprio per supportare questa funzionalità) nella sua versione di prova; dopo aver operato nuomerosi riavvi e riinstallazioni di tale software, sembrerebbe che macOS in realtà dia il permesso di esecuzione al software, ma che, tuttavia, non solo il famigerato tasto “Consenti” non sparisca, ma che addirittura tale permesso debba essere rinnovato ad un successivo riavvio.
Volendo guardare sotto il cofano è possibile, aprendo una schermata a riga di comando tramite l’applicazione Terminale (che si trova nelle Utilità, combinazione Cmd+Shift+U dal Finder) oppure con l’eccellente iTerm (che si può scaricare dal sito https://www.iterm2.com/version3.html gratuitamente), andare ad interrogare il sistema direttamente.
Innanzitutto diventiamo SuperUser per amministrare la macchina, inserendo la tua password di sistema (ho messo gli asterischi per far vedere una digitazione, ma il tuo Mac non ti mostrerà nulla!):
POWERMINI:~ pasha$ sudo su
Password: ***********
POWERMINI:pasha root#
Da qui possiamo direttamente interrogare il sistema per capire se vi siano blocchi ad installazioni di moduli kext pendenti:
POWERMINI:pasha root# spctl kext-consent list
spctl: no kext consent configuration found.
Apparentemente sembrerebbe non esservi alcun blocco pendente, mentre la schermata grafica ancora lo segnala!! E infatti, il programma installato sembra funzionare correttamente :O Potremmo dunque verificare se i blocchi siano in generale attivati e se sia possibile disabilitarli:
POWERMINI:pasha root# spctl kext-consent status
Kernel Extension User Consent: ENABLED
POWERMINI:pasha root# spctl kext-consent disable
spctl: failed to store new configuration.
Con ulteriore stupore scopriamo che non solo l’infrastruttura di blocco è attivata, ma che, peraltro, non risulta possibile disabilitarla!! Forse è giusto dare un’occhiata ai permessi che sono conservati in una tabella di database sqlite, andando ad identificare se il codice produttore del software, denominato “Team ID” compaia o no.
POWERMINI:pasha root# /usr/bin/sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .tables
kext_load_history_v3 kext_policy_mdm
kext_policy settings
sqlite> select * from kext_policy;
VB5E2TV963|org.virtualbox.kext.VBoxDrv|1|Oracle America, Inc.|1
VB5E2TV963|org.virtualbox.kext.VBoxUSB|1|Oracle America, Inc.|1
VB5E2TV963|org.virtualbox.kext.VBoxNetFlt|1|Oracle America, Inc.|1
VB5E2TV963|org.virtualbox.kext.VBoxNetAdp|1|Oracle America, Inc.|1
3T5GSNBU6W|com.github.osxfuse.filesystems.osxfuse|1|Benjamin Fleischer|1
TXAEAV5RN4|com.epson.print.kext.USBPrintClass|1|Seiko Epson Corporation|0
PPNVCC9Z68|com.tuxera.filesystems.tuxera_ntfs|0|Tuxera Inc.|4
sqlite>.quit
Abbiamo dunque trovato che il Team ID del software bloccato è “PPNVCC9Z68”. Abilitare manualmente questo ID andrebbe a sbloccare tutti i prodotti software di quel produttore che lo utilizzi. Proviamoci, dunque!
POWERMINI:pasha root# spctl kext-consent add PPNVCC9Z68
spctl: failed to store new configuration.
Il tentativo fallisce miseramente. Siamo dunque di fronte ad un chiaro esempio di BUG del sistema operativo, molto probabilmente introdotto in macOS10.13.4. Speriamo che, con il prossimo aggiornamento, Apple rimuova questa problematica fastidiosa.
Nel frattempo, buon lavoro!