Perché la sicurezza di root è applicata ma $ HOME in genere non protetto?

Non sono d'accordo con le risposte che dicono che l'età del modello di sicurezza di Unix o l'ambiente in cui è stato sviluppato sono in difetto. Non penso che sia così perché ci sono meccanismi in atto per gestire questo.

The root permissions system makes sense, but on desktop systems, it feels like it protects the wrong data.

Le autorizzazioni del superutente esistono per proteggere il sistema dai suoi utenti. Le autorizzazioni per gli account utente sono lì per proteggere l'account da altri account non root.

Eseguendo un programma, gli dai il permesso di fare cose con il tuo UID. Dal momento che il tuo UID ha accesso completo alla tua directory home, hai temporaneamente dato al programma lo stesso accesso. Proprio come il superutente ha l'accesso per apportare modifiche ai file di sistema che necessitano di protezione da comportamenti malevoli (password, configurazione, file binari), potresti avere dati nella tua home directory che richiedono lo stesso tipo di protezione.

Il principio del privilegio minimo dice che non devi dare più accesso di quanto sia assolutamente necessario. Il processo decisionale per l'esecuzione di qualsiasi programma dovrebbe essere lo stesso sia per i file che per i file di sistema. Se non si fornisce un codice che non si fida dell'utilizzo illimitato dell'account di superutente nell'interesse della protezione del sistema, non dovrebbe essere concesso l'uso illimitato del proprio account nell'interesse della protezione dei dati.

Is there no way to prevent malicious code happening in $HOME? And why does nobody care about it?

Unix non offre autorizzazioni granulari per lo stesso motivo non esiste una protezione per il blade attorno al comando rm : le autorizzazioni non sono lì per proteggere gli utenti da loro stessi.

Il modo per evitare che il codice dannoso danneggi i file nella tua home directory è di non eseguirlo usando il tuo account. Crea un utente separato che non disponga di autorizzazioni speciali e esegua il codice sotto tale UID fino a quando non hai determinato se puoi fidarti o meno.

Ci sono altri modi per farlo, come le chiamate a chroot, ma impostarle richiede più lavoro, e sfuggire a loro non è più la sfida di una volta.

Perché il modello di sicurezza basato su UNIX ha 50 anni.

UNIX è alla base della maggior parte dei sistemi operativi diffusi, e persino la grande eccezione di Windows è stata influenzata da essa più di quanto sia evidente. Deriva da un tempo in cui i computer erano macchine grandi, costose e lente utilizzate esclusivamente da specialisti arcani.

All'epoca, gli utenti semplicemente non disponevano di estese raccolte di dati personali su un computer qualsiasi , non sul loro server universitario, non sul loro personal computer (e certamente non sul loro telefono cellulare). I dati che variavano da utente a utente erano in genere dati di input e output di processi informatici scientifici - la loro perdita potrebbe costituire una perdita, ma in gran parte uno che potrebbe essere compensato dal ri-calcolo, certamente niente come le conseguenze delle perdite di dati odierne.

Nessuno avrebbe avuto il proprio diario, informazioni bancarie o foto di nudo su un computer, quindi proteggerli dall'accesso malevolo non era qualcosa che aveva una priorità elevata - in effetti, la maggior parte degli studenti universitari negli anni '70 sarebbe probabilmente stato entusiasta se altri mostrassero interesse per i loro dati di ricerca. Pertanto, la prevenzione della perdita di dati è stata considerata la massima priorità nella sicurezza dei computer, e ciò è garantito in modo adeguato da backup regolari piuttosto che dal controllo di accesso.

Questa è un'osservazione molto astuta. Sì, il malware in esecuzione come tuo utente può danneggiare / distruggere / modificare i dati nella tua home directory. Sì, la separazione degli utenti sui singoli sistemi utente è meno utile rispetto ai server. Tuttavia, ci sono ancora alcune cose che solo l'utente root (o equivalente) può fare:

• Installa un rootkit nel kernel.
• Modifica il bootloader per contenere una backdoor anticipata per la persistenza.
• Cancella tutti i blocchi del disco rigido, rendendo i tuoi dati irrecuperabili.

Onestamente, trovo la separazione dei privilegi sulle workstation più utile per proteggere la workstation dal suo più grande nemico: me. Rende più difficile rovinare il mio sistema.

Inoltre, puoi sempre impostare un processo cron come root che esegue un backup della tua home directory (con, ad es., rsnapshot ) e lo memorizza in modo tale che non sia scrivibile dall'utente. Questo sarebbe un livello di protezione nella situazione che descrivi.

Xkcd obbligatorio

