Disposable VMs and Local Forensics on qubes R4.0 context

[Carl53]

Qubes OS version:

R4.0

Affected TemplateVMs:

Documentation

Steps to reproduce the behavior:

Go to page:
https://www.qubes-os.org/doc/dispvm/#disposable-vms-and-local-forensics
or
https://www.qubes-os.org/faq/

Expected behavior:

Information about how next Qubes version relate with this 2013 issue:

https://www.qubes-os.org/doc/dispvm/#disposable-vms-and-local-forensics

https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4/discussion

Actual behavior:

There is no information

[andrewdavidwong]

My understanding is that the documentation is still accurate, since nothing has changed to make Disposable VMs any more (or less) resistant to local forensics. @marmarek, is this correct?

[andrewdavidwong]

My understanding is that the documentation is still accurate, since nothing has changed to make Disposable VMs any more (or less) resistant to local forensics. @marmarek, is this correct?

[Carl53]

I cant find but remember reading something on Qubes site telling about more flexible mount mechanics that will make possible mount memory volumes, i remember was Joanna Rutkowska that wrote and was telling exactly about this old topic, was something like a changelog, i remember was talking too about XEN independence.

[Carl53]

I cant find but remember reading something on Qubes site telling about more flexible mount mechanics that will make possible mount memory volumes, i remember was Joanna Rutkowska that wrote and was telling exactly about this old topic, was something like a changelog, i remember was talking too about XEN independence.

[vincentadultman]

From what I remember the discussion progressed quite a bit past the initial post in that mailing list thread, continuing with much useful discussion in #904 Many other issues linked from that earliest one touch on related problems & requests (e.g. ram wiping on shutdown).

I do think where there is an open long running / help-wanted issue specifically discussing implementation of something the docs has an entry for, the issue could be referenced from the docs, @andrewdavidwong how do you feel? I don't see this would add weight to doc maintenance as an implemented new feature would need a doc edit / new page once fully implemented anyway.

From a technical writing perspective, for this question we could perhaps precis the long discussion of the issue? Relevant comments to include in a writeup seem to be:

VM Memory is never written to disk, however screen contents, audio and keystrokes will be potentially written to swap in dom0.
The dispvm filesystem Volatile.img are held on disk
To address both points, file systems can be configured for swap and for volatile.img to live on that are encrypted with disposable keys.
gists exist implementing the disposable encrypted swap / storage filesystems
https://gist.github.com/v6ak/d5d49375d59cfae8e455
I'm sure I've also seen one by someone other than Vik, but can't find it right now.
Storage pools for 4 will change this somewhat?

A point of order seems to be the comment by Marek "It's hard to handle the key in dom0 and be sure it didn't land in swap" - unsure if this refers to the approach above (dom0 swap is setup random key encrypted at boot) or the in-vm crypto / crypto-vm also discussed?

The problem currently is that a new user sees the brief reference, in a small percentage of cases spends some time reading the issue(s) understanding them for a given value of "understanding" only, then comes to mailing list or IRC and gets potentially dangerous advice, I'd rather expand the "canon" answer such that there is a "tight" description of the problem, an indication as to what is currently possible and as importantly, what remains a challenge.

On a related point, while this issue refers to 4, I'd quite like to add to the docs page description of what "keep dispvm in memory" means in 3.2 and perhaps even change the label in Qubes Manager to read "keep dispvm save-file in memory". Is this welcome? I know the question has come up at least a few times, which means to me that far more than just those people are misunderstanding...

[vincentadultman]

From what I remember the discussion progressed quite a bit past the initial post in that mailing list thread, continuing with much useful discussion in #904 Many other issues linked from that earliest one touch on related problems & requests (e.g. ram wiping on shutdown).

I do think where there is an open long running / help-wanted issue specifically discussing implementation of something the docs has an entry for, the issue could be referenced from the docs, @andrewdavidwong how do you feel? I don't see this would add weight to doc maintenance as an implemented new feature would need a doc edit / new page once fully implemented anyway.

From a technical writing perspective, for this question we could perhaps precis the long discussion of the issue? Relevant comments to include in a writeup seem to be:

VM Memory is never written to disk, however screen contents, audio and keystrokes will be potentially written to swap in dom0.
The dispvm filesystem Volatile.img are held on disk
To address both points, file systems can be configured for swap and for volatile.img to live on that are encrypted with disposable keys.
gists exist implementing the disposable encrypted swap / storage filesystems
https://gist.github.com/v6ak/d5d49375d59cfae8e455
I'm sure I've also seen one by someone other than Vik, but can't find it right now.
Storage pools for 4 will change this somewhat?

A point of order seems to be the comment by Marek "It's hard to handle the key in dom0 and be sure it didn't land in swap" - unsure if this refers to the approach above (dom0 swap is setup random key encrypted at boot) or the in-vm crypto / crypto-vm also discussed?

The problem currently is that a new user sees the brief reference, in a small percentage of cases spends some time reading the issue(s) understanding them for a given value of "understanding" only, then comes to mailing list or IRC and gets potentially dangerous advice, I'd rather expand the "canon" answer such that there is a "tight" description of the problem, an indication as to what is currently possible and as importantly, what remains a challenge.

On a related point, while this issue refers to 4, I'd quite like to add to the docs page description of what "keep dispvm in memory" means in 3.2 and perhaps even change the label in Qubes Manager to read "keep dispvm save-file in memory". Is this welcome? I know the question has come up at least a few times, which means to me that far more than just those people are misunderstanding...

[andrewdavidwong]

I do think where there is an open long running / help-wanted issue specifically discussing implementation of something the docs has an entry for, the issue could be referenced from the docs, @andrewdavidwong how do you feel?

That would be fine. We already reference issues from the docs quite frequently.

The problem currently is that a new user sees the brief reference, in a small percentage of cases spends some time reading the issue(s) understanding them for a given value of "understanding" only, then comes to mailing list or IRC and gets potentially dangerous advice, I'd rather expand the "canon" answer such that there is a "tight" description of the problem, an indication as to what is currently possible and as importantly, what remains a challenge.

That strikes me as a worthwhile endeavor. I encourage you to submit a PR to this effect.

On a related point, while this issue refers to 4, I'd quite like to add to the docs page description of what "keep dispvm in memory" means in 3.2 and perhaps even change the label in Qubes Manager to read "keep dispvm save-file in memory". Is this welcome?

I, for one, would welcome clarification on that point.

[andrewdavidwong]

I do think where there is an open long running / help-wanted issue specifically discussing implementation of something the docs has an entry for, the issue could be referenced from the docs, @andrewdavidwong how do you feel?

That would be fine. We already reference issues from the docs quite frequently.

The problem currently is that a new user sees the brief reference, in a small percentage of cases spends some time reading the issue(s) understanding them for a given value of "understanding" only, then comes to mailing list or IRC and gets potentially dangerous advice, I'd rather expand the "canon" answer such that there is a "tight" description of the problem, an indication as to what is currently possible and as importantly, what remains a challenge.

That strikes me as a worthwhile endeavor. I encourage you to submit a PR to this effect.

On a related point, while this issue refers to 4, I'd quite like to add to the docs page description of what "keep dispvm in memory" means in 3.2 and perhaps even change the label in Qubes Manager to read "keep dispvm save-file in memory". Is this welcome?

I, for one, would welcome clarification on that point.