chroot Prático

Olá, eu sou um inútil.
Por várias razões, é apenas uma questão de saber se podemos fazer algo com o antigo chroot na história da virtualização clássica. Desta vez, vou instalar o Arch em um USB de 64GB.

Preparando o Drive

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 238.5G  0 disk 
└─sda1   8:1    0 238.5G  0 part /var/lib/docker
                                 /
sdb      8:16   1  57.8G  0 disk 
└─sdb1   8:17   1  57.8G  0 part 
$ sudo fdisk /dev/sdb
$ sudo mkfs.ext4 /dev/sdb1
$ sudo mkdir /mnt/arch
$ sudo mount /dev/sdb1 /mnt/arch

Preparando o Kernel e Outros

$ pacstrap /mnt/arch base linux linux-firmware man-db vim
bash: pacstrap: comando não encontrado

Ops

$ sudo pacman -S arch-install-scripts
$ sudo pacstrap /mnt/arch base linux linux-firmware man-db vim

Fazendo arch-chroot

$ sudo arch-chroot arch
[alleycat /]# ls
bin  boot  dev  etc  home  lib  lib64  lost+found  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[alleycat /]# date
Fri Nov 29 14:36:48 UTC 2024
[alleycat /]# ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
[alleycat /]# date
Fri Nov 29 23:37:02 JST 2024
[alleycat /]# hwclock --systohc
[alleycat /]# date
Fri Nov 29 23:37:08 JST 2024

Parece que também existe no Devuan.

O script de instalação equivalente a arch-install-scripts/stable é

$ sudo apt search debian-installer 
Ordenando... Concluído
Busca de texto completo... Concluído  
bf-utf-source/stable 0.08+nmu2 all
  source for fonts needed to build Debian installers

cio-win32/stable 2.13+dfsg-7.1 all
  GNU cpio -- a program to manage archives of files (win32 build)

debian-installer/stable 20230607+deb12u8devuan1 amd64
  Devuan's debian installer

Parece que é realmente Devuan's debian installer.
Com um mecanismo semelhante, parece possível criar um ambiente mínimo com debootstrap.
Criando um sistema de arquivos raiz mínimo com mmdebstrap

Fazer um 'chroot jail' como desta vez é em parte por diversão, mas se você configurar todo esse ambiente chroot e conceder permissões SSH como um ambiente de execução completo, é possível dividir facilmente os recursos, e talvez amigos da universidade possam usar um ambiente de execução GNU/Linux rico e gratuito. No entanto, o ambiente SSH não pode sair do chroot, então não é possível alcançar o diretório raiz da própria máquina host. O que me preocupava era que construir com kvm também é bom, mas parece que tende a ser bastante complexo, e eu me perguntava se era realmente necessário ir tão longe se não fosse para escalar.
Além disso, se eu tivesse o desejo específico de criar um serviço em um disco separado que eu não gostaria de iniciar no disco do sistema operacional host, este ambiente chroot seria bastante útil.

Basicamente, o 'chroot jail' é recomendado até mesmo por entusiastas de segurança como o OpenBSD, então, se for usado corretamente nesse ambiente, é um amigo poderoso, mas sinto que dominá-lo é bastante difícil.
Sempre tive isso em mente, mas continuei minha vida diária por um tempo, procurando por um uso, e acabei com uma frase que soa como 'Tentai Kansoku' (Observação Astronômica) do BUMP OF CHICKEN, dizendo que 'parece que vou encontrar algo'.

A propósito, depois de instalar desta vez, o espaço restante no disco é assim.

$ df -h
~~~
/dev/sdb1         57G  2.0G   52G    4% /mnt/arch

Por que chroot é seguro

Por exemplo, se um PID e um shell como este existissem na máquina host

$ sleep 10000 & echo $$
[1] 21235
3936

Se você tentar eliminar isso do ambiente chroot (desculpe por não usar grep -v)

[alleycat /]# ps -ef | grep sleep
1000     21235  3936  0 00:30 ?        00:00:00 sleep 10000
root     21244 17618  0 00:31 ?        00:00:00 grep --colour=auto sleep
[alleycat /]# kill -9 21235
bash: kill: (21235) - No such process
[alleycat /]# kill -9 3936 
bash: kill: (3936) - No such process

O PID é visível, mas não pode ser killado. Por outro lado, o inverso é possível.

Portanto, mesmo que um processo em execução dentro do chroot seja atacado de alguma forma, ele não pode alcançar a máquina host, então é seguro, certo? Essa é a minha compreensão simples.

Também é possível combinar com o Protocolo Plan9?

Por exemplo, se houvesse um disco que você quisesse acessar também do ambiente chroot, parece que seria possível compartilhá-lo.
E é assim que o WSL do Windows foi criado, certo?
WSL uses the 9P protocol to share files between Windows and WSL

WSL é agora
Windows Subsystem for Plan9/GNU/Linux
WSPGL, talvez?