I can't comment, so: @shards have you tried creating a bootable USB to use? You can make it so that root has no password to login so the existing filesystems can't be mounted without root privileges. An added bonus is that the USB will be loaded into RAM so there won't be leftover files.
For distributions based on Gnu/Linux:
Chroots are not meant to be a security feature and shouldn't be used as such. To answer your question:
To create a more secure chroot environment, create a directory with bash or your prefered shell, its linked libraries, and the other tools you require. Directly from the just referenced wiki page:
# mkdir /chroot
# ldd /bin/bash
libncurses.so.5 => /lib/libncurses.so.5 (0x4001b000)
libdl.so.2 => /lib/libdl.so.2 (0x40060000)
libc.so.6 => /lib/libc.so.6 (0x40063000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Create the directories needed for the shared libraries linked to bash + any other executables you will be using:
# mkdir /chroot/bash
# mkdir /chroot/bash/bin
# mkdir /chroot/bash/lib
And copy those libraries to the correct directories.
Unfortunately I misread the question twice and have yet another unrelated answer to containers instead of chroots below.
The latest kernel documentation describes how to defend against Spectre, one of the major issues with a guest system/unprivileged container escaping from a virtual machine. You can the current status of your processor in regards to such vulnerabilities with:
tail -n1 /sys/devices/system/cpu/vulnerabilities/* | sed 's/\/.*\///g'
And comparing the results with the expected results described in the documentation.
Make sure CONFIG_RETPOLINE is enabled in the kernel, which it should be by default. Other protective options are CONFIG_STACKPROTECTOR_STRONG and CONFIG_STRICT_DEVMEM. There are other options as well that you may enable that distributions will leave off due to performance tradeoffs.
An essential step is to have the latest microcode firmware either built into your kernel, loaded by your BIOS, or loaded by your initramfs that will update your processor microcode upon every boot. Your distribution will likely the latest for you, assuming you keep your system updated. For reference, AMD motAMD's latest microcode is located at the official kernel git tree, and Intel's latest microcode is hosted on Github. The config to allow loading microcode into the initramfs/cpio is under CONFIG_MICROCODE, while you may choose to build it in with the kernel by directing CONFIG_EXTRA_FIRMWARE to the correct directory.
You may also opt to recompile GCC with Intel's patch that will allow you to use the -mzero-caller-saved-regs argument when compiling your kernel.
You would need to have a version of Windows that supports Process Isolation for your containers.
In order of relevance:
https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/faq
https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers
https://docs.microsoft.com/en-us/windows/win32/http/process-isolation
https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/containers-vs-vm
It is also needed to keep Windows updated with security patches relevant to Spectre/Meltdown, which may allow escapes from a virtual machine or container.
https://support.microsoft.com/en-us/help/4073757/protect-windows-devices-from-speculative-execution-side-channel-attack
Main reason why I prefer a live system is that my computer cannot handle a virtual machine well (there's an issue with my RAM chip). I don't have access to other computers at the moment either. – shards – 2019-11-10T14:16:00.237