This chapter describes the unique features of Subgraph OS. These are features that distinguish it from other operating systems. This is where you can find more information about the design of Subgraph OS.
This chapter also provides documentation for some advanced use-cases in Subgraph OS. This content is more technical than previous chapters in the Subgraph OS Handbook. It contains how-tos and reference materials intended for users who are comfortable running commands in the terminal and editing configuring files.
Sandboxing applications with Subgraph Oz
Subgraph OS runs desktop applications inside of our security sandbox (Oz). The security sandbox is an additional layer of security, above and beyond the othersecurity features of Subgraph OS. Subgraph OS is hardened to make it very difficult for an attacker to compromise applications. However, it is impossible to prevent every vulnerability. If an attacker compromises an application, Oz can help to protect the computer and the user's sensitive files against further compromise.
Oz can provide the following protections to sandboxed applications:
- Restrict the files that the application has access to
- Restrict network access
- Restrict audio playback
- Restrict the system calls the application can make (using seccomp)
- Restrict malicious interactions between X11 applications (using xpra)
Each sandboxed application has its own policies to restrict its capabilities.
The following table shows some of the sandbox policies in Subgraph OS:
| Tor Browser |
Browser |
Proxy port |
Yes |
| Icedove |
Email client |
Proxy port |
No |
| CoyIM |
Instant messager |
Proxy port |
No |
| Ricochet |
Instant messager |
Proxy port |
No |
| Hexchat |
IRC client |
Proxy port |
No |
| OnionShare |
File sharing |
Proxy port |
No |
| VLC |
Video player |
No |
Yes |
| LibreOffice |
Office suite |
No |
No |
| Evince |
PDF reader |
No |
No |
| Eog |
Image Viewer |
No |
No |
Oz also sandboxes desktop applications from each other. Normally, applications running under the X11 display server can interact with each other. This means that one application can intercept or inject events into another application.
Without Oz or an alternate display server, there is no way to securely prevent applications from interacting with each other. An attacker could abuse this to perform malicious actions such as intercepting the keystrokes from another desktop application. To prevent these attacks, Oz sandboxes use xpra to render applications on the desktop. Xpra isolates applications by using a separate display server to render each application. Since the applications do not share the same display server, they cannot interact.
For more technical details about Oz and its security features, see the following page:
https://github.com/subgraph/oz/wiki/Oz-Technical-Details
Enabling an Oz profile
Oz profiles can be found in the following directory:
/var/lib/oz/cells.d
Oz automatically enables profiles in this directory. However, if you need to manually enable a profile, you can do so by running the oz-setup command to install the profile.
The following example installs the profile for evince:
$ sudo oz-setup install evince
When the profile is installed, Oz will divert the path of the program executable. Instead of the program running directly, diverting it lets Oz start the program. So the next time it is started, the program will be sandboxed by Oz.
Disabling an Oz profile
If you want to run a previously sandboxed program outside of the sandbox, you must disable its profile. To disable a profile, run the oz-setup command with the remove option.
The following example removes the profile for evince:
$ sudo oz-setup remove evince
When the profile is removed, Oz will undo the divert of the program path. The program will not run in the Oz sandbox the next time it is started.
Viewing the status of an Oz profile
The status of a program can also be viewed with the oz-setup command.
The following example shows the status of evince:
$ sudo oz-setup status /usr/bin/evince
The command prints the following when evince profile is installed:
Package divert is installed for: /usr/bin/evince
Package divert is installed for: /usr/bin/evince-thumbnailer
Package divert is installed for: /usr/bin/evince-previewer
When the evince profile is not installed, the command prints the following:
Package divert is not installed for: /usr/bin/evince
Package divert is not installed for: /usr/bin/evince-thumbnailer
Package divert is not installed for: /usr/bin/evince-previewer
Creating an Oz profile
In this section, we will walk through some of the options in a basic profile.
Oz profiles are written in JSON.
The following is the Oz profile for the eog image viewer:
{
"name": "eog"
, "path": "/usr/bin/eog"
, "allow_files": true
, "xserver": {
"enabled": true
, "enable_tray": false
, "tray_icon":"/usr/share/icons/hicolor/scalable/apps/eog.svg"
}
, "networking":{
"type":"empty"
}
, "whitelist": [
{"path":"/var/lib/oz/cells.d/eog-whitelist.seccomp", "read_only": true}
]
, "blacklist": [
]
, "environment": [
{"name":"GTK_THEME", "value":"Adwaita:dark"}
, {"name":"GTK2_RC_FILES",
"value":"/usr/share/themes/Darklooks/gtk-2.0/gtkrc"}
]
, "seccomp": {
"mode":"whitelist"
, "enforce": true
, "whitelist":"/var/lib/oz/cells.d/eog-whitelist.seccomp"
}
}
Example Oz profile configuration options
name: The name of the profile
path: The path to the program executable
allow_files: Allow files to be passed as arguments to the program (such as image files for eog)
xserver -> enabled: Enable the use of the Xserver (xpra)
xserver -> enable_tray: Enable the xpra diagnostic tray (defaults to false, enabling it requires extra software)
xserver -> tray_icon: The path to the tray icon
networking -> type: The networking configuration type, empty disables networking entirely
whitelist -> path: The path of a file to add to the sandbox, in this case it is the seccomp whitelist for eog
whitelist -> path -> read_only: Whether or not the allowed file is read-only, should be true in most cases
blacklist: Removes access to a file in the sandbox, accepts the path argument
environment -> name, value: Adds environment variables by name and value to the sandbox
seccomp -> mode: Adds a seccomp policy (either whitelist or blacklist) to the sandbox
seccomp -> enforce": The seccomp enforcement mode
seccomp -> whitelist: The path to the whitelist policy
Oz supports a number of different profile configurations. More examples for real applications are located in the profiles directory:
/var/lib/oz/cells.d
Complete documentation for creating Oz profiles can be found here:
https://github.com/subgraph/oz
Securing system calls with seccomp in Oz
Seccomp is a feature of the Linux kernel to limit exposed system calls. As system calls provide a user interface to the kernel, they expose it to attacks. These attacks can let an attacker elevate their privileges on the computer. The Oz sandbox uses seccomp to protect against this type of attack.
Oz supports seccomp policies on a per-application basis. Seccomp kills applications whenever they violate a policy. This protects the computer in cases where an attacker tries to exploit a vulnerability in the kernel that depends on the blocked system call.
Some attacks also use system calls as part of their payload. A payload is the malicious code that runs as a result of a successful exploit. The seccomp policies in Oz can prevent payloads from running if they use a blocked system call.
Oz supports whitelist or blacklist policies. Whitelist policies are default deny. This means that only system calls that are explicitly permitted will be allowed. All other system calls (those not on the whitelist) cause the application to be killed.
Blacklist policies are default allow. This means that seccomp blocks system calls in the blacklist policy but allows all others (those not on the blacklist).
Whitelist policies are appropriate when the application is well understood. By well understood, we mean that the behavior of the application is predictable enough to create a precise profile of allowed system calls. This is more secure than a blacklist because known behavior of the application is allowed but unknown behavior is blocked. The disadvantage of this approach is that the whitelists must be updated regularly to reflect the known behavior of the application.
Blacklist policies are appropriate for applications that are not as well understood. We use them prior to the creation of a whitelist or if there is some other reason a whitelist cannot be created.
Oz includes a generic blacklist that will work out-of-the-box with many applications. This policy blocks unusual or exotic system calls that applications do not normally use.
The Oz generic blacklist is located here:
/var/lib/oz/cells.d/generic-blacklist.seccomp
In Subgraph OS, we try to create whitelist policies for all of our supported applications.
See the Appendix for a complete list of system calls in Subgraph OS. You can use this reference to look up system call numbers when writing or debugging seccomp policies.
Profiling applications with oz-seccomp-tracer
Oz includes a tool to help with the creation and maintenance of seccomp whitelists. The oz-seccomp-tracer profiles applications as they run to determine the system calls that they use. This tool will generate a seccomp whitelist after it exits.
To profile Firefox using oz-seccomp-tracer, run the following command:
$ oz-seccomp-tracer -trace -output firefox-whitelist.seccomp /usr/bin/firefox \
2>firefox_syscalls.txt
You can then use Firefox as you normally would. When you are finished, a seccomp whitelist will be saved to firefox-whitelist.seccomp. oz-seccomp-tracer prints all of the system calls from the application to stdout. So we also advise you to redirect this output to a separate file. We use firefox_syscalls.txt in this example. You could also redirect this output to /dev/null if you don't want to save it.
Adding a seccomp policy to an Oz application profile
Once you are satisfied with the whitelist, you can copy it to the following directory:
/var/lib/oz/cells.d
Using Firefox as an example, the following snippets from /var/lib/oz/cells.d/firefox.json show how to apply the policy.
First, the seccomp policy file must be added to the list of files allowed in the sandbox:
"whitelist": [
, {"path":"/var/lib/oz/cells.d/firefox-whitelist.seccomp",
"read_only": true}
]
Then the seccomp policy needs to be enabled to run in enforce mode:
"seccomp": {
"mode":"whitelist"
,
"whitelist":"/var/lib/oz/cells.d/firefox-whitelist.seccomp"
, "enforce": true
}
Lastly, the Oz daemon must be restarted to load the seccomp policy. You should save your work at this point as restarting Oz will close all of the open sandboxes. To restart the Oz daemon, run the following command:
$ sudo systemctl restart oz-daemon.service
Anonymizing communications with Tor
Tor is an essential privacy tool that provides anonymity to its users. In particular, Tor hides the location of its users. By location, we mean your IP address (which can also be used to geo-locate your computer).
Tor hides your location by relaying your traffic through a random series of network connections (called a circuit). While your traffic passes through the hops in this circuit, the source and destination of the traffic are hidden. The traffic eventually leaves the circuit through an exit node. The exit node relays the traffic to its final destination but is also unaware of the source. They are called exit nodes because they are the point where the traffic leaves the Tor network to reach its destination on the regular Internet. Exit nodes may observe or tamper with the traffic en-route to its destination, unless an additional layer of encryption is applied such as TLS.
Due to the possibility that some exit nodes are malicious, we strongly advise you to use Tor with an additional layer of encryption. This means connecting to websites over HTTPS only, using TLS with applications such as Icedove or Hexchat, etc.
NOTE: Tor hidden services provide a way to send network traffic only through the Tor network. This eliminates the risks involved when the traffic passes through an exit node to the regular Internet. However, this requires that the destination service is configured to run as a hidden service. It also adds more latency to the network traffic because it must pass through more hops to reach the hidden service. Tor hidden services are discussed in further detail in other sections of this book.
More information about Tor can be found here:
https://www.torproject.org/about/overview
Tor integration in Subgraph OS
Subgraph OS is integrated with the Tor anonymity network. We include many applications that are designed to be used with Tor. These include:
- Tor Browser for browsing the web anonymously and accessing Tor hidden service websites
- OnionShare for sharing files anonymously over Tor
- Ricochet for chatting anonymously of Tor
- CoyIM instant messager, which supports connecting to the .onion addresses for XMPP/Jabber chat servers
Other parts of Subgraph OS are engineered to integrate with Tor seamlessly. The Metaproxy routes non-Tor applications over Tor. Our Oz sandbox also lets applications work seamlessly with Tor. We also include a Gnome Shell extension that monitors that status of connections to the Tor network. Lastly, ROFLCopTor is a filter for the Tor control port that enforces security policies on applications that run Tor control commands.
Securing the Tor control port with ROFLCopTor
The Tor service is managed by a control protocol. This lets users perform various actions such as querying information about Tor connections, starting hidden services, and changing configuration options. However, most applications do not need all of these features. These extra features may actually introduce security and privacy risks if someone gains unauthorized access to the control port. To mitigate these risks, Subgraph OS includes a control port filter called ROFLCopTor.
ROFLCopTor is a proxy server that is placed between Tor control clients and the Tor control server port. ROFLCopTor handles authentication itself, meaning clients do not need to know the authentication credentials or run with higher privileges to access to Tor control port. It intercepts the incoming commands and outgoing responses. ROFLCopTor enforces policies on a per-application basis for the traffic between the Tor control clients and the server.
ROFLCopTor supports policies that are bi-directional. This means that a policy can filter both the incoming commands and the outgoing responses from the Tor control port. Policies can also replace command and response strings. Replacements can be used to filter sensitive information from Tor control port responses.
ROFLCopTor has a number of default policies for applications in Subgraph OS that require access to the Tor control port. The policies work without modification for most use-cases. This section describes how to profile applications to create new policies or modify existing ones.
Profiling applications with ROFLCopTor
ROFLCopTor can profile applications to determine the Tor control commands that they run on a regular basis. This makes it easier to create or edit policies.
Before profiling applications, you should stop the currently running version of ROFLCopTor:
$ sudo systemctl stop roflcoptor
To begin profiling, you must start ROFLCopTor in watch mode:
$ sudo -u roflcoptor roflcoptor watch -log_level DEBUG \
-config /etc/roflcoptor/roflcoptor_config.json
The log shows some of the commands that applications tried to run:
18:21:53 - DEBU 017 connection received tcp:127.0.0.1:44860 ->
tcp:127.0.0.1:9051
18:21:55 - ERRO 018 filter policy for gnome-shell-torstatus DENY: A->T: [GETCONF
ORPort]
18:21:55 - ERRO 019 filter policy for gnome-shell-torstatus DENY: A->T: [GETINFO
events/names]
18:21:55 - ERRO 01a filter policy for gnome-shell-torstatus DENY: A->T:
[SETEVENTS NOTICE NS NEWDESC NEWCONSENSUS]
18:21:55 - ERRO 01b filter policy for gnome-shell-torstatus DENY: A->T: [GETINFO
process/user]
18:21:55 - ERRO 01c filter policy for gnome-shell-torstatus DENY: A->T: [GETINFO
process/pid]
...
Press Ctrl-C to stop the ROFLCopTor watch process. Make sure to restart ROFLCopTor normally after you are done profiling. Run the following command to restart ROFLCopTor:
$ sudo systemctl restart roflcoptor
Editing ROFLCopTor policies
Once you have a list of commands required by an application, you can create or edit a policy.
ROFLCopTor policies are written in JSON. Policies can be found in the following directory on Subgraph OS:
/etc/roflcoptor/filters/
The following is a simple policy for the Tor Status Gnome shell extension in Subgraph OS:
{
"Name": "gnome-shell-torstatus",
"AuthNetAddr" : "tcp",
"AuthAddr" : "127.0.0.1:9051",
"client-allowed" : ["GETINFO status/bootstrap-phase", "SIGNAL NEWNYM"],
"client-allowed-prefixes" : [],
"client-replacements" : {},
"client-replacement-prefixes" : {},
"server-allowed" : ["250 OK"],
"server-allowed-prefixes" : ["250-status/bootstrap-phase="],
"server-replacement-prefixes" : {}
}
ROFLCopTor policy configuration options
Name: The name of the application to apply the policy to
AuthNetAddr: The protocol used by the Tor control port
AuthAddr: The address of the Tor control port
client-allowed: The list of commands allowed by the client
client-allowed-prefixes: A list of prefixes for partial allowed client commands (commands where the suffix varies)
client-replacements: A list of commands to replace and their replacement strings
client-replacement-prefixes: A list of client command prefixes to replace and their replacement strings (for commands where the suffix varies)
server-allowed: The list of responses allowed by the server
server-allowed-prefixes: A list of prefixes for partial allowed server responses (responds where the suffix varies)
server-replacement-prefixes: A list of server response prefixes to replace and their replacement strings (for responses where the suffix varies)
The most common configuration task is to add new commands and responses to the client-allowed, client-allowed-prefixes, server-allowed, and server-allowed-prefixes options.
More documentation on configuring and using ROFLCopTor is located on the following page: https://github.com/subgraph/roflcoptor
Hardening the operating system and applications with Grsecurity
Grsecurity is a third-party security enhancement to the Linux kernel. It is developed and maintained by the Grsecurity team. It is implemented as a patch to the upstream Linux kernel. Subgraph OS ships with a kernel that is patched with Grsecurity.
For more information about Grsecurity, see the following page:
https://grsecurity.net/
Configuring PaX flags with Paxrat
Paxrat is a utility in Subgraph OS for maintaining the PaX flags of applications on the computer.
What is PaX?
PaX is a feature of Grsecurity that provides memory protection. Many security vulnerabilities in applications and the Linux kernel allow attackers to corrupt process memory. Memory corruption can be exploited to run the attackers payload of malicious code.
PaX protects the computer from memory corruption using a number of novel techniques such as:
- Randomizing the layout of process memory or ASLR (Address Space Layout Randomization), making it harder for attackers to guess where their malicious payload is stored in process memory
- Making memory pages non-executable, meaning that an attacker's payload cannot run if stored in non-executable memory
PaX includes other memory protection and control flow integrity features so that it is more difficult for attackers to exploit memory corruption vulnerabilities in applications and the kernel.
PaX does not prevent all vulnerabilities but it complicates attacks. The difference to an attacker is that with PaX they may be required to exploit multiple vulnerabilities to achieve the same effect as a single vulnerability.
More information about PaX can be found here:
https://pax.grsecurity.net/
PaX works by killing applications that violate its security policies. This proactively prevents attacks from succeeding. However, as part of their normal functions, some applications perform non-malicious actions that violate the security policies. PaX flags are exceptions to these policies. They let applications run normally without being killed by PaX when they perform an action that appears to violate policies.
Applications such as web browsers need PaX flags to be set because they perform actions such as JIT (Just in Time compilation). To PaX, JIT has the same profile as an attack. Applications that use a JIT compiler must be flagged as exceptions so that they are not killed.
Paxrat keeps track of the PaX flags for applications in Subgraph OS. It is designed to maintain the PaX flags between application updates. Paxrat runs when the system updates software, automatically re-applying flags to upgraded applications.
Paxrat can only maintain the flags it knows about. If a user discovers that PaX is killing an application, the configuration must be changed to disable some PaX flags. Instructions are provided in this guide for changing the Paxrat configuration. We also advise users to report the exception to us so that we can update the configuration for everybody.
Paxrat configuration files are written in JSON. They are stored in the following directory:
/etc/paxrat
The following is a snippet of a PaX flag configuration for Tor Browser:
"/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/firefox":
{
"flags": "m",
"nonroot": true
}
Paxrat configuration options
The first line of the configuration (in quotes) is the path to the application. In the above example, it is: "/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/firefox"
flags: This a string of letters representing the various PaX flags
nonroot: This indicates whether the application is owned by the root user or not, it is false by default but true in the example because the Tor Browser application is owned by a normal user
NOTE: As a security precaution, Paxrat will not apply PaX flags to an application that is owned by a nonroot user unless the nonroot option is set to true.
There are a number of different PaX flags that can be enabled or disabled. Most are enabled by default and must be disabled. Disabled flags are represented by a lower-case letter such as m. Upper-case letters such as M represent enabled flags.
PaX flags
P/p: Enable/disable PAGEXEC
E/e: Enable/disable EMUTRAMP
M/m: Enable/disable MPROTECT
R/r: Enable/disable RANDMAP
X/x: Enable/disable RANDEXEC
S/x: Enable/disable SEGMEXEC
A detailed description of these flags can be found on the following page:
https://en.wikibooks.org/wiki/Grsecurity/Appendix/PaX_Flags
Working examples can be found in the Subgraph OS Paxrat configuration files:
/etc/paxrat/paxrat.conf
Applying PaX flags
PaX flags must be re-applied after any configuration changes. Run the following command to re-apply PaX flags:
$ sudo paxrat
Anonymizing MAC addresses with Macouflage
MAC addresses are the unique identifiers for the network interface on the computer (such as Ethernet ports and WIFI cards). Due to their unique nature, they can also compromise the privacy of the user.
When connecting to a network, it is possible for other devices on the network to see the MAC address of the network interface that is connected. While this is not much of a concern on networks you trust such as your home network, it may compromise your privacy on those who do not trust. On untrustworthy or hostile networks, uniquely identifying characteristics such as the MAC address may allow others to track your computer.
Subgraph OS mitigates this privacy risk by always creating random MAC addresses for all of your network interfaces. Each time one of your interfaces connects to a network, it will use a different MAC address. This helps to anonymize you across different networks or when connecting to the same network over and over again.
Preventing unauthorized USB access with USB Lockout
USB Lockout is a background feature in Subgraph OS. It protects your computer from unauthorized USB access while your desktop session is locked or you have logged out.
USB Lockout is intended for situations where your computer must be left unattended for short periods. Particularly, in situations where you do not fear your computer will be stolen but you do do not want to expose it to other risks while unattended.
Normally, when you lock the screen or logout, people may still insert a malicious USB device into the computer. While the computer is running, a malicious device can easily compromise it. USB Lockout denies all access for new USB devices while the screen is locked or the user is logged out.
USB Lockout works by monitoring the state of the desktop session. When the session is locked or logged out, USB Lockout enables the Grsecurity Deny New USB setting. When the user unlocks the screen or logs back in, this setting is disabled, allowing access to new USB devices once again.
See the following page page for more information about the Grsecurity Deny New USB feature:
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Deny_new_USB_connections_after_toggle
Enabling/disabling USB Lockout
While USB Lockout runs automatically in the background, you can manually enable or disable it.
Run the following command to enable USB Lockout:
Run the following command to disable USB Lockout:
Using virtual machines in Subgraph OS
Contrary to popular belief, there is nothing that stops the use of virtual machines in Subgraph OS. While the Grsecurity kernel is not compatible with VirtualBox, Qemu/KVM works as expected. However, you must install Qemu/KVM yourself if you want to run virtual machines.
Running the following command with install Qemu/KVM:
$ sudo apt install qemu-system qemu-kvm qemu-utils
Creating a virtual machine with Qemu
The following sections are recipes on how to use Qemu/KVM in Subgraph OS. They are similar to our own workflows for developing and testing Subgraph OS. Qemu/KVM supports many more options than what we use in these tutorials. For more detailed information regarding the operation of Qemu/KVM virtual machines, see the official Qemu manual:
http://wiki.qemu.org/Manual
There are multiple third-party graphical user interfaces for Qemu/KVM. These may make it easier to configure and manage virtual machines. You can explore the various options by visiting these pages:
Creating a basic Linux virtual machine
Prior to creating the virtual machine, you should create a virtual hard-drive image for it:
$ qemu-img create -f qcow2 disk.qcow2 8G
Your virtual hard-drive is now ready for use. Run the following command to test a virtual machine with the hard-drive:
$ qemu-system-x86_64 -enable-kvm -hda ./disk.qcow2 -m 4096
To start a virtual machine with an operating system ISO attached to the virtual CDROM, run the following command:
$ qemu-system-x86_64 -enable-kvm -hda ./disk.qcow2 -m 4096 \
-cdrom ./subgraph-os-alpha_2016-06-16_2.iso -boot d
Qemu/KVM options
-enable-kvm: enables KVM virtualisation, which is faster than Qemu's emulation
-hda: This attaches the virtual hard-drive you created
-m: This allocates RAM to the virtual machine (4096MB in the example)
-cdrom: The path to the operation system ISO
-boot: This specifies the boot order for the virtual machine, d is the virtual CDROM
This example can be adapted to run the Linux distribution of your choice inside of a virtual machine.
Creating an advanced Debian Stretch virtual machine using debootstrap
To have more control over the installation of Debian inside of a virtual machine, you can use debootstrap to install the operating system. Another advantage of this approach is that you can avoid all of the installation dialogs of the Debian installer.
This section will show how to install Debian Stretch with the Grsecurity kernel from Subgraph OS.
Create a virtual hard-drive image for the operating system
To begin the install, you must set up a virtual hard-drive image. Follow these steps to set it up:
Run the following command to create a sparse virtual hard-drive image:
$ truncate --size 8G ./disk.img
To format the virtual hard-drive run the following command:
$ /sbin/mkfs.ext4 ./disk.img
After formatting the hard-drive, you can create a proper partition table. We will skip this step in the tutorial as it is not strictly necessary to run the virtual machine.
Mount the virtual hard-drive:
$ sudo mount -o loop ./disk.img /mnt
NOTE: You should ensure there is enough free space in the image you create. You may want to allocate twice as much if you want to convert the image later on.
The sparse virtual hard-drive image you created will only use as much space as it requires.
Run the following command to show how much space is used by the image:
The amount shown is a fraction of the total amount specified in the truncate command:
189M disk.img
To verify the total amount that was specified in the truncate command, run this command:
$ du --apparent-size -sh disk.img
The total amount should correspond with what was specified when you ran
truncate:
8.0G disk.img
Installing the operating system with deboostrap
Now that the virtual disk-image is created, we can now use debootstrap to install Debian Stretch. Follow these steps to install it:
Run debootstrap to install the operating system:
$ sudo debootstrap --variant=mintbase --include=systemd-sysv stretch /mnt
Set a root password for the installed operating system:
$ sudo chroot /mnt passwd
Create a standard fstab configuration:
$ sudo tee /mnt/etc/fstab << EOL
/dev/sda / ext4 defaults,errors=remount-ro 0 1
EOL
Installing the Grsecurity kernel in the operating system
Run the following commands to install the Subgraph OS Grsecurity kernel in your virtual machine:
$ cd /tmp
$ apt-get download linux-{image,headers}-grsec-amd64-subgraph linux-{image,headers}-$(uname -r)
$ sudo cp ./linux-{image,headers}-$(uname -r) /mnt/tmp
$ sudo chroot /mnt
$ dpkg -i /tmp/linux-{image,headers}-*
$ update-initramfs -u -k all
$ exit
The kernel and initramfs are inside of your mounted virtual hard-drive image. You must copy them to a directory on your computer to boot the virtual machine using these files. Run the following command to copy the files to the directory you want to start the virtual machine from:
$ cp /mnt/boot/vmlinuz-<version>-amd64 /mnt/boot/initrd.img-<version>-amd64 \
/home/user/path/to/vm
Finalizing the installation of the operating system
As the final step, we will sync the filesystem and unmount the virtual hard-drive image:
$ sync
$ sudo umount /mnt
(Optional) If you prefer, you may convert the virtual hard-drive image to the qcow2 format:
$ qemu-img convert -f raw -O qcow2 ./disk.img ./disk.qcow2
Starting the Debian Stretch virtual machine
Now you are ready to start the virtual machine. Run the following command to start it:
$ qemu-system-x86_64 -enable-kvm -hda ./disk.qcow2 \
-kernel ./vmlinuz-<version>-amd64 \
-initrd ./initrd.img-<version>-amd64 \
-append root=/dev/sda
NOTE: This assumes you converted the virtual hard-drive image to the qcow2. If not, replace disk.qcow2 with the correct name of your image.
Qemu/KVM options
This section uses some new options for Qemu/KVM.
-kernel: This is the operating system kernel to boot when starting a virtual machine
-initrd: This is the initramfs to boot when starting a virtual machine
-append: These are options to append to the kernel command line when starting a virtual machine
If you want to install grub to keep the kernel and initrd images inside the virtual machine you'll have to create a full partition table. You may also need to create a separate /boot partition. But this is out of scope for this tutorial.
Setting up simple networking in Qemu/KVM
By default, Qemu will transparently NAT your virtual machines to the host network. This can be disabled by using the -net none flag.
Alternatively, you can also open simple tunnels between the host and the virtual machine using the port redirection mechanism with the -redir flag:
-redir tcp:55700::55700
For more on networking in Qemu/KVM see:
The following actions may be performed using the Oz menu:
