In che modo l'homebrew potrebbe influire sulla sicurezza del tuo Mac [duplicato]

4

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.

    
posta Nick 06.11.2018 - 07:44
fonte

1 risposta

0

È possibile modificare l'ordine dei percorsi in /etc/paths per impedire tali comportamenti dannosi. Tuttavia $PATH potrebbe essere sovrascritto nello script di shell (come .bash_profile o .zshrc ), quindi controlla / cambia anche loro.

Per quanto riguarda i Macport - Preferisco eseguire un software non affidabile in uno spazio utente con privilegi minimi, quindi Homebrew è più adatto.

Per quanto riguarda la shell Unix - basta creare una catena di fiducia, ad esempio utilizzare una shell affidabile nel terminale trusted. Inoltre, ho rafforzato il mio Mac con gli strumenti di Patrick Wardle perché sono open source e forniscono i necessari controlli di accesso alla rete e al sistema .

    
risposta data 06.11.2018 - 15:35
fonte

Leggi altre domande sui tag