Come fakeroot non è una violazione della sicurezza in Linux?

Dopo aver letto alcune belle risposte a questa domanda , sono ancora confuso sul motivo per cui vorresti far finta di essere root senza ottenere nessuno dei vantaggi di essere realmente root.

Finora, ciò che posso raccogliere è che fakeroot viene utilizzato per dare la proprietà a un file che deve essere root quando è decompresso / tar. La mia domanda è: perché non puoi semplicemente farlo con Chown?

Una discussione di Google Gruppi qui sottolinea che è necessario fakeroot per compilare un kernel Debian (se si desidera farlo da un utente non privilegiato). Il mio commento è che, il motivo per cui è necessario essere root per compilare è probabilmente perché le autorizzazioni di lettura non sono state impostate per altri utenti. Se è così, non è una violazione della sicurezza che fakeroot consente la compilazione (il che significa che gcc ora può leggere un file che era per root)?

Questa risposta qui descrive che le effettive chiamate di sistema vengono effettuate con vero uid / gid dell'utente , quindi di nuovo dove aiuta fakeroot?

In che modo fakeroot ferma le escalation di privilegi indesiderate su Linux? Se fakeroot può ingannare Tar nel creare un file di proprietà di root, perché non fare qualcosa di simile con SUID?

Da quello che ho raccolto, fakeroot è utile solo quando vuoi cambiare il proprietario di tutti i file del pacchetto che hai creato come root. Ma puoi farlo con chown, quindi dove mi manca la mia comprensione di come questo componente dovrebbe essere usato?

Finora, ciò che posso raccogliere è che fakeroot viene utilizzato per dare la proprietà a un file che deve essere root quando è decompresso / tar. La mia domanda è: perché non puoi semplicemente farlo con Chown?

Perché non puoi semplicemente farlo con chown, almeno non come utente non root. (E se si esegue come root, non è necessario fakeroot.) Questo è il punto fakeroot: consentire a programmi che si aspettano di essere eseguiti come root per essere eseguiti come utenti normali, fingendo che le operazioni che richiedono root abbiano esito positivo.

Questo viene utilizzato in genere durante la creazione di un pacchetto, in modo che il processo di installazione del pacchetto che si sta installando possa procedere senza errori (anche se è in esecuzione chown root:rooto install -o root, ecc.). fakerootricorda la falsa proprietà che pretendeva di fornire file, quindi le operazioni successive che guardano alla proprietà vedono questo invece di quello reale; questo consente ad taresecuzioni successive , ad esempio, di archiviare file di proprietà di root.

In che modo fakeroot ferma le escalation di privilegi indesiderate su Linux? Se fakeroot può ingannare Tar nel creare un file di proprietà di root, perché non fare qualcosa di simile con SUID?

fakerootnon induce tara fare nulla, preserva le modifiche che la build desidera apportare senza lasciare che tali modifiche abbiano effetto sul sistema che ospita la build. Non è necessario fakerootprodurre un tarball contenente un file di proprietà di root e suid; se hai un binario evilbinary, in esecuzione tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary, come utente normale, creerà un tarball contenente evilbinary, di proprietà di root e suid. Tuttavia, non sarai in grado di estrarre quel tarball e conservare quelle autorizzazioni a meno che tu non lo faccia come root: qui non c'è escalation di privilegi. fakerootè un privilegio de-scalation tool: ti permette di eseguire una build come utente normale, preservando gli effetti che la build avrebbe avuto se fosse stata eseguita come root, consentendo di riprodurre tali effetti in un secondo momento. L'applicazione degli effetti "per davvero" richiede sempre i privilegi di root; fakerootnon fornisce alcun metodo per acquisirli.

Per comprendere l'uso fakerootin modo più dettagliato, considera che una tipica build di distribuzione comporta le seguenti operazioni (tra le altre):

• installa file, di proprietà di root
• ...
• archiviare quei file, ancora di proprietà di root, in modo che quando vengono estratti, saranno di proprietà di root

La prima parte ovviamente fallisce se non sei root. Tuttavia, quando si esegue sotto fakeroot, come un normale utente, il processo diventa