Il design originale della sicurezza Unix / Linux consisteva nel proteggere un utente da altri utenti e i file di sistema dagli utenti. Ricorda che 30-40 anni fa, la maggior parte dei sistemi Unix erano configurazioni multiutente con molte persone che si collegavano alla stessa macchina nello stesso momento. Questi sistemi costano decine di migliaia di dollari ed era estremamente raro avere il proprio computer personale, quindi la macchina era condivisa in un ambiente di accesso multiutente.

Il design non è stato concepito per proteggere un utente o file di un utente da codice dannoso, ma solo per proteggere gli utenti da altri utenti, gli utenti dalla modifica del sistema sottostante e gli utenti dall'utilizzo di troppe risorse di sistema. Nella nostra era attuale in cui ognuno ha il proprio computer, il design ha (per lo più) tradotto in macchine per utente singolo che proteggono un processo dall'intrusione di troppe risorse di sistema.

Per questo motivo un programma eseguito dall'utente ha accesso a qualsiasi file che l'utente possiede. Non c'è alcun concetto di ulteriori accessi sui file di un utente. In altre parole, un processo eseguito come utente A ha accesso a leggere, modificare ed eliminare tutti i file che appartengono all'utente A. Ciò include (come si nota) i file di avvio automatico.

Un approccio più moderno può comportare qualche forma di controllo futuro su determinati file. Qualcosa come "ri-autenticazione necessaria" per accedere a questi file, o forse qualche forma di protezione ulteriore dei file di un programma da un altro file di programma. AFAIK non c'è (al momento) qualcosa di simile nel mondo desktop di Linux. Correggimi se sbaglio?

Is there no way to prevent malicious code happening in $HOME?

Per rispondere a questa domanda, ciò che fanno alcune installazioni è utilizzare il framework di sicurezza esistente facendo in modo che un utente esegua il programma in modo specifico. I programmi avranno un'opzione di configurazione per specificare quale utente dovrebbero essere in esecuzione. Ad esempio, la mia installazione di PostgreSQL ha i file di database di proprietà dell'utente postgres e il server di database viene eseguito come postgres . Per i comandi amministrativi di PostgreSQL, cambierei gli utenti in postgres . OpenVPN ha anche la possibilità di passare a un utente non privilegiato dopo averlo fatto usando i poteri amministrativi di root (per aggiungere interfacce di rete, ecc.). Le installazioni possono avere un utente chiamato nobody appositamente per questo scopo. In questo modo, gli exploit su PostgreSQL o OpenVPN non portano necessariamente al compromesso di $HOME .

Un'altra opzione è usare qualcosa come SELinux e specificare esattamente a quali file e altre risorse ha accesso ogni programma. In questo modo, puoi persino negare a un programma in esecuzione come root di toccare i tuoi file in $HOME . Scrivere una politica SELinux dettagliata che specifica ogni programma è noioso, ma credo che alcune distro come Fedora vadano a metà e abbiano politiche definite che aggiungono solo ulteriori restrizioni ai programmi di rete.

Per rispondere alla seconda parte della tua domanda: Esistono meccanismi sandbox, ma non sono abilitati di default sulla maggior parte delle distribuzioni Linux.

Uno molto vecchio e complicato è selinux. Un approccio più recente e più facile da usare è l'apparmor. Il più utile per l'uso personale (i sistemi di apparmor e similiar sono principalmente usati per proteggere i demoni) è firejail , che isola i processi nel loro stesso carcere.

Un firefox può ad esempio scrivere solo la sua directory profilo e la directory Downloads. D'altra parte non sarà possibile caricare le immagini se non le si inserisce nella directory Download. Ma questo è in base alla progettazione di una sandbox del genere. Un programma potrebbe cancellare le tue immagini o caricarle su siti casuali, quindi la prigione impedisce questo.

Usare firejail è facile. Lo installi e per i programmi che hanno già un profilo (guarda in /etc/firejail ) puoi semplicemente fare (come root) ln -s /usr/bin/firejail /usr/local/bin/firefox . Se non si è root o si desidera utilizzare gli argomenti della riga di comando per firejail (ad esempio un percorso personalizzato per i file del profilo) è possibile eseguire firejail firefox .

I sistemi come lo snap richiedono anche l'aggiunta di meccanismi di sandboxing, in modo da poter eseguire un programma non affidabile installato da un repository di snap casuale senza troppe conseguenze. Con tutti questi meccanismi, tieni presente che i programmi non attendibili possono ancora fare cose come inviare spam o far parte di un attacco dDoS.

La presunzione che i dati errati siano protetti è falsa.

