chroot práctico

Hola, soy un inútil.
Por una razón u otra, solo me pregunto si no se puede hacer algo con el antiguo chroot en la historia de la virtualización clásica. Esta vez, instalaré Arch en una USB de 64G.

Preparación de la unidad

$ 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

Preparación del kernel y otros

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

Oops

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

Realizando 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 también está en Devuan.

El script de instalación equivalente a arch-install-scripts/stable es

$ sudo apt search debian-installer 
Ordenando... Hecho
Búsqueda de texto completo... Hecho  
bf-utf-source/stable 0.08+nmu2 all
  source for fonts needed to build Debian installers

cipio-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 es correctamente Devuan's debian installer.
Con un mecanismo similar, parece posible crear un entorno mínimo con debootstrap.
Crear un sistema de archivos raíz mínimo con mmdebstrap

La razón por la que me tomo la molestia de usar la 'prisión' chroot como esta vez es en parte por diversión, pero si se configura todo este entorno chroot y se le otorgan permisos SSH como un entorno de ejecución completo, es posible dividir los recursos fácilmente. ¿Quizás así mis amigos universitarios podrían usar un entorno de ejecución GNU/Linux rico de forma gratuita? En cualquier caso, el entorno SSH no puede salir del chroot, por lo que no puede acceder al directorio raíz de la máquina anfitriona. Lo que me preocupaba era que construirlo con kvm también es bueno, pero parece que tiende a complicarse bastante, y me preguntaba si era necesario llegar tan lejos si no se iba a escalar.
Además, si tengo un deseo de nicho, como querer crear un servicio en un disco separado que no quiero iniciar en el disco del sistema operativo anfitrión, este entorno chroot podría ser bastante útil.

Básicamente, la 'prisión' chroot es incluso recomendada por entusiastas de la seguridad como OpenBSD, por lo que si se usa correctamente en ese entorno, es un amigo confiable, pero siento que dominarlo es bastante difícil.
Lo he tenido en mente durante mucho tiempo, y aunque he estado buscando cómo usarlo en mi vida diaria, me sale una frase como la de 'Tentai Kansoku' de BUMP OF CHICKEN, diciendo que parece que finalmente encontraré un uso.

Por cierto, después de la instalación, el espacio restante en el disco es así.

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

¿Por qué chroot es seguro?

Por ejemplo, si existe un PID y un shell como este en la máquina anfitriona:

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

Si intentamos eliminarlo desde el entorno chroot (lo siento por no 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

Los PID son visibles, pero no se pueden kill. Por cierto, lo contrario es posible.

Por lo tanto, incluso si un proceso que se ejecuta dentro de chroot es atacado de alguna manera, no puede llegar a la máquina anfitriona, por lo que es seguro. Esa es mi simple comprensión.

¿También se puede combinar con el Protocolo Plan9?

Por ejemplo, si hubiera un disco al que se quisiera acceder también desde el entorno chroot, creo que también se podría compartir.
Así es como se creó WSL de Windows, ¿verdad?
WSL uses the 9P protocol to share files between Windows and WSL

WSL es ahora...
Windows Subsystem for Plan9/GNU/Linux
¿WSPGL, quizás?