Perché Linux consente 'init = / bin / bash'?

Di recente ho scoperto che se modifico GRUB prima dell'avvio e aggiungo, rw init=/bin/bashfinisco con una shell di root.

Essendo in una condizione in cui voglio capire tutto, vorrei sapere perché questo accade. Voglio dire, è un bug? è una caratteristica? è lì per aiutare gli amministratori a risolvere le cose in quanto funziona solo se si ha accesso fisico a un computer?

È fornito da GRUB o dal kernel attuale?

Questa è una funzione e viene utilizzata per la manutenzione del sistema: consente a un amministratore di sistema di ripristinare un sistema da file di inizializzazione incasinati o modificare una password dimenticata.

Questo post nella mailing list di Red Hat spiega alcune cose:

In sistemi simili a Unix, init è il primo processo ad essere eseguito e l'ultimo antenato di tutti i processi mai eseguiti. È responsabile per l'esecuzione di tutti gli script init.

Stai dicendo al kernel Linux di eseguire / bin / bash come init, anziché come init di sistema. [...]

Quindi, non stai sfruttando nulla, stai solo usando una funzionalità standard del kernel.

Inoltre, come notato in un commento, il rwflag è separato da init=, dice semplicemente al sistema di montare il file system di root come lettura-scrittura (in modo da poter ad esempio modificare il file non configurato correttamente o cambiare una password).

Il tuo sistema ha meccanismi per l'esecuzione e il debug (come il parametro init) e probabilmente ha meccanismi di sicurezza per impedire agli utenti indesiderati di trarne vantaggio. Queste sono funzionalità, non bug.

Il bootloader è responsabile dell'avvio del sistema operativo. La sicurezza del sistema operativo ovviamente non si applica a quel punto. Potresti semplicemente caricare un kernel diverso, initrd, root fs o impostare diverse opzioni (come il percorso init). Se si desidera impedire agli utenti di farlo, è necessario farlo sul bootloader.

Il tuo sistema (probabilmente un PC, quindi BIOS) carica il bootloader e quindi, ovviamente, la sicurezza del bootloader non si applica ad esso. Se si desidera impedire agli utenti di eseguire l'avvio del BIOS da USB o simili, è necessario farlo a quel livello.

Il tuo sistema potrebbe essere su una scrivania da qualche parte. Se si desidera impedire agli utenti di aprire il coputer e cambiare l'hdd per uno di loro o rimuovere l'unità per montarlo sui propri computer, è necessario farlo a livello fisico. E ciò non impedirà loro di prendere l'intera scrivania e scappare nel loro furgone di fuga ...

Questa è la sicurezza. Elefanti fino in fondo.

All'avvio, il computer esegue un programma chiamato "init", generalmente disponibile su /bin/inito /sbin/init. Questo programma è responsabile di tutto l'avvio del sistema e della creazione di un ambiente utilizzabile.

La specifica init=/bin/bashindica /bin/bashinvece l' esecuzione del kernel (che è una shell). La specifica rwdice al kernel di avviarsi con il disco rigido in modalità lettura-scrittura anziché in modalità sola lettura. Tradizionalmente il kernel inizia con il disco in modalità di sola lettura e un processo successivo verifica l'integrità del disco prima di passare alla lettura / scrittura.

Messi insieme da kernel.org :

KNL     Is a kernel start-up parameter.

init=   [KNL]
        Format: <full_path>
        Run specified binary instead of /sbin/init as init
        process.

rw      [KNL] Mount root device read-write on boot

Questa è una funzionalità del kernel: consente al suo "chiamante", ovvero al boot loader, una grande flessibilità. Grub ti offre i mezzi per sfruttare questa flessibilità durante l'avvio, ma ti fornisce anche i mezzi per limitare questo tipo di manomissione . Ciò ha senso in particolare nei casi in cui gli utenti non autorizzati possono ottenere il processo di avvio, ma altrimenti viene loro negato l'accesso al disco rigido stesso.

init=può prendere qualsiasi eseguibile

init=può accettare qualsiasi eseguibile, inclusi gli script di shell .

Qui, ad esempio, ho dimostrato come creare una C minimale arbitraria compilata init: Come creare una distro Linux personalizzata che esegue solo un programma e nient'altro?

Allora, perché sarebbe non accettare /bin/bash, di tutte le cose, che è solo un eseguibile normale, e può effettivamente essere utile? :-)

Successivamente, dovresti anche provare a capire quali saranno i compromessi con i tuoi normali initcome systemd o Busybox "

Fondamentalmente, con un raw /bin/bash, tu:

• perdere la possibilità di controllare l'accesso con le password. Ma questo a volte è desiderabile, ad esempio quando si esegue l'emulazione di sistema: come accedere automaticamente senza digitare il nome utente o la password di root in Buildroot BusyBox init?
• perdere il controllo del lavoro, ad es. Ctrl + C non funzionerà
• se fai Ctrl + C, la shell esce e il panico del kernel da allora initesiste

Il controllo del lavoro può essere ripristinato sull'iniz di Busybox e altri init simili con un vantaggio -in inittab:

tty3::respawn:-/bin/sh

Le inittabvoci più normali , che usano il login e continuano a generare shell se si fa Ctrl + D sono:

::respawn:/sbin/getty -L ttyS0 0 vt100

che usano l' gettyeseguibile, ma TODO: non sono stato in grado di generare quelli da solo senza Busybox init: getty iniziare dalla riga di comando?

È possibile utilizzare questa configurazione per giocare con esso e raggiungere le conclusioni sopra.