Maybe use shred or wipe to delete logs? That would make your script truly antiforensic
Maybe use
shredorwipeto delete logs? That would make your script truly antiforensic
Without firmware access, effective file-level shredding is simply not possible on SSD due to the way hardware works. If you look at the script, you will see it does something (IMO) better:
# Create void symlinks to prevent log saving
for file in "${logfiles[@]}"; do
sudo ln -sfT /dev/null "${file}"
done
I.e. no logging actually occurs (even to RAM). The only persistent info that remains is the metadata trace of the erased symlink name on the filesystem. With an encrypted storage, non-revealing VM names (like “my_password_is_helloworld”) and volatile dom0 journal, that seems to me quite insignificant, even for a paranoid who is scared of an adversary being able to unlock encrypted storage, inspect the filesystem, find the erased metadata remnants and from that act.
Unfortunately, for e.g. /var/log/qubes/guid.abc1234.log, the link gets overwritten with an actual file by the system upon abc1234 start but even so I don’t see any forensic data in that file.
root@dom0:~ # cat /var/log/qubes/guid.abc1234.log
Icon size: 128x128
If you see any significant traces remaining anywhere else, please let me know.
6 Likes
@qubist Hello. Your RAM qubes will stop working if file driver and varlibqubes are removed from version 5?
I’d like to reiterate that there is a better path towards anti-forensic DisposableVMs:
People might want to focus their energy on generalizing the already existing Qubes OS support for ephemerally encrypted ‘root’ volumes to ‘private’ volumes, which would entail something like the WIP in marmarek/qubes-linux-utils@
volatile-thin-poolfrom, oh wow, 2016. That’s a much cleaner approach to anti-forensic DisposableVMs (#904) than creating and tearing down pools.
More generally, from #904:
The storage layer already has generic support for encrypting a volume with an ephemeral key. In the context of this issue, the problem is that this not implemented for
snap_on_startvolumes like the ‘root’ and especially the ‘private’ volume of a DisposableVM. (For the ‘root’ volume the existing workaround is to set it as read-only, rely on in-VM support to redirect writes to it to the ‘volatile’ volume, and make the non-snap_on_start‘volatile’ volumeephemeralinstead of ‘root’. But there is currently no such in-VM support for the ‘private’ volume.)
Solving the bold part - not necessarily by using exactly the same implementation as in the linked WIP code! - would solve anti-forensic DisposableVMs.
That said, in order to avoid the ‘file’ driver it would also be possible to adapt this thread’s script to create a throwaway Btrfs/XFS filesystem (maybe even on disk, encrypted with a random key) and then use the file-reflink driver for the temporary pool.
1 Like
Currently, the script uses what the existing Qubes tools allow. If something changes, then we will follow and adapt. Ideally, the dev team will actually provide RAM-based qubes out of the box in next versions.
I remember that comment of yours but I am quite hesitant about experimenting in my dom0 as I don’t have a separate testing system. If @marmarek has not made that part of the official OS for so many years, he probably has good reasons for it.
1 Like
Could you write the code and publish it on GitHub or in a guide on a forum? 
Your idea is really cool, and it doesn’t require much RAM.
It seems to me that this won’t happen. Devs are not interested in protecting against forensic. It only benefits the community.
It is very interesting
Oh I’m almost certain a clean implementation of the write diversion mechanism for ‘private’ volumes, like the existing one for ‘root’ volumes, would be accepted with open arms and merged. It’s just that nobody’s gotten around to it, including me.
My first post here, and I am sorry if this has already been discussed but I like this comment: DisposableVMs: support for in-RAM execution only (for anti-forensics) · Issue #904 · QubesOS/qubes-issues · GitHub
FWIW, I really like the idea of encrypting volatile.img with a one-time key and then throw it away after the DispVM shutdown. Can we ensure the dm will never write the key to dom0 fs anywhere? Do we need to disable swap in dom0 for that?
There was another post here about running Qubes-VMs from a second encrypted SSD
hmm… and then wiping that partition? Seems better than the whole dom0 LIVE based approach which to me is overkill.
Qubes OS uses cryptsetup --key-file=/dev/urandom for this, which handles marking this kind of sensitive memory as not to be swapped out.
Thinking outside the box
Just a thought…on a second ssd: Dedicated thin-pool for dispvms + wipe pool on shutdown
1.Create a thin-pool for disposables
2. Tell Qubes to place DispVM volatile.img /private volumes in this pool/ Create a storage pool in Qubes that points to the LVM thin-pool.
3. Route Disposable volumes to the new pool
4. Wipe the thin-pool on shutdown with blkdiscard / dd single pass to 0 /trim…
Advantages being simplicity, physical isolation (dispVMs don’t touch the main pool), no need to make any modifications to templates etc.
But I still really like the idea of encrypting volatile.img with a one-time key and then throw it away after the DispVM shutdown. That seems simple and elegant.
It seems to me that this won’t happen. Devs are not interested in protecting against forensic. It only benefits the community.
Then the community should rather try to convince devs than ask another community member to do what the OS is not designed to do 
Could you write the code and publish it on GitHub or in a guide on a forum?
What code? Which idea?
It isn’t intended for many things - for example, gamers, but some users manage to run games successfully. And your ram solution works great.
I’m talking about idea of encryption using an ephemeral key that @rustybird mentioned.
I’m talking about idea of encryption using an ephemeral key that @rustybird mentioned.
The pools created by the script currently use --option ephemeral_volatile=True.
There was another post here about running Qubes-VMs from a second encrypted SSD hmm… and then wiping that partition? Seems better than the RAM based approach which to me is overkill.
This thread is about the RAM-based approach. Its goals are:
- to reduce the unnecessary SSD writes of disposable data
- faster r/w inside the RAM-based VM
Writing to SSD and “wiping” the written data is:
- impossible due to how SSD hardware works and doubles SSD writes (an actual overkill)
- much slower than r/w to RAM
=> opposite to the goal.
4 Likes
HI @qubist
Maybe this is a stupid question because of my lack of knowledge on how Linux & VMs work
But why is it that, if I delete files in the disposable qube, it is not reclaimed in the pool?
Running your monitor script, it shows me that the ram_pool* and private pools’ usage keep increasing, until it hits 100% and the qube crashes; they never decrease, even if I delete files within that qube.
Is there any way I can make it reclaim space?
Thanks
EDIT: Mmm, maybe this is related? [solved] When is Disk Space Returned to the Thin Pool after Deleting Data in an AppVM? - #3 by f00
EDIT2: setting revisions_to_keep to 0 didn’t help
I see @apparatus explained in the linked thread:
“Maybe it’ll remove your old revisions after you shutdown the qube.”
However, in the particular case with RAM-based qubes, that is obviously not an option. So, I guess the answer is just make sure your pool is big enough.
I am not an expert on the inner workings of pools.
That’s a shame. I wanted to set the qube up for a long-running task that involves downloading/uploading, so no matter how big the pool is, it will eventually crash.
I’ll keep trying to find a solution.
@apparatus please let us know if you have a way to mitigate this!
Thanks