GNU/Linux >> Linux Esercitazione >  >> Linux

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

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

Il sistema dei permessi di root ha senso, ma sui sistemi desktop sembra che protegga i dati sbagliati.

I permessi del superutente esistono per proteggere il sistema dai suoi utenti. Le autorizzazioni sugli account utente servono a 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 pieno accesso alla tua home directory, hai dato transitivamente 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 dannosi (password, configurazione, file binari), potresti avere dati nella tua home directory che necessitano dello stesso tipo di protezione.

Il principio del privilegio minimo dice che non dovresti concedere più accesso di quanto sia assolutamente necessario. Il processo decisionale per l'esecuzione di qualsiasi programma dovrebbe essere lo stesso per quanto riguarda i tuoi file come lo è per i file di sistema. Se non fornisci un pezzo di codice di cui non ti fidi l'uso illimitato dell'account di superutente nell'interesse della protezione del sistema, non dovrebbe essere concesso l'uso illimitato del tuo account nell'interesse della protezione dei tuoi dati.

Non c'è modo di impedire che si verifichi codice dannoso in $HOME? E perché a nessuno interessa?

Unix non offre permessi così granulari per lo stesso motivo per cui non c'è un blade guard attorno al comando rm:i permessi non sono lì per proteggere gli utenti da se stessi.

Il modo per evitare che il codice dannoso danneggi i file nella tua home directory è non eseguirlo utilizzando il tuo account. Crea un utente separato che non disponga di autorizzazioni speciali ed esegui il codice con quell'UID fino a quando non avrai determinato se puoi fidarti o meno.

Ci sono altri modi per farlo, come le jail in chroot, ma impostarle richiede più lavoro e sfuggirle non è più la sfida di una volta.


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

UNIX è alla base dei sistemi operativi più diffusi, e anche la grande eccezione Windows ne è stata influenzata più di quanto sembri. Deriva da un'epoca in cui i computer erano macchine grandi, costose e lente utilizzate esclusivamente da specialisti arcani.

A quel tempo, gli utenti semplicemente non disponevano di ampie raccolte di dati personali su nessuno computer, non il loro server universitario, non il loro personal computer (e certamente non il loro cellulare). I dati che variavano da utente a utente erano in genere dati di input e output di processi di calcolo scientifico:perderli potrebbe costituire una perdita, ma in gran parte compensabile ricalcolandoli, certamente niente come le conseguenze delle odierne fughe di dati.

Nessuno avrebbe avuto il proprio diario, le informazioni bancarie o le foto di nudo su un computer, proteggendoli così da accessi dannosi non era qualcosa che aveva un'alta priorità - in effetti, la maggior parte degli studenti universitari negli anni '70 sarebbe stata probabilmente entusiasta se altri hanno mostrato interesse per i loro dati di ricerca. Pertanto, la prevenzione della perdita di dati è stata considerata la massima priorità nella sicurezza informatica e ciò è adeguatamente garantito da backup regolari piuttosto che dal controllo degli accessi.


Questa è un'osservazione molto astuta. Sì, il malware in esecuzione mentre l'utente può danneggiare/distruggere/modificare i dati nella tua home directory. Sì, la separazione degli utenti sui sistemi a utente singolo è 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 in modo che contenga una backdoor iniziale 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 e rompere il mio sistema.

Inoltre, puoi sempre impostare un cron job come root che esegua un backup della tua home directory (con, ad esempio, rsnapshot ) e lo memorizza in modo che non sia scrivibile dall'utente. Sarebbe un certo livello di protezione nella situazione che descrivi.

Obbligatorio xkcd


Linux
  1. Spazio riservato per il root su un filesystem:perché?

  2. Perché l'utente root ha bisogno dell'autorizzazione Sudo?

  3. Linux:perché Archlinux mantiene alcuni utenti/gruppi dopo la disinstallazione del pacchetto?

  4. Perché non è possibile trovare Read /run/user/1000/gvfs anche se è in esecuzione come root?

  5. Installa WordPress su un account utente come root

La funzione di root del gruppo utente??

Differenza tra utente Sudo e utente root?

Dove in genere archiviano i dati le applicazioni?

Come limitare l'utente root in CentOS

Utente predefinito non root di Kali

Perché l'utente più potente su un sistema Unix/Linux si chiama "root?"