Protezione di root attività fa protegge le tue foto delle vacanze dal 2011. E le mie, quelle dei tuoi fratelli e di tutti quelli che usano il computer.

Anche se hai implementato un sistema operativo con uno schema che proteggeva l'account di casa richiedendo una password ogni volta che un'app tentava di accedere a un file e rimosso la protezione della password di root, non la userei perché sarebbe peggio per le foto delle vacanze.

Se mio fratello compromette le funzionalità del sistema principale sul nostro computer di casa, le mie foto delle vacanze vengono cancellate, tagliate a mano o qualsiasi altra cosa nonostante le protezioni della home directory, perché il sistema stesso è ora compromesso e può aggirare qualsiasi livello utente restrizioni implementate.

E molte persone sarebbero molto seccate se dovessero inserire una password ogni volta che hanno scelto File -> Open nel loro word processor.

Inoltre, abbiamo avuto il problema del controllo degli accessi che veniva richiesto troppo spesso sui computer di casa. Quando Microsoft ha lanciato per la prima volta la sua cosa UAC (per la quale non è nemmeno necessario inserire una password se si utilizza l'account principale ... tutto ciò che si deve fare è premere un pulsante ), è venuto fuori molto e la gente si è lamentata abbastanza degli 0,5 secondi della loro vita sprecati 20 volte al giorno che Microsoft l'ha cambiata. Ora, questo non era il tipo di protezione di cui stai parlando, ma ci mostra che se le persone non sono disposte a fare clic su un pulsante di sicurezza alcune decine di volte al giorno per la sicurezza del sistema di Microsoft, non vorranno fare clic (o peggio, digita una password) per qualsiasi cosa venga implementata per proteggere le loro immagini da quell'app casuale che hanno appena lanciato.

Quindi la risposta di base è:

1. Proteggere root protegge le tue foto personali
2. Le persone si lamentano del tipo di autenticazione richiesta troppo spesso.

Un punto chiave per la protezione di root / kernel è integrità forense . Nel caso in cui il dominio contenente i tuoi dati preziosi (utente desktop con documenti privati e token di autenticazione Web, server di sviluppo con codice / risorse riservati, server webapp con database utenti, ecc.) Sia compromesso, hai ancora un dominio senza compromessi da cui valutare il compromesso, determinare cosa è successo, sviluppare un piano per difendersi dall'accadere esattamente nello stesso modo, ecc.

Altre risposte guardano perché * nix è così com'è.

Ma vale la pena notare che c'è spazio per fare qualcosa in più rispetto alla configurazione "out of box", per proteggere la directory home dell'utente, script e file.

La maggior parte dei moderni * nix supporta gli ACL POSIX o varianti, che possono essere configurati per aggiungere il tipo di controllo granulare degli accessi che l'OP sta cercando. È necessario impostarli manualmente e non cercano di distinguere l'accesso su qualsiasi base diversa da quale account utente / gruppo sta agendo. Ma una volta impostato, puoi essere molto specifico su quali account possono eseguire le azioni sui file e ottenere almeno un controllo extra forzando i comandi a utilizzare account limitati per determinati comandi o file, piuttosto che un account utente per tutto. Tuttavia avrà un limite di praticità piuttosto stretto.

Tali privilegi non esistono perché sono scomodi.

L'obiettivo delle autorizzazioni, in generale, è quello di prevenire azioni indesiderate. I tipi di azioni che root può fare sono molto più insidiosi. Un'app ransomware di livello utente potrebbe essere in grado di crittografare i tuoi file, ma non possono nascondere il fatto che lo stanno facendo. Quando trovi un file crittografato, viene aperto come normale e rivela che è stato crittografato. Con un ransomware di livello root, può dirottare l'intero filesystem e creare l'illusione che i file non vengano crittografati fino all'ultimo momento, quindi dimenticare la chiave e bam ! Tutti i tuoi file diventano inaccessibili allo stesso tempo.

Ora ovviamente oggi non si accede come root. Usiamo sudo. Questa è una forma di privilegio basato sui ruoli. Non hai i privilegi di root finché non assumi il ruolo di "un utente che fa attività amministrative". Quindi ottieni questi privilegi, fino a quando non completi il comando.

Un potrebbe creare ruoli a grana fine che hanno accesso a diverse cartelle. Forse vuoi che le "foto delle vacanze" vengano lette solo a meno che non entri nel ruolo di "aggiunta / modifica delle foto". Questo sarebbe potente, ma tassativo. Come ha detto Aaron, l'UAC di Windows è stato ampiamente stroncato per aver sprecato preziosi secondi chiedendo il permesso invece di limitarsi a fare le cose. Il tuo computer avrebbe bisogno di chiedere l'autorizzazione più spesso se dovesse cambiare ruolo per proteggere i tuoi dati. Generalmente gli utenti non hanno trovato che questo valga la pena, quindi non è supportato.

(Se fossi interessato a tali capacità e volessi usare sudo per eseguirle, potresti creare una partizione separata che potrebbe essere montata su ro o rw, a seconda di cosa vuoi fare e memorizzare le tue foto lì).

Uno dei compiti più difficili da affrontare in questi casi è la granularità dei ruoli. Se l'utente entra in un ruolo o in un altro, è abbastanza facile da gestire. È più difficile, tuttavia, gestire il caso in cui una particolare applicazione deve inserire quel ruolo. Forse a Firefox non è permesso scrivere sulle tue foto, ma GIMP è autorizzato a farlo. Ciò è complicato perché laddove esistono dei limiti, non è possibile avere un'integrazione coerente e coerente. Cosa succede se Firefox sfrutta un plug-in GIMP per eseguire il fotoritocco? L'unico modo per impedire a Firefox di farlo è di impedirgli di parlare con GIMP.

Suppongo che tu abbia una certa esperienza con Windows. Ti sei mai chiesto perché lo schermo si attenua quando viene visualizzato l'UAC? In realtà non per la conferma visiva che stai facendo qualcosa di speciale. È molto più importante di quello. Le finestre sopra la parte oscurata fanno parte di uno schermo diverso , isolato dalle finestre sottostanti. Perché questo è importante? Bene, si scopre che ogni finestra su uno schermo può manipolare qualsiasi altra finestra sullo stesso schermo. Se il controllo dell'account utente si avvicina alla stessa schermata del programma di installazione che richiede le autorizzazioni, il programma di installazione potrebbe letteralmente solo ottenere un handle nella finestra UAC e fare clic su OK per te ! Ciò avrebbe sicuramente vanificato lo scopo di un simile suggerimento. La soluzione è che l'UAC è fornito su una diversa , quindi nessun'altra applicazione può fare clic su OK da sola. L'unico modo per fare clic su OK è se l'utente sposta il mouse e fa clic su di esso. L'oscuramento è proprio lì per mostrarti che non puoi interagire con nessuna delle finestre sottostanti mentre lo schermo UAC ha il controllo della tastiera / del mouse.

Quindi questo è il livello di sforzo che deve essere affrontato per l'isolamento. Non è facile. Infatti, è abbastanza difficile che abbia senso per te proteggere i tuoi dati chiave avendo più account utente e dando a ciascuno un accesso diverso ai dati. Quindi è possibile utilizzare la funzionalità switch-user per passare da una all'altra. Questo fornirebbe il tipo di isolamento necessario per fare dei buoni privilegi basati sui ruoli.

Unix non è in realtà un sistema desktop. È un sistema che gira su un grande computer che costa circa quanto una casa situata nel seminterrato dell'università. Tu, come qualcuno che non può permettersi il suo computer, devi condividere il computer con altri duemila, e con diverse decine di utenti contemporaneamente per quella materia.

Per inciso, oggi anche puoi far girare un sistema simile a Unix sul tuo computer desktop o su un SoC di una carta di credito che costa $ 20.

In linea di principio, tuttavia, Unix non è progettato per utenti singoli. L'utente singolo non è importante. Ciò che è nella tua directory home è il tuo problema, ma ciò che root può fare è il problema di tutti. Pertanto, solo le poche attività che richiedono realmente di lavorare come root devono essere eseguite con tale utente e preferibilmente (per limitare la finestra temporale durante la quale è possibile fare del male) non accedendo con tale account, ma utilizzando in modo esplicito sudo per i singoli comandi che lo richiedono. C'è anche molta religione in questo, ed è per questo che alcuni distributori sono così dannatamente arroganti da minacciarti quando digiti su piuttosto che sudo per ognuno dei 10 diversi apt di comandi che devi eseguire installare qualche piccola cosa Questo incidente verrà segnalato , beh, dimmi, cazzo, il tuo rapporto. Alcune persone sanno davvero come infastidire gli altri.

Quindi puoi cancellare tutte le tue foto personali senza essere root . Giusto. Il malware può cancellare tutte le cose nella tua home directory, giusto. Può negare il servizio riempiendo il disco fino a raggiungere la quota dell'utente, giusto. Ma dal punto di vista del sistema, questo è solo il tuo problema, e a nessun altro importa. Nessun altro utente è (in linea di principio) interessato.

Ora, il problema con un singolo sistema utente moderno (o pochi) è che il modello di sicurezza logica bivalente è del tutto inapplicabile, proprio come l'idea "c'è centinaia di utenti".

Sfortunatamente, è molto difficile trovare qualcosa di meglio. Guarda Windows se vuoi vedere come non rubare un'idea (sono riusciti davvero a peggiorare l'approccio).

