1 21b-Virtualization


Previous: 21a-OSHardening.html

https://en.wikipedia.org/wiki/Down_the_Rabbit_Hole
21b-Virtualization/vms.jpg

1.1 Screencasts

Included as part of lecture: 21a-OSHardening.html

1.2 Background and reading

../../DataStructuresLab/Content/00-VirtualMachines.html

https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/book.virt.html

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_getting_started_guide/

1.3 Benefits: why virtualize?

A virtual sandbox where you can experiment with coding, hacking, cracking, etc.
Snapshots allow reverting to earlier states!!
You can do software unit and integration testing on other operating systems.
Security and isolation (Graders run student code in a virtual machine for example).
Good computer hygiene (keep your OS clean).

1.4 Hypervisors and Virtual Machines

https://en.wikipedia.org/wiki/Virtual_machine

A virtual machine (VM) is an emulation of a computer system.
Virtual machines are based on computer architectures and provide functionality of a physical computer.
Their implementations may involve specialized hardware, software, or a combination.
Software simulates hardware, so that an operating system can run inside of a software environment.

https://en.wikipedia.org/wiki/Hypervisor

A hypervisor is also known as a virtual machine monitor (VMM).
It is computer software, firmware or hardware that creates and runs virtual machines.
A computer on which a hypervisor runs one or more virtual machines is called a host machine.
Each virtual machine is called a guest machine.
The hypervisor presents the guest operating systems with a virtual operating platform,
and manages the execution of the guest operating systems.

1.4.1 Normal OS

21b-Virtualization/f1-crop.png

1.4.2 Two types of hypervisor (and another category below)

21b-Virtualization/hyper.png

1.4.3 Type-1, native or bare-metal hypervisors

These hypervisors run directly on the host’s hardware,
to control the hardware and to manage guest operating systems.
For this reason, they are sometimes called bare metal hypervisors.
Xen is a type-1 hypervisor, for example.
These are more secure than type 2

21b-Virtualization/f2-crop.png
21b-Virtualization/Type-1-Hypervisor.png
21b-Virtualization/type2.png

1.4.4 Type-2 or hosted hypervisors

These hypervisors run on a conventional operating system (OS),
just as other computer programs do.
A guest operating system runs as a process on the host.
Type-2 hypervisors abstract guest operating systems from the host operating system.
VirtualBox for example is a type-2 hypervisor, less secure than type 1
Still a lot better than your host alone!

21b-Virtualization/f3-crop.png
21b-Virtualization/Type-2-Hypervisor.png
21b-Virtualization/type1.png

1.4.5 Levels (within type 1 and 2)

Full virtualization almost complete simulation of the actual hardware,
to allow software, which typically consists of a guest operating system, to run unmodified.

Paravirtualization a hardware environment is not simulated
However, the guest programs are executed in their own isolated domains,
as if they are running on a separate system.
Guest programs need to be specifically modified to run in this environment.

1.4.6 Type-3: Containers (OS-level pseudo-virtualization)

https://en.wikipedia.org/wiki/Container_(virtualization)
https://en.wikipedia.org/wiki/LXC
21b-Virtualization/containers.png

1.4.6.1 chroot jail (almost a container)

Restricts a running process to a subset of the file system,
by mapping the processes view of root to a sub-directory of the actual root user.
Not all processes tolerate this well,
and it can require including more directories into the jail
If a process can run as root,
then it is possible to break out of the chroot jail

1.4.6.2 Container

One kernel allows the existence of multiple isolated user-space instances.
Such instances, called containers, partitions,
virtualization engines (VEs) or jails (FreeBSD jail or chroot jail),
may look like real computers from the point of view of programs running in them.
Typical program can see all resources of that computer,
(connected devices, files and folders, network shares, CPU power, quantifiable hardware capabilities)
but programs running inside a container can only see the container’s contents,
and devices assigned to the container.
They can be seen as an advanced implementation of the standard chroot mechanism,
which changes the apparent root folder for the current running process and its children.
Kernel provides resource-management features,
to limit the impact of one container’s activities on other containers.

Warning:

Containers like Docker are pretty easy to escape.
Use them only for minor sandboxing purposes.

1.5 Examples (of all types)

1.5.1 Virtualbox (type 2)

https://www.virtualbox.org/
https://en.wikipedia.org/wiki/VirtualBox

21b-Virtualization/vbox.png

1.5.2 KVM (type 2)

https://www.linux-kvm.org/page/Main_Page
https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/book.virt.html

21b-Virtualization/kvm1.png
21b-Virtualization/kvm0.png
21b-Virtualization/KVM.png

1.5.3 Xen (type 1)

https://xenproject.org/
https://en.wikipedia.org/wiki/Xen
https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/book.virt.html

21b-Virtualization/xen_master_fong_a.png
21b-Virtualization/Xen-architecture-29.png
21b-Virtualization/Xen.png

1.5.4 Docker (container)

https://en.wikipedia.org/wiki/LXC
https://en.wikipedia.org/wiki/Docker_(software)
https://codereviewvideos.com/course/docker-tutorial-for-beginners
21b-Virtualization/docker.png

Docker vs. VM:
21b-Virtualization/docker2.png

21b-Virtualization/vm-vs-docker-diagram.png

+++++++++++++++++++++
Cahoot-21b.1

1.6 Management of VMs

1.6.1 Virtualbox manager

21b-Virtualization/Screenshot_20180606_013918.png

1.6.2 Libvirt (interface to many backend hypervisors)

21b-Virtualization/libvirt.png

1.6.3 VM-based operating systems

