Scopo della sicurezza di chiedere la password dell'amministratore per montare la partizione su Linux

When I wanted to access the NTFS partition fedora asked me for my admin password to mount that partition. Why does it do that? What security purpose does it have?

Come tutti gli altri hanno detto, devi essere l'utente root per montare le partizioni, salvo alcune eccezioni speciali come la definizione della partizione e l'impostazione del flag user sulla voce in /etc/fstab .

Perché questo è importante limitare è perché mount può sovrapporre qualsiasi punto di montaggio su qualsiasi altra directory, o anche solo un albero di directory su un altro. Con il permesso di eseguire mount, potrei inserire /home/jeff/bin sopra /bin usando mount /home/jeff/bin /bin -o bind . All'improvviso tutti usano la versione di su , ls o qualsiasi altra cosa desideri dalla mia directory.

Come farebbe dimostrare quanto sopra, i mount point non devono essere vuoti. Tutto in una directory montata sopra diventa semplicemente inaccessibile. Mount è in grado di trasformare qualsiasi cosa in una struttura di directory, non solo in partizioni. I file system di loopback e le unità di rete remote sono anche possibili origini di montaggio.

Quindi, nel sistema multiutente, non si è in grado di camminare su tutta la struttura del filesystem usando mount perché si rompono completamente le restrizioni di sicurezza e si presume che i file provengano dalla posizione che ci si aspetta che siano perché qualcuno potrebbe semplicemente monta una directory per mascherarne un'altra.

Permettere a chiunque di montare qualsiasi file system in qualsiasi posizione aprirebbe un certo numero di falle nella sicurezza.

• Un ovvio è che il driver del filesystem accede al dispositivo sottostante. Questo potrebbe essere l'hardware che l'amministratore di sistema non vuole esporre agli utenti.
• Un altro ovvio è che potrebbero esserci file che consentono agli utenti di ottenere privilegi. Una shell radice setuid, per esempio. O un nodo di dispositivo che consente l'accesso non elaborato alla memoria o al disco o altra risorsa hardware. Consentire a un utente di montare un filesystem arbitrario gli consente di creare arbitrari setuid / setgid programmi e nodi del dispositivo .
• Un problema più sottile è che montare un filesystem potrebbe creare file in una posizione inaspettata. Alcune applicazioni leggono i file in posizioni fisse o fidano di file in cui la catena di directory dalla radice al file è interamente di proprietà di un utente. Il montaggio di un diverso filesystem lungo il percorso potrebbe consentire al mounter di sostituire file legittimi con contenuti arbitrari. Ad esempio, puoi quindi montare una copia di /etc con un diverso file passwd con una password di root impostata dall'utente. Oppure puoi montare una directory diversa sulla home directory di un utente e fornire il tuo .ssh/authorized_keys .
• Un'altra preoccupazione è che i driver del filesystem sono spesso scritti per prestazioni e affidabilità con filesystem ben formati. Se un filesystem è malformato, può attivare un bug nel driver che consente a chiunque controlli il dispositivo sottostante di eseguire codice nel contesto del driver del filesystem, che viene eseguito tradizionalmente nel kernel.

Puoi dichiarare un dispositivo, un punto di montaggio e opzioni di montaggio in /etc/fstab per montare automaticamente un filesystem su tempo di avvio. È compito dell'amministratore di sistema non mettere nulla di "pericoloso" lì, per esempio nessun montaggio di filesystem sconosciuti nei percorsi di sistema, disabilitare setuid eccetto il filesystem di root, ecc.

Il vecchio modo di permettere agli utenti ordinari di montare filesystem transienti è di mettere l'opzione user mount su un fstab, in genere combinato con noauto . user implica automaticamente altre tre opzioni: nosuid , nodev e noexec . Queste opzioni disabilitano i file setuid / setgid (questi bit non hanno alcun effetto), i file del dispositivo (i nodi del dispositivo non hanno effetto) ei file eseguibili (il bit eseguibile viene ignorato tranne che nelle directory) rispettivamente. Le opzioni nosuid e nodev sono fondamentali; noexec può essere disabilitato (aggiungendo exec dopo user ) in quasi tutte le situazioni. Ecco una tipica linea fstab per un dispositivo rimovibile:

/dev/cdrom  /media/cdrom  iso9660  noauto,user,exec

Un metodo più moderno per consentire agli utenti di montare dispositivi rimovibili consiste nell'installare il programma pmount . Questo programma ha politiche più flessibili di fstab, che consente solo un elenco predefinito. Pmount applica diversi vincoli, tra cui la richiesta che il dispositivo sia dichiarato rimovibile e il punto di montaggio sia una directory vuota sotto /media .

