merOS :: Build and Interact with a Set of Virtual Machines

SYNOPSIS

merOS can be used to:

• Bootstrap, a base installation -
  Chroot of A) Debian or B) Alpine Linux.

• Populate, the Chroot with a custom set
  Of configuration Files and Packages.

• Pack the the Resulting Filesystem,
  Under a Qemu image.

• Virtualize the Final Image/ VM-
  Thereof, Target.

• Network/ Netfilter resulting Targets.

---

DESCRIPTION

merOS:

Not unlike Debootstrap (which we also use), allows for fine- grained build control over a structure of a file-system-
Not unlike Virtualbox, allows for ease of access to a number of Virtual Machines-
Not unlike Docker,allows for secure application testing-
Not unlike Qubes OS,allows for secure activity-based compartmentalization of activities.

merOS Families:

Provide a simple, XML and file-based configuration file-set.
From a build recipe-like structure, they allow us to set-up a full set of virtualized machines,
with an abstraction layer around Building, Virtualization, Networking and Connection.

---

ARCHITECTURE

Families are used to describe Sets of Targets ( VMs )

Configuration Files are found, and should be placed, under:
conf/families/[fam-id]/ - containing:

1. The Target rootfs directory : rootfs/[target-id]/includes.chroot/
   Where any custom package configuration file, or persistent data, can be placed.
   ( Inspired by the Debootstrap Debian-Building architecture. )

2. The Target build-time hooks directory : rootfs/[target-id]/hooks/
   Where a shell script can be placed and is run in the Target Chroot, before build.
   ( Inspired by the Debootstrap Debian-Building architecture. )

3. Build XML configuration files : build/[target-id].xml
   Where Target properties are described,
   such as Distro, Image Free Size, etc.

4. Host run-Time hooks : hooks/
   Where Host run-time hooks can be found-
   These are executed upon Family initialization.

5. Libvirt XML configuration files : libvirt/[target-id].xml
   Describing Virtual Machine Emulation options.
   (As used by libvirt-Domains and libvirt-Networks

Two Family Templates, currently in beta development, are:

• mos_sec A Whonix- like set of two Targets (VMs) || Firewall & Guest.
• mos_lab A Whonix/ Kali- like set of three Targets (VMs) || Firewall & Tool Guest.

Both are currently included as sub-modules in our main Repository

A fully transparent, but critical, part of building a Target (VM)- is the Linux Kernel Cloning and Building.
This step could as well be skipped, and replaced with a precompiled kernel-image download, reducing bandwidth/ processing use-
but leaving a significant part of the running machine out of our control.
(Such an option could/ should nevertheless be implemented )

---

SYSTEM PREPARATIONoptimized

All merOS created data are placed under: ./data/[fam_id]

• Clone the project, along with it's submodules:
  git clone --recursive
  

• Run ./dist-conf.sh - or:
  Manually resolve any system/ distro-specific dependencies-
  See below.
  

• Install the project, for all users:
  sudo pip3 install -e --system
  

You can now call meros !

---

SYSTEM DEPENDENCIES

Are aquired through ./dist-conf.sh

• Python3
  After initially implementing this idea in bash,
  Python3 is chosen for its' wide availability on machines,
  ease of understanding- auditing and contributing.

• Debootstrap
  Is used for the Debian Target Rootfs building.
  Being activelly-maintained by the Debian team,
  and greatly adopted- ( Just think of Debian-based OSes )
  Along with bringing the security and stability of Debian-
  It was chosen for the basic flavor for merOS-based Targets.

• Libvirt
  Is used as the main virtualization platform.
  Being actively-maintained, widely implemented and documented thoroughly -
  It was chosen as most appropriate Virtualization framework for this project.

• Xpra
  Is used as the main SSH- x11 communication framework,
  used with --run and --connect|-c.
  Being actively maintained, and well documented- it allows for a reliable and faster,
  more secure way of XForward-like functions.

---

BUILDING & MANAGING A TARGET ( VM )

[fam-id] - [target-id] = target-full-id ( ex. mos_sec-guest )

• --build [fam-id]
  This creates and populates the rootfs chroot dir,
  and builds the qemu compatible .qcow image-
  Which can be found under: data/images/

• --init|-i [fam-id]
  Initialize Targets and Networks via Libvirt.

• --shutdown [target-full-id]
  Shut down selected Target.

• --shutdown-all
  Shut down ALL libvirt guests.

• --info
  Show Active Targets, Networks
  and local Available merOS configuration sets.

The recommended free-space for the project sits at around 12- 15GB ( For mos_lab ) -
With the possibility to free up to ~92% after initial build -
By a simple rm -rf of ./data/build/bootstrap/[fam_id].
Since the final image resides under: ./data/images/[target-full-id]

---

COMMUNICATING WITH A VM

The following require an SSH server set-up on the Target ( VM ) Side,
Along with an active network connection with the host ( As found in mos_mersec )

• --connect [vm-full-id]
  SSH into Targets' defined user ( As found under: $CONF/build/[target-id] )

• --run [vm-full-id] [VMs-executable]
  ex. mos_sec-guest --run firefox

• --push [vm-full-id] [file/ folder]
  Copy file to Target ( Defaults transfers to VMs Users' ~/.mos-shared/ )

• --pull [vm-full-id]
  Pull all files from Targets' ~/mos-shared/
  to ./data/mos-shared/[vm-full-id]

---

CONTRIBUTING

I am by no means a professional developer.
This is a project in which I hope to learn, and share ideas- concepts and practical solutions
to development and modern privacy and management problems.

Any contributions are welcome, you're encouraged to create tickets,
pull requests or offer any ideas on the project!

---

COPYRIGHT

License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

---

IMPORTANT NOTES:

Being an actively developed, actively maintained project- No security guarantee is provided.
Bugs are to be expected, implementations ( secure-critical or not ) may be broken.
And as always, security issues may arise from within the selected frameworks used-
no matter how widely adopted, or thoroughly tested they be.