I want an easy way to run one or more ephermal Linux VMs in Ubuntu desktop, including the possibility to mount host directories into them in an efficient fashion. Those VMs should have the same CPU architecture and hardware features as the host, no need to emulate some foreign CPU or special hardware, and no GUI in the VMs. The intended use case is sandboxing and isolation for security and reproducability reason. To be used as a cheaper alternative to a remote cloud instance. Or as a more secure alternative to Docker/Podman containers, with possibility to install Docker or Podman in the VM, and run containers there without affecting the host or other VMs (it’s not feasible to nest containers in a secure manner without a proper VM).

You can do quite a lot with Docker, but sometimes you want greater capabilities or increased security, then a proper virtual machine with KVM is a good alternative. An example is when you want to run Docker containers in the VM, it’s not easy to nest Docker without forgoing all security.

Just like Alpine Linux is suitable as a base for Docker images, it is also a good option as a guest in a virtual machine.

I have been using the distroless Docker base images to package my applications, mainly since I want slim and simple image without unnecessary cruft.

However, they are based on Debian, and Debian is unfortunately not so diligent to fix serious security issues as other distributions like Ubuntu or Alpine. If you scan a distroless image with the grype tool, you get this result:

$ grype gcr.io/distroless/java17-debian11

NAME             INSTALLED              FIXED-IN     TYPE  VULNERABILITY     SEVERITY
libharfbuzz0b    2.7.4-1                (won't fix)  deb   CVE-2023-25193    High
libjpeg62-turbo  1:2.0.6-4              (won't fix)  deb   CVE-2021-46822    Medium
libssl1.1        1.1.1n-0+deb11u4       (won't fix)  deb   CVE-2023-0464     High
openssl          1.1.1n-0+deb11u4       (won't fix)  deb   CVE-2023-0464     High

Furthermore, if small image size is important, distroless is quite overrated. They brags about being so small:

These instructions are tested with Ubuntu desktop 12.04, but will probably be useful in other Linux distros with GRUB2 as well.

The goal is to block everything except booting the default system. In paricular, it should not be possible for anyone to boot into recovery mode, since that will bypass normal login and give root access directly.

1. Run grub-mkpasswd-pbkdf2 from a terminal and enter the desired password, copy the output.
2. Edit /etc/grub.d/40_custom and add this to the end:

set superusers="root"
password_pbkdf2 root output from grub-mkpasswd-pbkdf2 goes here
password bogus bogus

3. Make /etc/grub.d/40_custom non-readable for users:
   chmod o-r /etc/grub.d/40_custom
4. Edit /etc/grub.d/10_linux according to this diff:

90c90,94
<   printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${version}"
---
>   if ${recovery} || ${in_submenu}; then
>     printf "menuentry '${title}' ${CLASS} --users '' {\n" "${os}" "${version}"
>   else
>     printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${version}"
>   fi
258c262
<     echo "submenu \"Previous Linux versions\" {"
---
>     echo "submenu \"Previous Linux versions\" --users '' {"

5. Edit /etc/grub.d/20_memtest86+ according to this diff:

27c27
< menuentry "Memory test (memtest86+)" {
---
> menuentry "Memory test (memtest86+)" --users "" {
33c33
< menuentry "Memory test (memtest86+, serial console 115200)" {
---
> menuentry "Memory test (memtest86+, serial console 115200)" --users "" {
46c46
< #menuentry "Memory test (memtest86+, experimental multiboot)" {
---
> #menuentry "Memory test (memtest86+, experimental multiboot)" --users "" {
52c52
< #menuentry "Memory test (memtest86+, serial console 115200, experimental multiboot)" {
---
> #menuentry "Memory test (memtest86+, serial console 115200, experimental multiboot)" --users "" {

6. Run update-grub

(I am not sure if it is possible to abuse memtest86+, but better safe than sorry.)

(This article has been edited since it’s first publication.)

In Linux, and other UNIX-like systems, you have to be root (have superuser privileges) in order to listen to TCP or UDP ports below 1024 (the well-known ports).

This port 1024 limit is a security measure. But it is based on an obsolete security model and today it only gives a false sense of security and contributes to security holes.

The port 1024 limit forces you to run all network daemons with
superuser privileges, which might open security holes. Without the port 1024 limit, most network daemons (except sshd), could be run without superuser privileges. Some daemons try to remedy this potential security hole by dropping the superuser privileges after binding to the port, but you still need to start the daemon as root. And this does not work if the daemon is written in Java, which is quite popular for web servers.