When I mount a container in Live Mode it breaks the live check. Like explained with snapd in the link below, the container is mounted with 0 (read-write) ## kicksecure.com/wiki/Grub-live#Technical_Details_of_livecheck.sh
It states If anything in coloumn RO is set to 0, then it is not blessed read-only hard drive mode.
This means snapd or any other mounted containers in a READ ONLY Live Mode session with a 0 actually do write on the disk? I think this is unclear in the documentation
That is not the issue. If you start Live Mode with virt-manager set as read-write and create a file it’s gone after rebooting too. But it still has been written to the disk. I’m not a forensic analyst which is able to recover and check this traces
Ok that was a test with a default file. But it is no answer to my initial question. In my question I was speaking about a container that gets mounted as 0. According to the documentation this container is read-write. If you read the documentation now it looks like snapd or other containers write to the disk even when you boot the VM in Live Mode with Read Only enabled.
About the “basic” test. When I reboot, the container is unmounted. So the files are not there. I have no idea to check if it has ever written the files to the disk or a small part of it.
Patrick could you please clarify if mounted containers in a Live Mode session with Read Only enabled actually do write on the disk or not? Since they get marked as 0.
Without answer on this question I sadly can’t use Whonix
Edit:
I’m going to do a raw disk backup check now. But please could you answer me in advance
I am not aware of any software that uses remount to turn the read-only disk to read-write. Could it theoretically exist, yes? With snap, I’ve tested to create a file in the snap folder (where not read-write protected). It was gone after reboot.
As far as I understand it, the loop device is read-write but it’s backend is on a presumably read-write disk but that’s just the overlay in the RAM.
I’ve installed a snap before booting into live mode to make sure the container exists after reboot. Then booted into live mode, created a file and rebooted again. You can find the folder using sudo mount.
The loops are actually are shown as RO 1 (read-only), see sudo lsblk, which is weird.
If you’re looking for warranties, you’re not going to get them from anyone without corporate level expenses.
What can be said: “Nobody could show that any files persist yet.” It’s hard to make stronger claims than that.
If you want stronger assurances for yourself by yourself then that’s only through a The User Co-developer Concept mindset, through the image comparison test.
This actually showed me that more musings on the security of any live mode in any live mode systems can be written…
If you want to learn more how much reliablity, security can be expected, which steps users can take to attain higher security, see this (also written just now): Security Considerations
That won’t really test if VM live mode HDD boot with read-only VM hard drive writes right? And if there is a different checksum it could be a lot of other stuff like cache or logs that might have written? I don’t see how your reference with the associated documentation is the answer for me how to test amnesic in my case. It might be me…
Thank you for expending the documentation! I would love to see a Live ISO and a more upstream hardened kernel. I’m considering to fund it in the future since I’m not able to contribute in other ways. For now I’m discovering everything
These instructions are pretty much generic except if you do inside the VM, then well, you do it inside the VM instead of the host operating system.
Boot into live mode from the VM’s internal storage.
Launch some applications and carry out a spectrum of regular user tasks.
Unfortunately you cannot record the hashsum of a VirtualBox .vdi, start a VM in live mode, record another hashsum of the .vdi and then compare the .vdis on the host operating system. I suspect VirtualBox is recording other metadata such as when the file was last opened.
Maybe possible with KVM .qcow2 files but untested.