Creating a Kali Linux TemplateVM

[taradiddles]

Warnings

• The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
• Adding additional repositories or tools for installing software extends your trust to those tool providers.
• Please keep in mind that using such a template for security and privacy critical tasks is not recommended.
• Kali Linux distribution is a rolling distribution based on Debian testing release, so it will always have a newer software base than available in the Qubes OS Debian template. Keep in mind that this may result in problems (especially in regard to package dependencies) not covered by this tutorial.

From the official ISO file

Only use this method if you want the full Kali GUI (desktop, fancy menus, etc.). It comes at the cost of much greater resources consumption.

1. Download the Kali ISO
2. Create a new HVM
3. Start the HVM with attached CD/DVD

$ qvm-start <hvm-name> --cdrom <vm-name>:/home/user/Downloads/<iso-name>.iso

From a Debian template

This is the recommended method. Easier to maintain and less demanding on resources, but you won’t have the full Kali GUI.

If you need to install custom kernel modules (wifi drivers, …) you need to use the kernel provided by Kali instead of the kernel provided by Qubes, see Managing VM Kernel.

The steps can be summarized as:

1. Install Qubes stable Debian template
2. Upgrade from Debian stable to Debian testing for Qubes repositories
3. Add testing and securitytesting Qubes repositories
4. Replace the content of /etc/apt/sources.list file with the Kali repository
5. Update the template

Get Kali Linux PGP key

CAUTION: Before proceeding, please carefully read On Digital Signatures and Key Verification. This website cannot guarantee that any PGP key you download from the Internet is authentic. In order to obtain a trusted fingerprint, check its value against multiple sources. Then, check the keys you download against your trusted fingerprint.

This step is required since by (security) default TemplateVM do not have a direct Internet connectivity. Users understanding the risks of enabling such access can change this configuration in firewall settings for the TemplateVM.

1. Retrieve the Kali Linux PGP key using a DisposableVM.

$ gpg --keyserver hkps://keys.openpgp.org --recv-key 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
$ gpg --list-keys --with-fingerprint 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
$ gpg --export --armor 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6 > kali-key.asc

2. DO NOT TURN OFF the DisposableVM, the kali-key.asc file will be copied in the Kali Linux template for a further step.

3. Make sure the key is the authentic Kali key. See the Kali website for further advice and instructions on verification.

Create a Kali Linux (rolling) template

These instructions will show you how to upgrade a Debian TemplateVM to Kali Linux.

1. (Optional) Check for latest Debian stable template and install it (if not already done)

# qubes-dom0-update --action="search all" qubes-template-debian
# qubes-dom0-update <latest Debian template>

2. Clone debian-X template

$ qvm-clone debian-<X> kali-rolling

3. Check the name of currently used repository in /etc/apt/sources.list.d/qubes-r<X>.list and current testing Debian release. Update repository list accordingly

# sed -i 's/<current stable>/<current testing>/g' /etc/apt/sources.list.d/qubes-r<X>.list

e.g. in this example we update bullseye stable repository to bookworm testing repository

# sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list.d/qubes-r<X>.list

4. Enable the QubesOS testing and securitytesting repositories

In /etc/apt/sources.list.d/qubes-r<X>.list, enable the testing and securitytesting repository. We do that to reduce the ‘dependency hell’ between Qubes repository and Kali repository.

5. Copy the Kali PGP key from the DisposableVM to the new template:

$ qvm-copy kali-key.asc

The DisposableVM can now be turned off.

6. Add the Kali PGP key to the list of keys trusted to authenticate packages:

# cd /home/user/QubesIncoming/dispXXX && gpg --dearmor kali-key.asc
# cp kali-key.asc.gpg /etc/apt/trusted.gpg.d/kali-key.gpg

7. Replace Debian repositories with Kali repository

# echo 'deb https://http.kali.org/kali kali-rolling main non-free contrib' > /etc/apt/sources.list

8. Replace conflicted packages to work around dependency issues

# apt-get remove <existing_package> && apt-get install <required_package>

e.g. in this example we replace gcc8 with gcc6

# apt-get remove libgcc-8-dev && apt-get install libc6-dev

Note: This kind of dependency issue will pop up and disappear without notice. Such issues arise because of the differences of dependencies in packages from the Kali repository, the Qubes testing repository and the Debian testing repository. So this step [step 8] is currently needed. But it will not always be the case.

9. Update the template

Note: During execution of the update, carefully read list of packages to be removed. If it contains qubes-vm-dependencies package, terminate operation and try to resolve missing dependencies first. For other qubes-* packages, it is up to you to decide if you need them.

10. Ensure a terminal can be opened in the new template.

$ qvm-run -a kali-rolling gnome-terminal

Install the Kali tools

At this point you should have a working template and you can install the tools you need. You can find a list of Kali Linux Metapackages here Keep in mind that the tools you will install can easily take more than 10 GB, so you will need to grow the size of the VM system storage.

Fix Qubes PulseAudio (audio and microphone)

Installing the kali-defaults package (which is included in many Kali metapackages including kali-linux-core) causes Kali PulseAudio configurations files to be installed that interfere with what Qubes provides. This breaks audio and microphone throughput for that qube.

To fix this, simply do one of the following in the Kali Linux TemplateVM:

Remove just the conflicting PulseAudio configuration files

1. Remove the configuration files by running the following command:

# rm /usr/lib/systemd/user/pulseaudio.service.d/kali_pulseaudio.conf /usr/lib/systemd/user/pulseaudio.socket.d/kali_pulseaudio.socket.conf

Uninstall the entire kali-defaults package

1. Assess the function and contents of the package to see if you need it:
   • See description: apt show kali-defaults
   • See installed files: dpkg -L kali-defaults
2. If you determine that the package is unnecessary, then uninstall it
   • sudo apt remove kali-defaults

Finally, for both of these options, the Kali Linux qube will have to be restarted for these changes to take effect.

Alternative Options to Kali Linux

• PenTester Framework, with PTF Qubes OS guide
• BlackArch Linux, with BA Qubes OS guide
• more on the Penetration Testing page

Notes

Thanks to the people in the discussion thread.

---

This document was migrated from the qubes-community project

• Page archive
• First commit: 08 Dec 2020. Last commit: 15 May 2022.
• Applicable Qubes OS releases based on commit dates and supported releases: 4.0, 4.1
• Original author(s) (GitHub usernames): wand3rlust, taylorsmcclure, elliotkillick
• Original author(s) (forum usernames):
• Document license: GPLv2

[Eleanorrais]

I’m stuck at

9. Update the template

I have set /etc/apt/sources.list.d/qubes-r4.list to

# Main qubes updates repository
deb [arch=amd64] https://deb.qubes-os.org/r4.1/vm trixie main
#deb-src https://deb.qubes-os.org/r4.1/vm trixie main

# Qubes updates candidates repository
deb [arch=amd64] https://deb.qubes-os.org/r4.1/vm trixie-testing main
#deb-src https://deb.qubes-os.org/r4.1/vm trixie-testing main

# Qubes security updates testing repository
deb [arch=amd64] https://deb.qubes-os.org/r4.1/vm trixie-securitytesting main
#deb-src https://deb.qubes-os.org/r4.1/vm trixie-securitytesting main

Running

apt update

Gives me

Ign:1 https://deb.qubes-os.org/r4.1/vm trixie InRelease
Ign:2 https://deb.qubes-os.org/r4.1/vm trixie-testing InRelease
Ign:3 https://deb.qubes-os.org/r4.1/vm trixie-securitytesting InRelease
Err:4 https://deb.qubes-os.org/r4.1/vm trixie Release                      
  404  Not Found [IP: 127.0.0.1 8082]
Err:5 https://deb.qubes-os.org/r4.1/vm trixie-testing Release              
  404  Not Found [IP: 127.0.0.1 8082]
Err:6 https://deb.qubes-os.org/r4.1/vm trixie-securitytesting Release
  404  Not Found [IP: 127.0.0.1 8082]
Hit:7 https://mirror.serverius.net/kali kali-rolling InRelease
Reading package lists... Done
E: The repository 'https://deb.qubes-os.org/r4.1/vm trixie Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'https://deb.qubes-os.org/r4.1/vm trixie-testing Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'https://deb.qubes-os.org/r4.1/vm trixie-securitytesting Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled 

Checking https://deb.qubes-os.org/r4.1/vm/dists also gives no entry for trixie or trixie-testing, which I would have expected. I believe this is giving me the issues of not being able to update.

[Eleanorrais]

I just read unmans post on another topic that the recommended way is to get their latest template from Index of /Templates. I am pursuing that step now, as my goal is to use Kali with the least hassle.

[pizzaMaker]

The Kali repository signing key included in the Kali Template has expired, leaving the template unable to update without bootstrapping a fresh key as described here.

Migrating the keys from a disposable template leads to an error message from qvm-copy. (unknown error -493906718). Importing the kali key directly on the template functions appropriately, but cuts against how qubes works for security. I am assuming the risk in the name of functionality.

As Testing is much closer to Debian 12 instead of the Debian 11 included in the kali template, I am hoping to rebase this to Debian 12.

Replacing ‘bullseye’ with ‘bookworm’ in /etc/apt/sources.list and in sources.list.d/qubes-r4.list is simple enough.

apt update && apt upgrade debian-archive-keyring && apt full-upgrade

Wish me luck!

My other option:

is to use the debian-12-minimal template, as 12 (bookworm) is the freshest in the repository, and not upgrading to Trixie (current debian testing). The fork between the bookworm and trixie is recent enough (~1month) for compatibility, but still allows updating to the kali packages.

It also lacks the libgcc-[version]-dev package, and any others that create an incompatibility detected by apt upon trying to install the ‘kali-linux-everything’ metapackage.

I am working through a few other issues from building upon a minimal template. but it is a solid backup choice. I have a debian-12-minimal template migrated over to the kali packages where possible, kept in reserve in case the template-upgrade fails.

[pizzaMaker]

Using the existing Kali template now, rebased to use the Debian-12 resources.

There were a few hiccups such that it wasnt entirely an unattended upgrade process. Apt itself provided the guidance regarding newly-broken packages.

I count myself lucky to have upgraded in place this way.

[Eleanorrais]

I solved this issue by replacing R4 sources with bookworm and activating bookworm-testing.
So the proposed example from step 3 and go to bookworm instead of trixie.