It would be great to have this integrated into Qubes OS directly instead of a third-party script. People with threat models higher than average might be worse off if they do not manage to find this thread (or don’t know that this could help them). I for one need protection against forensics and this is integral to it, and I hope it is merged into Qubes OS as soon as the devs can.
3 Likes
Maybe just the simplicity of having @unman 's GUI install it, but I don’t see how that could be solved since this is a standalone script and not salted. Suppose if anything @ben-grande might consider working a varient up for Qusal.
1 Like
Agree, the new laptop generation with DDR5 and up to 96GB RAM shows that RAM should not be any issue for Qubes OS anymore (in the upcoming years).
Maybe it is worth to summarize some cons and pros of really disposable qubes vs. default disposable qubes ?
| Attribute | Disposable RAM qube | Default disposable qube | Comment |
|---|---|---|---|
| … | … | … | … |
| … | … | … | … |
It would be nice if devs put in some thoughts and also comment on a possible implementation effort.
3 Likes
I for one need protection against forensics and this is integral to it, and I hope it is merged into Qubes OS as soon as the devs can.
This tool was never aimed to be anti-forensic and it can’t be relied on as such. Details were explained previously in the thread.
2 Likes
It should, in theory. I haven’t managed to comment that proves it otherwise (sorry, would be great if you could point towards it), but having a VM which is completely ephemeral, and run on encrypted, plausibly deniable storage for assets it needs access to, will make them a part of good security posture for individuals who need them.
It’s essentially akin to the live-images of most desktop distros and how they don’t leave any trace after shutting them down.
2 Likes
It should, in theory.
Well, it actually does in practice but that is a partial side effect, not essential functionality, i.e. a non-goal. Partial = it removes the domU itself but traces of its existence remain in dom0’s logs due to how the whole system works. Additionally, the safety of domU’s erasure depends on how the RAM-based disposable is shut down. If you initiate a system reboot/shutdown while the qube is running, the cleanup part won’t work (hence one of the additional scripts).
1 Like
Anti-forensics on Qubes is not easy. Especially with our suboptimal logging system.
2 Likes
Thank you for that, it is very relevant to know that.
1 Like
@qubist i just see that some qubes that i’ve deleting are still in ~/.local/share/qubes-appmenus/ .
Do you have the same problem like me?
It’s ok for rdispxxxx but not for the others…
edit: in the vm’s folder, i still have “apps” “apps.icons” “apps.tempicons” and “apps.templates” folders.
edit 2: forget it, i try to create other vm, them remove it and all is allright 
i think it’s when i restore Dom0 without use your script 
1 Like
No. I don’t see any rdisp* or named RAM-based disposable names in there.
Have you tried deleting the manually and checking if they would reappear?
1 Like
Nice script. I took interest in the example:
EXAMPLE:
Launch Tor browser in a RAM based whonix disposable:
${0##*/} -p template=whonix-ws-16-dvm -p netvm=sys-whonix -c torbrowser
Tor protocol encapsulation is handled inside the sys-whonix gateway, not the workstation. Meaning that sys-whonix could potentially leak cleartext request/response data (page content, passwords, etc. if the connection isn’t using TLS, SNI leakage for TLS) from the disposable to disk through swap or coredumps. I’m not sure if Whonix gateway retains other data like logs, cache files, etc.
The Whonix wiki explicitly discourages using a disposable gateway, so I hesitate mitigating the leak that way. Is disabling swap and coredumps in sys-whonix enough?
qvm-run -p sys-whonix "sudo swapoff --all; sudo sysctl -w fs.suid_dumpable=0; sudo sysctl -w kernel.core_pattern='|/bin/false'"
1 Like
Is disabling swap and coredumps in sys-whonix enough?
There is no such disabling.
The script disables swap in dom0 to prevent disk writes. It touches nothing inside any other qube. It will not put your netvm in RAM, only the AppVM you are creating resides there.
1 Like
Like as i say in my edit 2 : i try it and they disappear all is ok
1 Like
Like as i say in my edit 2 […]
Sorry, I don’t receive edits. I use the forum by email.
2 Likes
Thank you for the wonderful script! You did an excellent job. It works perfectly
3 Likes
This is a reply to @ben-grande regarding this comment:
[…] there are many things to consider:
- it is a shellscript, Qubes OS prefers python
More things to consider:
- prefers != mandates (IIUC)
- it is a work in progress thing. I will post a new version when ready. I am months late with so many things due to serious health issues but at least I am alive.
- While I have a (rusty) C/Assembly/others background, I still don’t “speak” Python. Shame on me.
- for the particular task, I don’t quite see the benefits of Python (and I admit the reason may be my lack of expertise)
- shell script is in every distro, out of the box, even minimal. The same largely applies to Python, especially considering Qubes OS. However, if some day in the distant future Python becomes no longer so preferred, or if dom0 finally gets proper minimisation, it may turn out that the bash version is more suitable (just a speculation)
- it uses a blocklist, adding a new log file to the system would be a cat and mouse game, the proper way would not save those files in non tpmfs in the first place
What do you call a “blocklist”?
- there are no unit or integration tests
Because it was never planned to become an integral part of the system. If there is such plan, that might become an actual (sub)project with proper design and structure.
- a live system would be much better to guarantee that nothing is ever written to disk
Unless I am missing something, the only thing that is written to persistent storage are the logs. Qubes OS is simply not designed to guarantee any non-logging, so if there is any expectation for the opposite, it must be addressed at the OS level, not at the level of a component.
I welcome any further comments which may improve this micro project.
Thank you for your feedback!
4 Likes
Friend, I wish you robust health! Thank you for the guides you create!
In fact, Qubes, like any other Linux, normally boots in an overlayfs using the standard dracut modules that work on all Linux systems and launch the root in tmpfs. One of those modules is published here Qubes in tmpfs 🤫 - #86 by linuxuser1. I’ve also tested several other modules from GitHub - it all worked in Qubes. The dom0 logs are completely erased. The entire system operates with amnesia when installing Qubes with Btrfs.
If you decide to make DVMs resistant to forensic analysis, you can improve or simplify the solutions for a dom0 live in ZRAM (a dom0 running in tmpfs requires a lot of RAM, but this approach with ZRAM significantly reduces memory consumption, and even systems with 16 GB of RAM work well with DVMs and AppVMs in live mode).
However, you don’t pursue the goal of protection against forensic. Therefore, your solution is very good. I constantly use it whenever I need to run a browser in persistent mode.
3 Likes
Because the script needs to know which files to remove, so enumeration.
You cannot be sure of that on a non-live system. Check if new files are created on /etc/lvm/archive when you run the script.
Also, what happens with the cleanup on sudden shutdown of the computer? I don’t see it handling emergency shutdown. A sudden shutdown doesn’t send TERM signal.
There is an Python Admin API , every qvm-* tool you are calling is already using it. If you use it directly, you could establish some parameters and functions that would make the creation of ephemeral pools and qubes natively, reaching a pint where you could do qvm-create --ephemeral ... and everything would be handled by qubesd.
- The command-line tools you are using is another abstraction on top of the Python API.
- If an ephemeral option was implemented directly in the backend, it would prevent log files from being written to disk with an if clause.
- No need to assume the user can run privileged commands with sudo, qubesd runs as root
- No need to reinvent property parsing
- Event handlers, you may see a short bit about it at my presentation at the summit this year
- There are more benefits than what I can list now
1 Like
Thank you!
However, you don’t pursue the goal of protection against forensic.
I just don’t think it is appropriate to even attempt to address this issue at the level of such a script. It must be addressed at a deeper/lower level for more serious threat models.
FWIW, on my system the dom0 journal is volatile. If you use this and considering the log files for the RAM-based VMs are erased too, it is pretty much anti-forensic. Disclaimer: not at the level of “I have an electronic microscope and it shows more than you can see”.
Because the script needs to know which files to remove, so enumeration.
You are right. Unfortunately, there is no mechanism (that I know of) to say “I don’t want logs for this qube”, so the way the script works is simply a workaround for this.
Check if new files are created on
/etc/lvm/archivewhen you run the script.
Grepping, I can see names of non-longer-existing RAM qubes. That, however, is not really much info (compared to what happens inside the qube). So, yeah… threat model, depth…
Also, what happens with the cleanup on sudden shutdown of the computer? I don’t see it handling emergency shutdown. A sudden shutdown doesn’t send TERM signal.
I am working on better handling of this. However, nothing can prevent a forceful process killing, hence the additional helper script.
BTW the same question applies to conventional disposables, no?
Thanks for the additional info!
2 Likes
Yes, your tool handles this well. It’s better than the default dvm. For example, the original Whonix has a live mode. But why add a live mode to VM if the host is in persistent mode? And the host could be Windows. The answer is simple - it’s better than not having such a tool at all. And it will wipe everything on the virtual disk. So I always include your tool in the list of solutions for anti‑forensics in Qubes:
Qubes dom0 ZRAM Live Mode
Qubes dom0 OverlayFS Live Mode
Really disposable (RAM based) qubes
By the way, kicksecure and Whonix appVMs with live‑mode support may appear soon Live mode in Qubes 4.3? - Qubes - Kicksecure Forums