Alcuni web browser e sistemi telefonici (o smart TV) tentano (e falliscono) di fornire qualcosa di meglio, e il Linux moderno ha anche un sistema più fine (ma non saprei come configurarlo correttamente senza spendere settimane del mio tempo).

Il problema è che il modello di sicurezza bivalente presuppone che le normali applicazioni non richiedano alcun privilegio (che è sbagliato perché alcune cose per lo più innocue richiedono privilegi) mentre le applicazioni non normali richiedono l'accesso completo al sistema informatico (che è anche sbagliato, quasi nessun programma ha bisogno di accesso completo, mai).

D'altra parte, anche i modelli di sicurezza a grana più fine (che sono ancora piuttosto grossolani) fanno presupporre erroneamente che se un'applicazione richiede un set di privilegi, ha davvero bisogno di quel set completo e l'utente è a suo agio nel concederlo.

Per quanto ne so, non esiste un sistema in cui un'applicazione possa richiedere i privilegi A, B e C e l'utente può accettare di concedere A (ma non B e C) e l'applicazione può quindi interrogare quali privilegi è stato dato e decide se è in grado di eseguire l'attività richiesta o no.

Quindi, in genere, hai la possibilità di concedere XYZ-app "memorizza i dati su un archivio permanente" (con cui puoi essere OK) e anche che consente "accedi alla mia posizione" e "accedi al mio dati personali "o" installa il driver di sistema "(con cui non sei d'accordo), o bene, non puoi eseguire il programma.
Oppure, puoi consentire al programma XYZ di "apportare modifiche al tuo computer", qualunque cosa ciò significhi, oppure puoi scegliere di non eseguirlo. E, devi confermarlo di nuovo ogni volta. Che, onestamente, fa davvero schifo dal punto di vista dell'utente.

Is there no way to prevent malicious code happening in $HOME?

Supponendo che tu abbia /home come singolo punto di innesto, sulla propria partizione - allora puoi semplicemente modificare /etc/fstab e aggiungere il flag noexec alle opzioni di montaggio. Ciò disabilita tutta l'esecuzione del codice su quella partizione, con il lato negativo che il codice all'interno di ~/bin (come alcune installazioni per utente possono crearlo) inoltre non verrà eseguito più. questo tuttavia non fermerà un eseguibile posizionato altrove nel file system per cancellare /home .

SE Linux è un sistema di sicurezza completo, che può benissimo isolare - mentre AppArmor è solo per l'isolamento delle applicazioni. Il Linux sottostante di Android lo caratterizza, poiché v 5.0 qualcosa. Su Windows, hanno introdotto di recente "cartelle protette" che è piuttosto la stessa (una fregatura completa). qui il lato negativo è che, quando si installa manualmente qualcosa di nuovo, si deve spesso etichettare e / o impostare i flag appropriati, per permettere che, mentre il contesto in cui qualcosa viene eseguito è molto importante lì. le persone spesso suggeriscono di disabilitarlo, semplicemente perché non capiscono come gestirlo. beh, questo non è esattamente il punto di scegliere una distribuzione SE Linux per una distribuzione.

Sono sorpreso che nessuno abbia menzionato quanto segue:

Uno dei motivi principali per non accedere a una macchina desktop come root è perché molte attività cambieranno la proprietà dei file per diventare root. Questo in genere significa che gli utenti "normali" non saranno in grado di eseguire molte applicazioni perché non possono leggere il file di configurazione predefinito creato da root.

Uno dei motivi principali per cui non ci si collega a una macchina server come root è che da una prospettiva di verifica / tracciabilità, è meglio avere qualcuno che si connette come se stessi e quindi eseguire i comandi come root in modo che ci sia un registro verificabile che indichi che 'utente1' ha effettuato l'accesso e quindi è passato a root invece di sapere che 'root' ha effettuato il login dall'indirizzo IP 10.2.1.2 che potrebbe essere un terminale generico disponibile per molte persone. Su una macchina server è più comune avere accesso limitato sudo a molti comandi per tentare di mantenere le azioni eseguite da un amministratore più verificabili e tracciabili.

Come con tutte le attività di root, puoi fare quello che vuoi; ricorda che più fai, più grande è la pistola puntata verso il tuo piede e basta un comando sbagliato per tirare quel grilletto.

rm -rf {uninitializedVariable}/*