• installa i file, di proprietà di root: questo non riesce, ma fakerootfinge di avere successo e ricorda la proprietà cambiata
• ...
• archiviare quei file, ancora di proprietà di root - quando tar(o qualunque altro archivio sia in uso) chiede al sistema quale sia la proprietà del file, fakerootcambia la risposta in modo che corrisponda alla proprietà registrata in precedenza

In questo modo puoi eseguire un build di pacchetti senza essere root, ottenendo allo stesso tempo gli stessi risultati che otterrai se stavi davvero eseguendo come root. L'uso fakerootè più sicuro: il sistema non può ancora fare nulla che l'utente non possa fare, quindi un processo di installazione non autorizzato non può danneggiare il sistema (oltre a toccare i file).

In Debian, gli strumenti di compilazione sono stati migliorati in modo da non richiederlo più, e puoi creare pacchetti senzafakeroot . Questo è supportato dpkgdirettamente dalla Rules-Requires-Rootdirettiva (vedi rootless-builds.txt).

Comprendere lo scopo fakeroote gli aspetti di sicurezza della corsa come root o no, potrebbe aiutare a considerare lo scopo del packaging. Quando si installa un software dal sorgente, per l'utilizzo a livello di sistema, si procede come segue:

1. costruire il software (che può essere fatto senza privilegi)
2. installare il software (che deve essere fatto come root, o almeno come un utente ha permesso di scrivere nelle posizioni di sistema appropriate)

Quando impacchetti un software, stai ritardando la seconda parte; ma per farlo con successo, è ancora necessario "installare" il software, nel pacchetto piuttosto che nel sistema. Quindi, quando impacchettate il software, il processo diventa:

1. costruire il software (senza privilegi speciali)
2. fingere di installare il software (di nuovo senza privilegi speciali)
3. acquisire l'installazione del software come pacchetto (idem)
4. rendere disponibile il pacchetto (idem)

Ora un utente completa il processo installando il pacchetto, che deve essere eseguito come root (o ancora, un utente con i privilegi appropriati per scrivere nelle posizioni appropriate). È qui che viene realizzato il processo privilegiato ritardato ed è l'unica parte del processo che richiede privilegi speciali.

fakeroot aiuta con i passaggi 2 e 3 sopra consentendoci di eseguire i processi di installazione del software e di acquisirne il comportamento, senza eseguire come root.

NO. La radice falsa ti consente di eseguire strumenti di manipolazione delle autorizzazioni e di reporting, che segnalerà in modo coerente. Tuttavia non concederà effettivamente queste autorizzazioni. Sembrerà che tu li abbia (falso). Non cambierà nulla al di fuori dell'ambiente.

È utile, se si desidera creare una struttura di directory, che contenga proprietà e autorizzazioni, che non possono essere impostate dall'utente, quindi sarà tar, zip o altro pacchetto.

Essa non ha davvero elevare le autorizzazioni, è falso. Non ti consente di fare nulla (eliminare, scrivere, leggere) che altrimenti non potresti fare. Potresti produrre il pacchetto (in teoria) senza di esso. Potresti ottenere un rapporto falso ( ls) senza di esso.

Non è un difetto di sicurezza, perché non consente l'accesso o qualsiasi cosa di cui non puoi farne a meno. Funziona senza privilegi. Tutto ciò che la dose è intercettare le chiamate a chown, chmodecc. Li rende una non-operazione, tranne per il fatto che registra cosa sarebbe successo. Intercetta anche le chiamate a statecc. In modo da segnalare permessi e proprietà, dal proprio database interno, come se fossero stati eseguiti gli altri comandi. Questo è utile, perché se poi comprimi la directory, avrà i permessi falsi. Se decomprimi, come root, le autorizzazioni diventeranno reali.

Tutti i file che non sono mai stati leggibili / scrivibili prima, rimarranno non leggibili / scrivibili. Qualsiasi file speciale (ad es. Dispositivi) creato, non avrà poteri speciali. Qualsiasi set-uid (per un altro utente), i file non verranno impostati. Qualsiasi altra escalation di privilegi non funzionerà.