Per le risorse di rete, l'approccio tradizionale per andare oltre un elenco predefinito è un automounter . L'automounter è in genere configurato per consentire agli utenti di montare solo filesystem di rete (NFS, Samba), solo da host controllati (o almeno solo all'interno di un dominio), con opzioni predefinite che includono nodev e nosuid .

Un approccio più moderno per consentire agli utenti di montare i filesystem è di spostare il driver del filesystem fuori dal kernel. FUSE è lo standard di fatto qui (su Solaris, Linux, * BSD, OSX). L'utente deve avere accesso al dispositivo sottostante (se presente) poiché tutti gli accessi al dispositivo sono eseguiti da un processo non privilegiato. Per lo stesso motivo, un bug nel driver del filesystem non comprometterà la sicurezza del sistema operativo. L'utente deve possedere il punto di mount, quindi non sarà in grado di far apparire i file dove altrimenti non potrebbe far apparire i file. I bit Setuid e Setgid vengono ignorati. Tuttavia, è possibile rendere i file di proprietà di qualsiasi utente, non solo l'utente che esegue il montaggio.

fedora asked me for my admin password

Come dice correttamente Zzz, solo root può montare / smontare le partizioni. In realtà, solo root può fare molte cose, ad esempio includendo il binding alle porte inferiori a 1024.

Con un solo utente root, la condivisione della password di root diventa un problema - inoltre, abilitare il login diretto come root potrebbe essere considerato un rischio per la sicurezza più o meno come uno potrebbe rinominare l'account Administrator su Windows - per deviare un obiettivo comune .

Ubuntu risolve questo problema generando una password casuale per root al momento dell'installazione e aggiungendo utenti che necessitano dell'accesso root a un gruppo specifico il quale può eseguire comandi tramite sudo in /etc/sudoers . Il login di root viene quindi bloccato e l'esecuzione dei comandi di amministrazione può essere eseguita da un utente normale tramite sudo , gksudo o dal prompt di root tramite sudo -i .

Fedora è andata a metà strada - il login di root è ancora permesso, ma gli utenti che si trovano nel gruppo wheel possono eseguire sudo con la propria password (anziché root). La riga specifica in /etc/sudoers che abilita questo è:

%wheel ALL=(ALL) ALL

Ora, due note storiche:

• Alcuni comandi in Fedora non sono a conoscenza dell'uso di sudo e richiedono root. I comandi di root di Fedora venivano utilizzati tramite su -c che si verifica ancora nei documenti in luoghi, quindi a volte è necessaria la password di root.
• Storicamente, su sta per "switch user" e il gruppo wheel è il gruppo autorizzato a eseguire su .

E alcune note finali sulla sicurezza di unix:

• avrai sentito parlare di setuid e setgid bit. Ciò consente a un processo di essere eseguito nel contesto dell'utente proprietario e del gruppo rispettivamente, piuttosto che chi li ha avviati, ed è il modo tradizionale di consentire agli utenti di avviare processi che richiedono alcune funzionalità di livello root.
• Questo è in realtà deprecato - fedora ha adottato le capacità posix preferibilmente a questo, che distribuiscono le funzionalità root in base alle necessità, consentendo l'avvio di molti processi non-root.

[Hai installato Windows XP e sei preoccupato per la sicurezza? : P]

(Optional) The rights are currently elevated for anyone in the wheel group (system administrators). You can select only particular users e.g. this way

suona bene finora. Vorrei controllare i permessi sul filesystem dopo che è stato montato, cosa che non menzionano esplicitamente. Per esempio. lancia "mount" e cerca l'opzione "uid" di mount su questa partizione. Mi aspetto che vada tutto bene.

Quindi l'implicazione è che qualsiasi compromissione dell'utente Linux può facilmente compromettere l'intera installazione di Windows - e quindi l'intero sistema, non appena si avvia Windows. Questo non è necessariamente un grosso problema. Una volta che l'utente sudo / su-using è stato compromesso, hai già perso! A meno che non si tratti di un sistema multiutente, una volta che l'utente è stato compromesso, ciò influisce su tutte le cose importanti - password che inserisci sulla tastiera, file, email, attività online, ecc. E le vulnerabilità di escalation dei privilegi si verificano abbastanza spesso comunque.

Se si desidera approfondire la difesa, è possibile riorganizzare le partizioni in modo che i dati condivisi si trovino su una partizione diversa da Windows XP. Questo è consigliato solo se sei in grado di eseguire il backup di tutti i tuoi dati, perché c'è molto spazio per commettere errori durante la riorganizzazione delle partizioni.

In alternativa potresti provare ad ottenere lo stesso effetto con uno script di init personalizzato. Montare l'intero FS con l'opzione uid = desiderata, associare la directory dei dati condivisa a un secondo punto di montaggio, quindi smontare l'originale. Sono abbastanza sicuro che funzioni per FAT comunque. Io spero non c'è un modo subdolo per aggirare questo: le persone usano "spazi dei nomi del filesystem" come uno strumento di sicurezza, e non è noto ... male, come chroot lo è.

Solo root può montare partizioni (se non diversamente configurato). Altrimenti chiunque potrebbe fare del male smontando le partizioni, cambiando le opzioni di mount, ecc.