Good morning,
I have an IncusOS cluster with OVN set up to provide “isolated” networking for each of my Incus Projects.
Because IncusOS is relatively new, I am just double-checking that I haven’t missed anything or that there isn’t any known VM-escape vulnerabilities.
Since OVN networks are “isolated” from each other (as much as virtual networks can be) and Incus Projects give another layer of isolation, are the risks of VM-escape higher than other virtualization options?
My current plan:
- Create a new project solely for analysis
- Use a USB-to-Ethernet NIC, directly attached to the analysis box (This specific project wouldn’t be OVN)
- Assign that NIC it’s own subnet, isolated from the rest of the network, only able to talk to the internet
- I should still have access to the VM through the default management interface (Incus CLI / WebGUI), but the VM shouldn’t know it exists
- Set the Project to isolate images, profiles, networks, network zones, storage buckets, and storage volumes
- Set the Project to limit all resources to the minimum necessary for the analysis setup
- Set the VM resource limits to the minimum to run the OS
Other than that, everything else would be default settings.
The one thing that I think could be an issue is /dev/incus, since that’s the connection to the management interface. If I wanted to disallow that, I would have to set up FTP, SSH, or some other form of control for the analysis machine.
My questions are:
- Is there any hardening that is IncusOS-specific that I might have missed?
- What kind of access does a VM have to
/dev/incus?
- Are there any known VM-escape issues? Since IncusOS is immutable, there isn’t any ‘persistence’ malware could gain, so I can reboot the physical machine after an analysis out of caution.
Just as a little aside: I’m a cybersecurity analyst but my specialty is digital forensics and incident response (DFIR). My work’s malware analyst has CAPE set up, but I want to build a malware analysis sandbox for personal research and to get better at investigating real malware in different environments and operating systems. I have a background in cybersecurity, but not specifically malware analysis.
Hi NocturnalDanger,
I am in no means an expert on this, but as part of my master thesis I am currently heading in a similar direction as you: I want to use incus to host capture the flag challenges. Since inside those challenges, random users will be able to do whatever they want, explicitly allowing root access and kernel exploits within the VM, this involves probably about the same level of hardening/correct configuration as your threat model.
Currently unknown kernel exploits and container escapes (0 days) aside, based on the documentation I am kind of confident that incus (linux containers/VM) should allow for all the needed separations.
I draw a lot of this confidence from those two things:
- According to the documentation, unprivileged incus (/lxc) containers are considered “safe”, because ”most security issues (container escape, resource abuse, …) in those containers will apply just as well to a random unprivileged user and so would be a generic kernel security bug rather than a LXC issue.” Linux Containers - LXC - Security
- They provide access to an incus VM to try it for everyone on the public internet
I found many security statements about containers, but (maybe I just have not found them yet!) not so many about VM.
To pick out one of your points, just because I have a vague feeling about this:
Based upon my absolutely unfinished readings of the documentation, inside the VM (at least in the default configuration of some? all? VM images) there is an incus thingy running, that can communicate with the incus host. For example this thing enables `incus shell` and probably some other niceties. I don’t know yet if it really is mandatory, if this can be disabled easy or if it even is there for all images by default. So if something inside the VM wants to check if it is inside an incus VM, it might just probe for that thingy.
Also note that containers and VM (at least in their basic configuration) usually don’t really hide their existence. For example there is `systemd_detect_virt` and even if this is disabled, malware might (and some do) probe for typical signs of a container/VM (for example specific drivers or other system settings typical for VM) and adjust their behavior. Also restricting the machine too much might be a telltale: If the malware is blocked to access things that are usually allowed, it might just change its state to harmless. It’s a cat and mouse game.
I would be open to chat about our use cases 
And everyone reading this: I would be very happy to hear about things why incus container/vm might actually not be a good idea to host ctf instances.
Hey, this is less about the security but:
For your usecase, I think you might benefit a from forking Game of Active Directory.
Itll give you a decent starting point for your CTF.