Easy chroot - SOULMINIGRIG

Hello, this is Incompetent.
Long story short, I'm just exploring what can be done with the old chroot from the history of classical virtualization. This time, I will install Arch onto a 64G USB.

Preparing the 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

Preparing the Kernel and Other Components

$ pacstrap /mnt/arch base linux linux-firmware man-db vim
bash: pacstrap: command not found

Oops

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

Performing 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

It seems to exist in Devuan as well.

What about installation scripts equivalent to arch-install-scripts/stable?

$ sudo apt search debian-installer 
Sorting... Done
Full Text Search... Done  
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

It seems to be properly Devuan's debian installer.
It seems possible to create a minimal environment with debootstrap using a similar mechanism.
Creating a minimal root filesystem with mmdebstrap

The reason I'm deliberately setting up a chroot jail like this is partly for fun. But if you set up this entire chroot environment and grant SSH access as a complete execution environment, it becomes easy to divide resources, and friends attending university could use a rich GNU/Linux execution environment for free, I wonder. However, the SSH'd environment cannot escape from within the chroot, so it cannot reach the root directory of the host machine itself. What I was wondering about was, while building with kvm is also good, it tends to become quite complex, and I questioned if it was necessary to go that far when not scaling out.
Additionally, if I have a niche desire, for example, to create services on a separate disk that I don't want to run on the host OS's disk, this chroot environment seems quite useful.

Basically, the chroot jail is even recommended by security enthusiasts like OpenBSD, so if used properly in that environment, it's a strong ally, but I feel it's quite difficult to master.
It's been on my mind for a long time, and I've been living my daily life while searching for a good use case, and a phrase like 'I might find it' (reminiscent of BUMP OF CHICKEN's 'Tentai Kansoku' - 'Astronomical Observation') comes to mind.

By the way, after this installation, the remaining disk space looks like this.

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

Why chroot is Secure

For example, if a PID and shell like this exist on the host machine:

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

If you try to kill it from the chroot environment (sorry for not using 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

You can see the PID, but you can't kill it. By the way, the reverse is possible.

Therefore, even if a process running within chroot is attacked in some way, it cannot reach the host machine, so it's safe, right? That's my simple understanding.

Can it also be combined with Plan9 Protocol?

For example, if there was a disk that you wanted to access from the chroot environment, I feel like it could be shared.
That's how Windows WSL was created, isn't it?
WSL uses the 9P protocol to share files between Windows and WSL

WSL is already
Windows Subsystem for Plan9/GNU/Linux
WSPGL, perhaps?