Quanto possiamo contare sulle autorizzazioni del filesystem per la sicurezza?

La mia domanda riguarda le autorizzazioni del filesystem (in particolare le autorizzazioni in stile Unix) e come si relazionano con la sicurezza.

Supponi di avere accesso a un computer con un account utente guest e un utente di nome Bob. Non conosco la password di Bob, ma posso usare l'account ospite. L'account guest non ha assolutamente permessi di lettura per tutti i file di Bob, quindi non posso leggere nessuno dei file di Bob mentre eseguo l'accesso come guest.

Tuttavia, da una vera prospettiva "avversaria", ho pieno accesso a questo disco non crittografato. Potrei immaginarlo, salvarlo per dopo, eseguire qualche altro sistema operativo per leggere semplicemente i file di Bob ignorando le impostazioni delle autorizzazioni del filesystem.

Da questo, arrivo alla domanda:

1. Un'impostazione delle autorizzazioni del filesystem su un disco non crittografato è solo un flag, giusto? E l'unica cosa che mi impedisce di leggere i file per i quali non ho il permesso è il fatto che il sistema operativo dirà "Oh, non puoi leggerlo, non hai il permesso." Quel file è ancora sul disco in forma grezza e potrei leggerlo semplicemente ignorando i flag del filesystem (diciamo, tramite un sistema operativo di avvio ombreggiato che ignora semplicemente le autorizzazioni). È tutto corretto?

Ora dì che non ho accesso diretto al disco e sto solo inserendo una macchina. Non ho il permesso di leggere nessuno dei file di Bob. Non c'è davvero niente che io possa fare al riguardo, giusto?

2. Date le mie autorizzazioni limitate, semplicemente non riesco ad accedere ai file di Bob, non importa quanto ci provi, no? Cosa succede se utilizzo un exploit per ottenere l'accesso come root? Ora posso ignorare i flag di autorizzazione del sistema operativo? È una cosa che succede mai?

Risposta più breve.

Se si dispone dell'accesso fisico a un sistema informatico (PC o sistema di archiviazione dati) e l'unica "protezione" in atto sono le autorizzazioni per i file, non si ha alcuna protezione al 100%.

Che i dati non crittografati possano essere copiati e clonati con il minimo sforzo, quasi senza strumenti diversi dall'avere un altro dispositivo, è possibile collegarsi all'unità di sistema per fare una copia dei dati.

E sì, potenzialmente alcuni aspetti probatori di penetrazione fisica potrebbero aver bisogno di essere preso in considerazione in accesso a livello fisico; come assicurarsi che non vengano lasciate le impronte digitali e che vengano trattati anche eventuali sigilli "manomissione". Ma onestamente, la stragrande maggioranza dei sistemi là fuori può rimuovere fisicamente le proprie unità per una copia fisica dei dati senza che l'utente finale ne sia a conoscenza. Se si dispone dell'unità, si dispone dell'unità e quindi si hanno i dati se non è crittografato.

Questo è il motivo per cui al giorno d'oggi la crittografia per utente o la crittografia dell'intero disco è una cosa così grande; laptop e altri dispositivi di elaborazione portatili sono oggi una parte così grande del mercato che il rischio di perdita di dati a causa del furto del dispositivo o del prestito occasionale di un PC è molto più elevato di quanto non sia mai stato in passato.

Se il disco non è crittografato, i dati su di esso sono un libro aperto pronto per la lettura. Questo concetto non è limitato alle macchine Linux / Unix ma a qualsiasi sistema operativo ovunque; se hai accesso fisico a un sistema non crittografato hai il sistema.

Detto questo, i permessi sui file sono una misura di sicurezza utile per server remoti di ogni tipo.

Risposta più lunga.

La mia domanda riguarda le autorizzazioni del filesystem (in particolare le autorizzazioni in stile Unix) e come si relazionano con la sicurezza.

Innanzitutto, tieni presente che la sicurezza sui computer — e su tutto — è davvero solo un deterrente che rallenta le cose e non fornisce necessariamente una sicurezza assoluta.

