mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Merge branch 'master' into unman-patch-1
This commit is contained in:
Andrew David Wong
commit
11e8187f4e
@ -8,10 +8,10 @@ redirect_from:
|
||||
- /wiki/BuildingNonFedoraTemplate/
|
||||
---
|
||||
|
||||
Building a TemplateVM for ArchLinux (or another non fedora OS)
|
||||
Building a TemplateVM for ArchLinux (or another non Fedora OS)
|
||||
==============================================================
|
||||
|
||||
If you don't like using Fedora because of specific administration or package management / building needs, you could build a VM Template for your Distribution of choice.
|
||||
If you don't like using Fedora because of specific administration, package management or other building needs, you could build a TemplateVM for your distribution of choice.
|
||||
|
||||
This article shows how to build a template for a different OS, taking ArchLinux as an example.
|
||||
|
||||
@ -23,9 +23,9 @@ You can start creating Qubes builder scripts for your new OS. Just note that it
|
||||
chroot initialization
|
||||
---------------------
|
||||
|
||||
You need to install your OS inside a chroot that will be used to build all the required qubes agents of tools.
|
||||
You need to customize some scripts that will be used to build all the Qubes tools.
|
||||
|
||||
The scripts you will be interested in will be inside the qubes-src/linux-template-builder project:
|
||||
The scripts you will be interested in will be inside the `qubes-src/linux-template-builder` folder:
|
||||
|
||||
~~~
|
||||
scripts_fedora
|
||||
@ -35,15 +35,15 @@ scripts_yourOSname
|
||||
|
||||
### 00\_prepare.sh
|
||||
|
||||
The goal of the first script 00\_prepare.sh is to download and verify the signature of the installation cd and tools. You can use the \$CACHEDIR directory variable to store files that could be reused (such as downloaded scripts or iso files)
|
||||
The goal of the first script `00_prepare.sh` is to download and verify the signature of the installation CD and tools. You can use the `$CACHEDIR` directory variable to store files that could be reused (such as downloaded scripts or iso files).
|
||||
|
||||
### 01\_install\_core.sh
|
||||
|
||||
The goal of this script is to install a base environment of your target OS inside the \$INSTALLDIR directory variable. Generally you need to bootstrap/install your package manager inside the \$INSTALLDIR directory and install the base packages.
|
||||
The goal of this script is to install a base environment of your target OS inside the `$INSTALLDIR` directory variable. Generally you need to bootstrap/install your package manager inside the `$INSTALLDIR` directory and install the base packages.
|
||||
|
||||
### Testing the installation process
|
||||
|
||||
Edit the builder.conf file to change the variable DISTS\_VM to your OS name (DISTS\_VM=your\_os\_name). The try to make the template to check that at least these to first scripts are working correctly:
|
||||
Edit the file `builder.conf` to change the variable `$DISTS_VM` to your OS name (`DISTS_VM=your_os_name`). The try to create (make) the template to check that at least these first two scripts are working correctly:
|
||||
|
||||
~~~
|
||||
make linux-template-builder
|
||||
@ -52,7 +52,7 @@ make linux-template-builder
|
||||
Qubes builder Makefiles
|
||||
-----------------------
|
||||
|
||||
Now you need to create Makefiles specific to your OS. You will find the required scripts directly inside qubes-builder:
|
||||
Now you need to create Makefiles specific to your OS. You will find the required scripts directly inside the `qubes-builder` folder:
|
||||
|
||||
~~~
|
||||
prepare-chroot-yourOSname
|
||||
@ -61,30 +61,30 @@ Makefile.yourOSname
|
||||
|
||||
### prepare-chroot-yourOSname
|
||||
|
||||
The goal of this file is to prepare a development environment of your target OS inside a chroot. You will reuse there the 00\_prepare.sh and 01\_install\_core.sh scripts. Additionally, the following things will be necessary to use to chroot environment:
|
||||
The goal of this file is to prepare a development environment of your target OS inside a chroot. You will reuse the `00_prepare.sh` and `01_install_core.sh` scripts. Additionally, the following things will be necessary to put in this Makefile:
|
||||
|
||||
- the \$1 variable will contain the installation directory (INSTALLDIR should contain the same value than \$1 when you run 00\_prepare or 01\_install\_core)
|
||||
- the `$1` variable will contain the installation directory (`$INSTALLDIR` should contain the same value as `$1` when you run `00_prepare.sh` or `01_install_core.sh`)
|
||||
- after your base system is installed, you should install development tools and libraries (gcc, make, ...)
|
||||
- create a user called 'user' inside your chroot, and give him enough rights to run the command sudo without any password
|
||||
- register all the repository that could be necessary and synchronize the package database
|
||||
- register all the repositories that are be necessary and synchronize the package database
|
||||
- register a custom repository that will be used to store Qubes packages
|
||||
|
||||
### Makefile.yourOSname
|
||||
|
||||
This file will be used to define the action required when installing a package. The most important one are:
|
||||
This file will be used to define the action required when installing a custom package. The most important one are:
|
||||
|
||||
- dist-prepare-chroot: that's where you will call prepare-chroot-yourOSname if the chroot has not been initialized
|
||||
- dist-package: that's where you will chroot the development environment and run the command used to build a package.
|
||||
- dist-build-dep: that's where you will create the custom repository for your target OS based on already compiled packages.
|
||||
- `dist-prepare-chroot`: that's where you will call `prepare-chroot-yourOSname` if the chroot has not been initialized.
|
||||
- `dist-package`: that's where you will chroot the development environment and run the command used to build a package.
|
||||
- `dist-build-dep`: that's where you will create the custom repository for your target OS based on already compiled packages.
|
||||
|
||||
These additional target need to exist once you created your first packages:
|
||||
|
||||
- dist-copy-out: that's where you will retrieve the package you just built and put it with all the other package you prepared.
|
||||
- update-repo: that's where you will retrieve the package that have been built and that need to be installed inside the template
|
||||
- `dist-copy-out`: that's where you will retrieve the package you just built and put it with all the other packages you prepared.
|
||||
- `update-repo`: that's where you will retrieve the package that have been built and add it to the custom repository.
|
||||
|
||||
### Testing the development chroot
|
||||
|
||||
You will be able to test these script when making the first Qubes packages. Don't forget that the first things that run when running 'make somcomponent-vm' will be these two scripts, and that you will need to debug it at this point.
|
||||
You will be able to test these scripts when making the first Qubes packages. Don't forget that the first things that run when running `make somcomponent-vm` will be these two scripts, and that you will need to debug it at this point.
|
||||
|
||||
Qubes packages
|
||||
--------------
|
||||
@ -99,7 +99,7 @@ Qubes packages
|
||||
Additional Installation scripts
|
||||
-------------------------------
|
||||
|
||||
Again you need to work on scripts inside the qubes-src/linux-template-builder project:
|
||||
Again you need to work on scripts inside the `qubes-src/linux-template-builder` folder:
|
||||
|
||||
~~~
|
||||
scripts_fedora
|
||||
@ -109,7 +109,7 @@ scripts_yourOSname
|
||||
|
||||
### 02\_install\_groups.sh
|
||||
|
||||
The goal of this script is to install all the package that you want to use in your template (eg: firefox, thunderbird, a file manager, Xorg...)
|
||||
The goal of this script is to install all the packages that you want to use in your template (eg: firefox, thunderbird, a file manager, Xorg...).
|
||||
|
||||
### 04\_install\_qubes.sh
|
||||
|
||||
@ -128,28 +128,24 @@ If no Qubes packages are available for your selected OS. You could start to inst
|
||||
- to create required Qubes packages
|
||||
- to identify potential issue making all Qubes agents and scripts working correctly.
|
||||
|
||||
As soon as you manage to make qrexec and qubes-gui-agent working, it should be sufficient to start preparing a template VM.
|
||||
As soon as you manage to make `qrexec` and `qubes-gui-agent` working, it should be sufficient to start preparing a template VM.
|
||||
|
||||
### Xen libraries
|
||||
|
||||
Several XEN libraries are required for Qubes to work correctly. In fact, you need to make xenstore commands working before anything else. For this, Qubes git can be used as several patches have been selected by Qubes developers that could impact the activity inside a VM. Start be retrieving a recent git and identify how you can build a package from it: `git clone https://github.com/QubesOS/qubes-vmm-xen.git`
|
||||
Several Xen libraries are required for Qubes to work correctly. In fact, you need to make `xenstore` commands working before anything else. For this, Qubes git can be used as several patches have been selected by Qubes developers that could impact the activity inside a VM. Start be retrieving a recent git and identify how you can build a package from it: `git clone https://github.com/QubesOS/qubes-vmm-xen.git`.
|
||||
|
||||
Find the .spec file in the git repository (this is the file being used to build rpm packages), and try to adapt it to your OS in order to build a package similar to the target 'vmm-xen'. For example, a PKGBUILD has been created for [ArchLinux](/doc/templates/archlinux/) and can be found in the vmm-xen repository.
|
||||
|
||||
Don't be afraid with the complexity of the PKGBUILD, most of the code is almost a copy/paste of required sources and patches found in the .spec file provided in the git repository.
|
||||
|
||||
Note once the package has been successfully compiled and installed, you need to setup XEN filesystem. Add the following line to your fstab (you can create this line in your package install script): `xen /proc/xen xenfs defaults 0 0`
|
||||
Note once the package has been successfully compiled and installed, you need to setup XEN filesystem. Add the following line to your fstab (you can create this line in your package install script): `xen /proc/xen xenfs defaults 0 0`.
|
||||
|
||||
Now install the package you built and mount /proc/xen. Verify that xenstore-read works by running: `xenstore-read name` That should give you the current name.
|
||||
Now install the package you built and mount `/proc/xen`. Verify that xenstore-read works by running: `xenstore-read name`. That should give you the current name.
|
||||
|
||||
### Qubes-OS core agents (qrexec...)
|
||||
### ArchLinux example PKGBUILDs
|
||||
|
||||
[https://aur.archlinux.org/packages/qu/qubes-vm-core/PKGBUILD](https://aur.archlinux.org/packages/qu/qubes-vm-core/PKGBUILD)
|
||||
Qubes OS core agent (qrexec...) - [https://aur.archlinux.org/packages/qu/qubes-vm-core/PKGBUILD](https://aur.archlinux.org/packages/qu/qubes-vm-core/PKGBUILD)
|
||||
|
||||
### Qubes-OS kernel modules
|
||||
Qubes OS kernel modules - [https://aur.archlinux.org/packages/qu/qubes-vm-kernel-modules/PKGBUILD](https://aur.archlinux.org/packages/qu/qubes-vm-kernel-modules/PKGBUILD)
|
||||
|
||||
[https://aur.archlinux.org/packages/qu/qubes-vm-kernel-modules/PKGBUILD](https://aur.archlinux.org/packages/qu/qubes-vm-kernel-modules/PKGBUILD)
|
||||
|
||||
### Qubes-OS gui agents
|
||||
|
||||
[https://aur.archlinux.org/packages/qu/qubes-vm-gui/PKGBUILD](https://aur.archlinux.org/packages/qu/qubes-vm-gui/PKGBUILD)
|
||||
Qubes OS GUI agent - [https://aur.archlinux.org/packages/qu/qubes-vm-gui/PKGBUILD](https://aur.archlinux.org/packages/qu/qubes-vm-gui/PKGBUILD)
|
||||
|
||||
@ -20,7 +20,7 @@ Qubes 4.0 is more flexible than earlier versions about placing different VMs on
|
||||
For example, you can keep templates on one disk and AppVMs on another, without messy symlinks.
|
||||
|
||||
These steps assume you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your HDD.
|
||||
See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-system-lvm-luks) if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the `-T` option on `lvcreate` to specify it is thin).
|
||||
See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-system-lvm-luks) if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the `-T` option on `lvcreate` to specify it is thin). You can find the commands for this example applied to Qubes at the bottom of this R4.0 section.
|
||||
|
||||
First, collect some information in a dom0 terminal:
|
||||
|
||||
@ -50,6 +50,45 @@ For example:
|
||||
|
||||
In theory, you can still use file-based disk images ("file" pool driver), but it lacks some features such as you won't be able to do backups without shutting down the qube.
|
||||
|
||||
#### Example HDD setup ####
|
||||
|
||||
Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
|
||||
|
||||
sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
|
||||
sudo blkid /dev/sdb
|
||||
|
||||
Note the device's UUID (in this example "b209..."), we will use it as its luks name for auto-mounting at boot, by doing:
|
||||
|
||||
sudo nano /etc/crypttab
|
||||
|
||||
And adding this line (change both "b209..." for your device's UUID from blkid) to crypttab:
|
||||
|
||||
luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6cde none
|
||||
|
||||
Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... and we can then create its pool, by doing this on a dom0 terminal (substitute the b209... UUIDs with yours):
|
||||
|
||||
First create the physical volume
|
||||
|
||||
sudo pvcreate /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
|
||||
|
||||
Then create the LVM volume group, we will use for example "qubes" as the <vg_name>:
|
||||
|
||||
sudo vgcreate qubes /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
|
||||
|
||||
And then use "poolhd0" as the <thin_pool_name> (LVM thin pool name):
|
||||
|
||||
sudo lvcreate -T -n poolhd0 -l +100%FREE qubes
|
||||
|
||||
Finally we will tell Qubes to add a new pool on the just created thin pool
|
||||
|
||||
qvm-pool --add poolhd0_qubes lvm_thin -o volume_group=qubes,thin_pool=poolhd0,revisions_to_keep=2
|
||||
|
||||
By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary HDD do the following on a dom0 terminal:
|
||||
|
||||
qvm-create -P poolhd0_qubes --label red unstrusted-hdd
|
||||
|
||||
|
||||
|
||||
### R3.2 ###
|
||||
|
||||
In dom0:
|
||||
|
||||
@ -93,4 +93,5 @@ Qubes Security Bulletins are published through the [Qubes Security Pack](/securi
|
||||
- [Qubes Security Bulletin \#40](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.txt) (Information leaks due to processor speculative store bypass (XSA-263))
|
||||
- [Qubes Security Bulletin \#41](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-041-2018.txt) (Speculative register leakage from lazy FPU context switching (XSA-267))
|
||||
- [Qubes Security Bulletin \#42](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-042-2018.txt) (Linux netback driver OOB access in hash handling (XSA-270))
|
||||
- [Qubes Security Bulletin \#43](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-043-2018.txt) (L1 Terminal Fault speculative side channel (XSA-273))
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user