Security by isolation, in addition to security by correctness

1.6.3.1 Spectrum OS

https://spectrum-os.org/

1.6.3.2 Bottlerocket OS

https://github.com/bottlerocket-os

1.6.3.3 Rancher OS

https://rancher.com/

1.6.3.4 Fedora silverblue OS

https://silverblue.fedoraproject.org/
https://fedoramagazine.org/what-is-silverblue/

1.6.3.5 Genode OS

A compartmentalized micro-kernel OS framework
https://genode.org/index
https://en.wikipedia.org/wiki/Genode

1.6.3.6 CLIP os

https://clip-os.org/en/

1.6.3.7 SubGraph OS: containers for isolation

21b-Virtualization/sgos.png

Not really a mature/stable/alive project.
Known exploits can escape containers with relative ease.

1.6.3.8 Qubes OS

Bare metal hypervisor (Xen), with full VM for isolation.

https://www.qubes-os.org/intro/
https://www.qubes-os.org/video-tours/

21b-Virtualization/qubes0.png

Qubes OS: detailed
21b-Virtualization/qubes-trust-level-architecture.png
21b-Virtualization/r4.0-snapshot12.png
21b-Virtualization/r4.0-qubes-manager.png
21b-Virtualization/qubes-partition-data-flows.jpg
21b-Virtualization/qubes-components.png

1.7 Security and virtualization

Guest OS isolation,
ensuring that programs executing within a guest OS,
may only access and use the resources allocated to it,
and not covertly interact with programs or data,
either in other guest OS’s, or in the hypervisor.

Guest OS monitoring by the hypervisor,
which has privileged access to the programs and data in each guest OS,
and must be trusted as secure from subversion,
and compromised use of this access.

Virtualized environment security,
particularly image and snapshot management,
which attackers may attempt to view or modify.

Minimize access to the hypervisor
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_security_guide/

21b-Virtualization/sandboxes.png

Are we going in circles here…
What about security by correctness and minimalism?

1.8 Unikernels

https://en.wikipedia.org/wiki/Unikernel
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/

A unikernel is a specialized, single address space machine image,
constructed by using library operating systems.
A developer selects, from a modular stack, the minimal set of libraries,
which correspond to the OS constructs required for their application to run.
These libraries are then compiled with the application and configuration code,
to build sealed, fixed-purpose images (unikernels),
which run directly on a hypervisor or hardware,
without an intervening OS such as Linux or Windows.

1.9 Microkernels

https://en.wikipedia.org/wiki/Microkernel
A microkernel is the near-minimum amount of software needed to implement an operating system (OS).
These mechanisms include:
low-level address space management,
thread management, and
inter-process communication (IPC).

If the hardware provides multiple rings or CPU modes,
then the microkernel may be the only software executing at the most privileged level,
which is generally referred to as supervisor or kernel mode.
Traditional operating system functions,
such as device drivers, protocol stacks and file systems,
are typically removed from the microkernel itself,
and are instead run in user space.

In terms of the source code size, microkernels are usually much smaller than monolithic kernels.

1.9.1 Minix

https://www.minix3.org/
https://en.wikipedia.org/wiki/Minix
The MINIX3 microkernel, for example, has approximately 12,000 lines of code,
compared to 12,000,000 for a small monolithic kernel.

1.9.2 Redox

https://www.redox-os.org
https://en.wikipedia.org/wiki/Redox_(operating_system)
Inspired by those like Minix, but written in a memory safe language, Rust.

1.9.3 Xous

Microkernel in Rust
https://betrusted.io/xous-book/ch00-00-introduction.html
https://github.com/betrusted-io/xous-core

1.9.4 rCore

Educational kernel in Rust
https://github.com/rcore-os/rCore
https://github.com/rcore-os/zCore

1.9.5 Other minimalist operating systems

https://softwareengineering.stackexchange.com/questions/117973/are-there-any-os-which-are-simple-enough-for-learning
https://homepage.divms.uiowa.edu/~jones/opsys/notes/06.shtml

1.10 Virtual networking

https://en.wikipedia.org/wiki/Network_virtualization

Network virtualization combines the functionality of network hardware and software,
into a single, software-based administrative entity, a virtual network.
Network virtualization involves platform virtualization,
often combined with resource virtualization.
Network virtualization is categorized as either:
external virtualization, combining many networks or parts of networks into a virtual unit, or
internal virtualization, providing network-like functionality to software containers on a single server.

1.10.1 VirtualBox

https://blogs.oracle.com/scoter/networking-in-virtualbox-v2
https://www.virtualbox.org/manual/ch06.html

1.10.2 KVM

https://www.linux-kvm.org/page/Networking
https://help.ubuntu.com/community/KVM/Networking
https://jamielinux.com/docs/libvirt-networking-handbook/

1.10.3 Xen

https://wiki.xenproject.org/wiki/Xen_Networking
https://wiki.xenproject.org/wiki/Xen_FAQ_Networking

1.10.4 Qubes

https://www.qubes-os.org/doc/firewall/
https://www.qubes-os.org/doc/networking/

1.11 Meta-management

How do you manage and build hordes of networked VMs in your virtual network?

1.11.1 Mass-administration and provisioning

https://www.terraform.io/
https://www.vagrantup.com/
https://www.ansible.com/
https://en.wikipedia.org/wiki/Ansible_(software)
https://en.wikipedia.org/wiki/Kubernetes
https://kubernetes.io/

+++++++++++++++++++++
Cahoot-21b.2

Next: 21d-PracticalPersonal.html