Ad esempio, il pezzo più debole di sicurezza in qualsiasi edificio fisico è la porta che devi aprire quando entri / esci o la finestra che devi aprire per consentire l'ingresso dell'aria. Sì, puoi bloccare porte e finestre e impostare allarmi ma se qualcuno vuole veramente avere accesso a qualcosa - e hanno il tempo, le risorse, la ricchezza e gli sforzi per perseguirlo - avranno accesso ad esso.

Supponi di avere accesso a un computer con un account utente guest e un utente di nome Bob. Non conosco la password di Bob, ma posso usare l'account ospite. L'account guest non ha assolutamente permessi di lettura per tutti i file di Bob, quindi non posso leggere nessuno dei file di Bob mentre eseguo l'accesso come guest.

Il problema qui è il contesto di accesso. Se hai accesso fisico a un computer, praticamente tutto è possibile. Ma se si è connessi solo tramite una connessione remota, su una rete di qualche tipo, la proprietà del file system è sicuramente un metodo di sicurezza efficace. E nel caso dei server Linux / Unix, le autorizzazioni e la proprietà sono forme efficaci di sicurezza per scoraggiare le intrusioni remote.

Questo è il motivo per cui nel mondo Linux / Unix l' rootaccesso a un sistema remoto è considerato un tale premio. Accedi roota un sistema remoto e poi hai veramente fatto qualcosa che ti dà un maggiore accesso senza bisogno di entrare in un data center e clonare un'unità.

Tuttavia, da una vera prospettiva "avversaria", ho pieno accesso a questo disco non crittografato. Potrei immaginarlo, salvarlo per dopo, eseguire qualche altro sistema operativo per leggere semplicemente i file di Bob ignorando le impostazioni delle autorizzazioni del filesystem.

Sì. Esattamente. Se hai accesso fisico alla macchina, allora - come spiegato all'inizio - tutte le scommesse sono disattivate. È possibile ottenere l'accesso ai file e alle directory di proprietà di altri creando un'immagine del disco - o anche semplicemente perseguendo i contenuti non elaborati dell'unità stessa - con poco o nessun profondo sforzo tecnico.

Chiunque, ad esempio, ti presti il ​​proprio personal computer e crei un nuovo account solo per te senza pensare a questo scenario, in pratica sta dando via tutti i dati personali che ha sulla propria macchina senza saperlo davvero.

Leggero tangente, ma penso che sia per questo che così tanti utenti occasionali donano vecchi PC senza fare il minimo sforzo per cancellare i dati sul disco. Impostano una password utente e presumono che i loro dati siano stati protetti nella misura in cui potevano semplicemente lanciare l'unità nel cestino e non pensarci due volte. Quando la realtà è senza vera crittografia o cancellazione dei dati, qualsiasi unità lanciata nella spazzatura o venduta usata può essere letta da chiunque ovunque senza molto sollevamento o sforzo tecnico profondo.

I tuoi tre punti:

1. Se si utilizza SSH come utente normale, non si ha accesso al dispositivo disco non elaborato. In genere è necessario rooto disporre dell'autorizzazione per accedere ai dispositivi disco logici e non elaborati.

2. Se ottieni il root attraverso un exploit, sei l'utente più potente del sistema e hai accesso a quasi tutto, incluso il dispositivo. Dato che sei root, puoi accedere direttamente ai file di Bob, quindi non è necessario accedere al dispositivo disco.

3. Ritmi di accesso fisico root. La radice è un livello logico. Puoi ignorarlo con accesso fisico al disco. Ciò include il caricamento di detto disco in un sistema operativo separato in cui si è root.

Naturalmente, i sistemi dovrebbero essere induriti contro gli rootexploit, ma ogni giorno escono nuovi exploit. Nessun sistema è sicuro al 100%, ma puoi renderlo sicuro per scopi pratici limitando l'accesso.

Le autorizzazioni del file system dovrebbero funzionare solo in situazioni di accesso con utenti limitati, in cui il sistema operativo non è compromesso. È un sistema "mantieni gli utenti onesti (e tipici) onesti", come i lucchetti per bici. Funziona per prevenire i "crimini di opportunità" più che una protezione totale sicura.