È un tipo di macchina virtuale: una macchina virtuale, in generale, può simulare qualsiasi ambiente / sistema operativo, ma non può fare nulla all'host, cosa che qualsiasi altra applicazione non potrebbe fare. All'interno della macchina virtuale, puoi sembrare di fare qualsiasi cosa. È possibile reinventare il sistema di sicurezza in modo che sia uguale o diverso, tuttavia tutto ciò esisterà sull'host, come risorse di proprietà dell'utente / gruppo del processo che esegue l'ambiente virtuale.

Ci sono già due risposte valide e molto dettagliate qui, ma farò solo notare che il paragrafo introduttivo della pagina man originale ^{1 in} realtà lo spiega in modo abbastanza chiaro e conciso:fakeroot

fakeroot esegue un comando in un ambiente in cui sembra avere i privilegi di root per la manipolazione dei file. Ciò è utile per consentire agli utenti di creare archivi (tar, ar, .deb ecc.) Con file al loro interno con permessi / proprietà di root. Senza fakeroot si dovrebbero avere i privilegi di root per creare i file costituenti degli archivi con le autorizzazioni e la proprietà corrette, e quindi impacchettarli, oppure si dovrebbero costruire gli archivi direttamente, senza usare l'archiviatore.

Fakeroot consente a un utente non root di creare archivi contenenti file di proprietà root, che è una parte fondamentale della generazione e distribuzione di pacchetti software binari in Linux. Senza fakeroot, gli archivi dei pacchetti dovrebbero essere generati durante l'esecuzione come root effettivi, in modo che contengano la proprietà e le autorizzazioni corrette del file. Questo sarebbe un rischio per la sicurezza. La creazione e il confezionamento di software potenzialmente non attendibile è una grande esposizione se eseguita con i privilegi di root. Grazie a fakeroot, un utente senza privilegi con file senza privilegi può comunque generare archivi contenenti file con proprietà di root. ²

Ma non è un rischio per la sicurezza, perché nulla nell'archivio è effettivamente di proprietà di root fino a quando i file non vengono ESTRATTI . E anche in questo caso, i file verranno estratti solo con le autorizzazioni di root intatte se vengono eseguiti da un utente privilegiato. Quel passaggio - in cui un fakerootutente privilegiato che estrae un archivio assistito contenente file "root" è dove la radice "fake" diventa finalmente reale. Fino a quel momento, nessun privilegio di root reale è mai stato ottenuto o ignorato.

Appunti

1. Fakeroot ha generato alcuni concorrenti / imitatori che si maschereranno come fakerootinstallati, tra cui fakeroot-nge pseudo. Ma la pagina man di "Imitator" di IMHO non è altrettanto chiara su come arrivare a questo punto. Attenersi all'originale, unico e solo fakerootOG

2. Altre distribuzioni / sistemi di imballaggio lo superano semplicemente non usando la proprietà di root negli archivi dei pacchetti. Su Fedora, ad esempio, il software può essere compilato, installato e impacchettato da un utente non privilegiato senza necessità fakeroot. È tutto fatto nello $HOME/rpmbuild/spazio dell'utente e passaggi normalmente privilegiati come make installvengono reindirizzati (tramite meccanismi come --prefixe DESTDIR) a una $HOME/rpmbuild/BUILDROOT/gerarchia che potrebbe essere considerata una sorta di spazio "fakechroot" (senza effettivamente utilizzarlo fakechroot).

   Ma anche durante make install, tutto viene eseguito come e di proprietà dell'utente non privilegiato. La proprietà e le autorizzazioni del file estratto verranno impostate su root,roote 0644(o 0755per gli eseguibili) per impostazione predefinita, a meno che non vengano sovrascritte nel .specfile di definizione del pacchetto ( ) nel qual caso vengono archiviate come metadati all'interno del pacchetto finale. Poiché nessuna autorizzazione o proprietà viene effettivamente applicata fino al processo di installazione (privilegiato) del pacchetto rpm, né root né fakerootè necessario durante il packaging. Ma fakerootè davvero solo un percorso diverso per quello stesso risultato.