Ho letto ( qui e qui ) che Homebrew (il gestore di pacchetti Unix) è un significativo rischio per la sicurezza del Mac. È consentito un attacco perché Homebrew rende /usr/local/bin
scrivibile senza privilegio utente root, il che consente a un altro processo Homebrew di scrivere un processo dannoso in questo albero di directory. L'albero /usr/local/bin
è preimpostato di default prima di /usr/bin
nel percorso per la shell. In quanto tale, un utente malintenzionato potrebbe iniettare un codice binario dannoso per modificare l'orologio o rubare la password di un amministratore (sudo malevolo per esempio).
C'è qualcuno là fuori a conoscenza di queste vulnerabilità? Qualcuno ha un metodo migliore per accedere ai comandi Unix critici senza influire sulla sicurezza del terminale dell'utente finale (MacBook w / OSX per esempio)? Usi Macports che si basa su un gestore di pacchetti che installa usando il privilegio di root su / opt? Realizzi tutte le tue shell Unix in un emulatore come Virtual Box o VMWare?
So che ci sono molte falle nella sicurezza che iniziano con la produzione e non appena viene installata un'app software. Sono molto curioso delle migliori pratiche da un esperto di sicurezza su questo.
AGGIORNAMENTO 2018-11-07
Ho controllato con la mailing list di macports e ho ricevuto risposte dettagliate e veloci. Sfortunatamente, nessuna risposta con dettagli sulla funzionalità del forum di Homebrew. A questo punto, sospetto che Macports abbia una migliore funzionalità di sicurezza. Ci può sempre essere un buco da qualche parte e per essere veramente sicuro, prenderò in considerazione l'installazione di queste applicazioni open source in un contenitore emulato autonomo. Ad esempio usando VirtualBox, VMWare o Parallels. In questo modo, se c'è un problema di sicurezza, sarà contenuto e non esporterà l'accesso al Portachiavi Mac o ad altri dati critici.
UPDATE ricevuto dalla mailing list di macports
L'installazione di MacPorts tramite il pacchetto di installazione pubblicato sulla nostra pagina Web richiede una password di amministratore e i file e le directory che installa sono di proprietà di root, il che significa che nessuno, a parte un amministratore, può cambiarli. Crea anche un normale account utente non privilegiato chiamato "macports" per MacPorts da utilizzare in seguito.
L'uso di MacPorts come installato in questo modo richiede anche una password di amministratore. I file di installazione delle porte MacPorts sono solitamente di proprietà di root, anche se le singole porte possono prendere le proprie decisioni al riguardo. Ad esempio, una porta del server database potrebbe creare un account utente speciale che deve essere utilizzato dal server database quando è in esecuzione e potrebbe installare una directory vuota in cui i file scritti dal server di database possono essere pubblicati e il proprietario di tale directory essere impostato su quel nuovo account utente.
Quando invochi il comando "port" con "sudo" e fornisci la password dell'amministratore, MacPorts passa all'utente "macports" non privilegiato. A quel punto non ha più privilegi di root quindi, anche se un portfile malevolo è stato commesso che ha tentato di farlo, non potrebbe modificare i file al di fuori della sua directory di build. MacPorts restituisce i privilegi di root quando si esegue qualcosa che richiede l'accesso root, ad esempio per il passaggio finale che installa effettivamente i file nel prefisso / opt / local.
È possibile costruire MacPorts da sorgenti configurate in modo da non utilizzare l'accesso root e, in tal caso, non si ottengono le protezioni di cui sopra. Non è consigliabile farlo.
MacPorts tiene traccia di quali file vengono installati da ciascuna porta e non consente a una porta di sovrascrivere i file di un'altra porta (a meno che l'utente lo richieda usando l'opzione -f, quindi l'utente dovrebbe astenersi dall'usare questo flag).
Un altro post
Va anche notato che l'homebrew non può improvvisamente cambiare se stesso per fornire questo grado di sicurezza senza una rehash abbastanza completa del modo in cui funziona, e la maggior parte / molti / tutti i "vantaggi" dell'installazione in / usr / i locali che sono serviti a renderlo popolare sarebbero stati completamente persi e molto probabilmente molte / la maggior parte / tutte le sue formule avrebbero dovuto essere riscritte per accogliere questo cambiamento. Molti di loro al momento suppongono che le cose si trovino automaticamente in / usr / local.
homebrew è stato popolare perché è "facile" - i file in / usr / local vengono trovati senza l'intervento di alcun compilatore o shell. Tuttavia, ciò non è privo di costi.
MacPorts richiede più lavoro per includere in modo specifico alcuni percorsi di inclusione, percorsi di libreria e percorsi eseguibili - ma ciò viene fornito con una certa conoscenza di ciò che si sta effettivamente ottenendo e la sicurezza di sapere che non può essere incasinato senza la tua autorizzazione.