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.
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.
Families are used to describe Sets of Targets ( VMs )
Configuration Files are found, and should be placed,
under:
conf/families/[fam-id]/
- containing:
-
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. ) -
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. ) -
Build XML configuration files :
build/[target-id].xml
Where Target properties are described,
such as Distro, Image Free Size, etc. -
Host run-Time hooks :
hooks/
Where Host run-time hooks can be found-
These are executed upon Family initialization. -
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 )
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
!
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.
[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]
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]
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!
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.
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.