Links for tutorials
- This blog is the most accurate and detailed of all by
Simos Xenitellis
running-x11-software-in-lxd-containers - The documentation of kali iself kalilinux-lxc-images
To make this all work you need to use the base of the kali documentation and modify it regarding Simon blog above as there were changes recently in LXC/LXD which gives a bit of extra layer of fixes for some bugs.
This post is not a tutorial ,there are other people who has more accurate and detailed posts regarding this. What I set out to write about is some caveats and risk assessment ,which you need to be aware if you would like to use this solution. It is not suitable for most use-cases and if you have a beefy powerful hardware, where proper virtualization can be solved this is not your cup of tea. Full virtualization gives more level of security and as I will write about it later this LXC solution bring great security risks to the table, which most user are not aware.
In my case I am running a kali linux inside LXC on an Ubuntu host system. With this I have a separated environment for doing CTF,HTB,THM and some bug bounties in the future,but what cost. As you probably know this technology has no runtime like docker, you have access to kernel modules which loaded and in case you have unprivileged
container you won’t be able to load any kernel modules and if there’s any module version difference you will have a bad time, however if you create a privileged
container same as in docker you are giving full access to host which basically gives the one in the container straight root access to host and you will have full control over the kernel as well.
Regarding the sharing X11 and pulse audio, It does works efficiently as you can see below my ubuntu-mate desktop there is a xfce4-panel at the bottom which is running inside the LXC kali. However this solution causes sometimes pulseaudio and alsa device failure which can be solved with sudo alsa force-reload
. Other interesting thing that with xfce4-panel running the whole consumed memory in idle by the kali subsystem is ~150MB
. There is an interesting bug regarding starting the xfce4-panel. For some reason with recent lxd versions starting xfce4-panel does not works ,which is why I had to use a hacky solution to create a small shell script which I start in background after the lxc starts up. Which solves almost all problems especially theme issues , with this all application running inside lxc-kali is using the kali-dark theme ,so it’s easy to distinguish.
#!/bin/bash
env GTK_THEME=Kali-Dark dbus-run-session xfce4-panel &
As you can see in my case the real bottleneck was the GPU all along, which makes it almost useless in full virtualization. That is the only reason I am using this type of workflow.