Por que o Linux permite 'init=/bin/bash'?

Question

Recentemente descobri que se eu editar o GRUB antes de inicializar e adicionar, rw init=/bin/bashacabo com um shell root.

Estando numa condição que quero entender tudo, gostaria de saber por que isso acontece. Quero dizer, é um bug? é um recurso? existe para ajudar os administradores a consertar as coisas, pois só funciona se você tiver acesso físico a um computador?

É fornecido pelo GRUB ou pelo kernel real?

Answer 1

Este é um recurso usado para manutenção do sistema: permite que um administrador de sistema recupere um sistema de arquivos de inicialização confusos ou altere uma senha esquecida.

Esta postagem na lista de discussão da Red Hatexplica algumas coisas:

Em sistemas do tipo Unix, init é o primeiro processo a ser executado e o ancestral final de todos os processos já executados. É responsável por executar todos os scripts de inicialização.

Você está dizendo ao kernel do Linux para executar/bin/bash como init, em vez do init do sistema. [...]

Assim, você não está explorando nada, está apenas usando um recurso padrão do kernel.

Além disso, como observado em um comentário, o rwsinalizador é separado de init=, apenas informa ao sistema para montar o sistema de arquivos raiz como leitura e gravação (para que você possa, por exemplo, editar o arquivo configurado incorretamente ou alterar uma senha).

Answer 2

Seu sistema possui mecanismos para execução e depuração (como o parâmetro init) e provavelmente possui mecanismos de segurança para impedir que usuários indesejados tirem vantagem deles. Esses são recursos, não bugs.

O bootloader é responsável por iniciar o sistema operacional. A segurança do sistema operacional obviamente não se aplica nesse ponto. Você pode simplesmente carregar um kernel diferente, initrd, root fs ou definir opções diferentes (como caminho de inicialização). Se você quiser impedir que os usuários façam isso, isso deve ser feito no bootloader.

Seu sistema (provavelmente um PC, portanto BIOS) carrega o bootloader e, portanto, obviamente, a segurança do bootloader não se aplica a ele. Se você quiser impedir que os usuários inicializem o BIOS a partir de USB ou algo semelhante, você precisa fazer isso nesse nível.

Seu sistema pode estar em uma mesa em algum lugar. Se você quiser impedir que os usuários abram o computador e troquem o disco rígido por um deles ou removam a unidade para montá-lo em suas máquinas, você precisa fazer isso em um nível físico. E isso não os impedirá de pegar toda a mesa e ir embora em sua van de fuga...

É assim que a segurança é. Elefantes até lá embaixo.

Answer 3

É simplesmente assim que o kernel foi projetado. Tem que haveralgopara ser executado quando o computador for inicializado e, embora haja um padrão, a linha de comando do kernel permite alterar esse padrão.

Normalmente ele executa um programa chamado "init", normalmente encontrado em /bin/initou /sbin/init. Este programa é responsável por toda a inicialização do sistema e criação de um ambiente utilizável.

A especificação init=/bin/bashdiz ao kernel para ser executado /bin/bash(que é um shell). A especificação rwdiz ao kernel para inicializar com o disco rígido no modo leitura-gravação em vez do modo somente leitura. Tradicionalmente, o kernel inicia com o disco no modo somente leitura e um processo posteriormente verifica a integridade do disco antes de mudar para leitura-gravação.

Answer 4

init=pode levarqualquerexecutável

init=pode levar qualquer executável, incluindoscripts de shell. A razão subjacente é provavelmente que oexecsyscall pode lidar diretamente com executáveis ​​ELF e shebangs.

Aqui, por exemplo, demonstro como criar um C mínimo arbitrário compilado init:Como criar uma distribuição Linux customizada que execute apenas um programa e nada mais?

Então por quenãoaccept /bin/bash, entre todas as coisas, que é apenas um executável normal e pode realmente ser útil? :-)

Em seguida, você também deve tentar entender quais serão as vantagens e desvantagens do seu sistema regular, initcomo systemd ou Busybox.

Basicamente, com um raw /bin/bash, você:

• perder a capacidade de controlar o login com senhas. Mas isso às vezes é desejável, por exemplo, ao fazer emulação de sistema:Como fazer login automaticamente sem digitar o nome de usuário root ou senha no buildroot BusyBox init?
• perder o controle do trabalho, por exemplo, Ctrl + C não funcionará
• se você fizer Ctrl + C, o shell será encerrado e o kernel entrará em pânico desde que initexistiu

O controle do trabalho pode ser restaurado no init do Busybox e em outros inits semelhantes com início -em inittab:

tty3::respawn:-/bin/sh

As entradas mais normais inittab, que usam login e continuam gerando shells se você fizer Ctrl+D são:

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

que usam o gettyexecutável, mas TODO: não consegui gerá-los sozinho sem o Busybox init:getty iniciar na linha de comando?

Você pode usaresta configuraçãobrincar com isso e chegar às conclusões acima.