9. Safety and security

Building an operating system from scratch on a running computer is a process that may involve safety and security hazards.
Several procedures and techniques have been developed to keep these hazards under control, and hopefully very low.

Keeping your running platform safe

Safety is generally thought of in terms of data integrity. Before running MKG on anything other than a container, a virtual machine or a live medium, it is generally a cautious move to backup the running platform.
Dozens of successful (and some unsuccessful) builds show that the overall design of MKG, which delegates most of the building operations in VirtualBox machines, will keep your personal data away from potential risks, as most of the processes involved are encapsulated into virtual disks. This said, mistakes happen and damage to data can possibly be caused by altering the scripts or running them in inappropriate contexts.

Security: Protecting data from unauthorized access

Running software should request only the minimal rights necessary for execution. You can run MKG without elevated rights provided that you use at least the present site workflow and avoid directly installing to block device or, more generally, using options that involve mount or chroot operations.

To step up security, you may wish to consider the following techniques:

• Using Github Actions workflows

  If you are ready to install software dependencies (see the list in the FAQ) and adjust virtual machine parameters yourself, a good option is to leverage to power of Github Actions workflows and stay away from elevated rights.
  The present project workflow delivers a daily package, in the form of an ISO live CD, which comprises the minimal Gentoo install live medium together with the stage3 archive and the MKG build scripts. Releases are entirely automated by Github Actions from the public repository code, for both branches (master and gnome), and the output is signed and verified by Github. Checksums are available as release artifacts. By default MKG, uses Github Actions releases automatically and checks control sums. The building process then unravels as indicated in the FAQ. VirtualBox machines can be run with user rights, so MKG can also be run with user rights in this case.
  To create a CloneZilla installer, you will likewise download an ISO live medium automatically released, signed and verified by the Github Actions workflow of companion site clonezilla_with_virtualbox.
  Although this may be performed automatically by MKG, users are allowed to keep control and replace the ISO live CD in the first VirtualBox machine with this one to create an ISO installer. This in turn can be burned to optical disk or copied to USB stick using dd. This last option is the only one that will require elevated rights to be achieved.

• Dropping Linux kernel capabilities

  Even though it is necessary to run docker as root for MKG to work in containers, it is possible to better isolate container processes from the host by excluding a number of Linux kernel capabilities (see the corresponding man page), which grant a fine-grained access to administrative rights.
  Tests have shown that all Linux kernel capabilities can be dropped, using option --cap-drop=ALL together with docker run:

  # docker run -dit --cap-drop=ALL -v /dev/log:/dev/log --device /dev/vboxdrv:/dev/vboxdrv
mygentoo:release-master

• Rebuilding Docker images

  You can also crank up security levels (perhaps beyond what is necessary for most users) by rebuilding from source code the same Docker image from the above Gentoo base images and the Dockerfile in the mkg_docker_image repository.

Current limitations

Virtual Machines embedded within containers will currently refuse to start if docker is run in experimental rootless mode or even if user namespaces are used to remap root processes within the container to a non-root test user running the host.
Other security-oriented tools like x11docker have unfortunately been tested not to work either.
With this in mind, the combination of containerization, nested virtualization and kernel capability-dropping should be powerful enough to prevent most likely hazards and keep data integrity and platform security in line with reasonable expectations.