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.

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.
Hundreds of successful (and some unsuccessful) builds show that the overall design of MKG, which delegates most of the building operations to VirtualBox machines, will keep your personal data away from potential risks, as most of the processes involved are encapsulated within 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. A good option is to leverage to power of Github Actions workflows and stay away from elevated rights. You can run MKG without elevated rights provided that you use the helper workflow releases (which are automatically downloaded by default) and avoid using options that involve mount or chroot operations (like hot_install, burn or test_emerge).
You may wish to consider the following techniques:

• Using Github Actions workflows

  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 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.

• Rebuilding Docker images

  You can crank up security levels (perhaps beyond what is necessary for most users) by rebuilding the above releases in a local fork of the above two repositories. You can also rebuild the current MKG Docker image using the Dockerfile in the mkg_docker_image repository.

You will not be able to create an installer ISO within the container, which is only possible if elevated access rights are granted to the docker engine (using option --privileged, see section 8.).
However with standard user rights, you should be able to create a valid Gentoo OS on a VDI virtual disk and fetch it back to the host to use it in a virtual machine or complete the processing.

• 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 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. You can further restrict potential exploits by adding: --security-opt=no-new-privileges, which will bar containers from acquiring privileges that are not already set on launch:

  # docker run -dit --security-opt=no-new-privileges --cap-drop=ALL \
-v /dev/log:/dev/log --device /dev/vboxdrv:/dev/vboxdrv \
mygentoo:release-master

• Using x11docker

  Project x11docker enforces a handful of security features on top of docker and makes it possible to use graphic display within containers. Currently MKG does not make use of graphic display, yet installing x11docker may be worth considering if you wish to step up hardening. In addition to the above standard docker security options, x11docker adds a namespace remapping option, --user=RETAIN which conveniently remaps root processes within the container to host user (not root user) rights.

  Unlike S. Jordahl's original approach, which has inspired MKG dockerization, the current settings for MKG:

  • do not request sharing the host's network stack, i.e. do not rely on --network=host(sharing stacks may cause hazards);

  • allow x11docker kernel capability dropping on startup, i.e. do not rely on --cap-default, thereby using the full range of x11docker hardening features;

  • allow namespace remapping to host user, which lessens hazards associated with root processes within containers;

  • do not request (re)building VirtualBox modules in the host, as both the host and container image have the same VB module configuration from the ground up (provided that the Gentoo host has been recently updated).

  Using x11docker you may this way:

  • log into your container (then run ./mkg and exit):

    # x11docker --interactive --no-entrypoint --network=bridge --tty \
--user=RETAIN -- --device /dev/vboxdrv:/dev/vboxdrv \
-v /dev/log:/dev/log -- mygentoo:release-master /bin/bash

  • or run the container in detached mode:

    # x11docker --quiet --network=bridge --tty --user=RETAIN \
-- --device /dev/vboxdrv:/dev/vboxdrv -v /dev/log:/dev/log \
-- mygentoo:release-master >/dev/null 2>&1 &

  To access the container created by the above command line, use:

      `# docker exec -it $(docker ps -q | head -1) bash`   
  

then within the container, change directory to /mkg.

Current limitations

Virtual Machines embedded within containers will currently refuse to start if docker is run in experimental rootless mode or even if namespace remapping is used to remap root processes within the container to a non-root ad-hoc test user.
With this in mind, combining containerization, nested virtualization, kernel capability-dropping and (optionally) x11docker hardening features should prevent most likely hazards and keep data integrity and platform security in line with reasonable expectations.