Le autorizzazioni per i file impostate in Unix / Linux sono efficaci in Windows o in qualsiasi altro SO?

3

Considera alcuni file e cartelle in Unix / Linux OS che sono configurati per il solo accesso in lettura da root, se il disco rigido è stato rubato e utilizzato in Ambiente Windows, queste autorizzazioni sono ancora valide?

Stesso scenario: l'impostazione delle autorizzazioni per file e cartelle in Windows (specialmente quando si utilizza il controller di dominio) sono queste autorizzazioni efficaci quando si accede a questi file utilizzando altri sistemi operativi?

Dal punto di vista della sicurezza: senza crittografia: esiste un altro modo per proteggere file e cartelle nel sistema operativo incrociato con autorizzazioni di accesso ai file efficaci?

    
posta Akam 05.02.2013 - 07:20
fonte

3 risposte

7

se il disco rigido rubato e sistema operativo incrociato sono due condizioni diverse!

  • Se rubati, montati in un altro host, tutte le autorizzazioni sono compromesse, tutti potrebbero essere root nel suo host e montare il disco rigido (magari esterno via USB - Sata changer) con tutto il necessario diritti. Per questa condizione, la crittografia (strong) è l'unico modo.

  • Informazioni su cross OS , se l'unità rimane montata in un sistema operativo Un * x e serve i suoi file attraverso un server di condivisione, come samba , ftpd , netatalk o altro, permesso sono utilizzati dal server stesso e potrebbero essere rispettati da tutti i clienti. Non è necessaria la crittografia locale se l'accesso al server è correttamente protetto.

    • Informazioni su controller di dominio , samba esegui i diritti utente della finestra di wrap su un * x file system ACL, quindi tutto funziona correttamente localmente e in remoto.

Senza alcuna considerazione sugli errori di sicurezza.

    
risposta data 05.02.2013 - 07:59
fonte
4

Le autorizzazioni sono definite dal sistema operativo. Se si ignora il sistema operativo, le autorizzazioni sono irrilevanti.

Non è possibile avere il controllo di accesso (autorizzazioni) senza autenticazione (determinare se la persona che richiede l'accesso è autorizzata). Ad esempio, per far sì che un file sia accessibile solo a root, è necessario determinare se l'utente è root. Questa determinazione è significativa solo nel contesto del sistema operativo originale.

Per avere il controllo di accesso inerente a un supporto di memorizzazione, è necessario un modulo di autenticazione esterno al supporto. Per proteggere i dati su un disco al di fuori del contesto del sistema a cui è collegato, il controllo degli accessi non può fare affidamento su alcuna informazione presente sul disco. Ad esempio, è possibile limitare fisicamente chi ha accesso al disco. Se si assume che questa forma di controllo degli accessi possa essere violata (un disco rubato), è necessario qualcos'altro. Il controllo dell'accesso tramite la crittografia si basa su due aspetti: la matematica, che è immanente e non può essere aggirata¹, e la conoscenza di alcuni segreti (password o chiave). Così puoi avere il controllo degli accessi usando la crittografia che non dipende dal supporto utilizzato in un particolare sistema, e in particolare continua a funzionare se il disco viene rubato.

Per mantenere riservati i file in questo scenario, crittografali. Un utente malintenzionato con un disco rubato può effettuare attacchi di forza bruta limitati solo dal numero di processori che dedica al compito (la velocità del disco non è un fattore limitato, perché il ladro può fare tutte le copie che gli piacciono dei dati crittografati). Pertanto, assicurati di utilizzare una password complessa che l'utente malintenzionato non troverà facilmente mediante ipotesi ripetute (automatizzate). Con un software adeguato, puoi ridurre il numero di tentativi a una manciata al secondo per CPU.

Se si dà accesso al sistema Linux da un sistema Windows tramite un protocollo di rete, è una storia diversa. L'accesso verrà concesso in base alle impostazioni di tutti i sistemi coinvolti: il sistema che contiene il disco, il sistema in cui si trova l'utente e il sistema contenente i dati di autenticazione (ad esempio un controller di dominio) se si tratta di un sistema diverso.

¹ Esclusione di importanti scoperte matematiche, ma si può presumere che ciò non accadrà. La crittografia (se fatta bene, che è difficile) è più robusta sotto questo aspetto rispetto, ad esempio, alle guardie armate (che possono essere corrotte o arruolate).

    
risposta data 05.02.2013 - 11:37
fonte
3

Le "autorizzazioni" del file non sono intrinseche. I permessi dei file sono un tag allegato al file, affermando: "per favore, chiunque abbia il potere di concedere o negare fisicamente l'accesso al file, fallo in queste condizioni". Il sistema operativo stesso dovrebbe onorare le richieste. Se il sistema operativo vuole ignorare le autorizzazioni del file, le autorizzazioni del file verrebbero completamente ignorate.

È come un club con un buttafuori. Il buttafuori decide chi entra e chi resta fuori. Ma nessuno può impedire al buttafuori di entrare ed uscire come crede.

Crittografia cambia il modello rendendo l'accesso condizionale alla conoscenza di un segreto specifico. Questo non è più un problema di permessi : non sapere che la chiave equivale a non avere il disco. Nell'analogia del club: si consideri un buttafuori amnesiacea. Se il buttafuori non ricorda dove si trova effettivamente il club, non sarà in grado di concedere o negare l'accesso a nessuno, incluso se stesso.

    
risposta data 05.02.2013 - 12:52
fonte

Leggi altre domande sui tag