Alright, so after your follow-up explanations, I think 3a is the best option for now.
Some more inline replies. Marek Marczykowski-Górecki: > On Mon, Sep 11, 2017 at 05:20:00PM +0000, Patrick Schleizer wrote: >>> 1. Allow starting default Disposable VMs from both Whonix Gateway >>> (sys-whonix) and Whonix Workstation (anon-whonix or other). This is the >>> default (if you don't modify policy for Whonix), but it's a very bad >>> idea, since such Disposable VM most likely will have access to clearnet >>> directly. > >> True. There would have to be a rule "default NetVM for whonix-ws based >> VMs AppVMs should always be a whonix-gw based ProxyVM". Doable? > >> That should be covered by 'Whonix default VM settings fixes - salt >> management' - https://github.com/QubesOS/qubes-issues/issues/1954 - >> which won't be available in time so we'll still need a solution 1-4 that >> you suggested? > >>> 2. Prevent starting Disposable VMs from any of Whonix VMs. This is safe >>> option, but also it limit functionality. > >> Yes, would be a very sad limitation of functionality. > >>> 3. Allow creating Disposable VMs based on anon-whonix, then allow only >>> such DispVMs be started from Whonix VMs. > >> Also quite limited in functionality. > >>> 3a. Similar, but create separate anon-whonix-dvm for that. Major >>> difference is that DispVMs based on anon-whonix-dvm will not have access >>> to private image of anon-whonix here. > >> If it's somehow possible, I'd like to avoid another template that needs >> to be separately upgraded. (If that would be the case?) > >>> 3a. Similar, but create separate anon-whonix-dvm for that. Major >>> difference is that DispVMs based on anon-whonix-dvm will not have access >>> to private image of anon-whonix here. > >> Yes, not too bad. > > "template" for DispVM is in fact an AppVM, not a separate TemplateVM. So, > it does not require separate TemplateVM. > > It's this way here: > > TemplateVM -> AppVM -> DispVM > > whonix-ws -> anon-whonix-dvm -> dispXXXX Great! >>> 3a. Similar, but create separate anon-whonix-dvm for that. Major >>> difference is that DispVMs based on anon-whonix-dvm will not have access >>> to private image of anon-whonix here. > >> Why not anon-whonix-disp being "simply" based on whonix-ws template? (I >> guess it's not advisable for some reason?) > > See above. > >>> 3a. Similar, but create separate anon-whonix-dvm for that. Major >>> difference is that DispVMs based on anon-whonix-dvm will not have access >>> to private image of anon-whonix here. > >> A Whonix DispVM having access to private image of anon-whonix doesn't >> seem good. As a user starting a DispVM to do some more risky action such >> as opening a pdf and links from an pdf, I would expect if that DispVM >> gets compromised, that it can not access any other data. > >>> Should the above be only about Whonix Workstation VM(s)? Whonix Gateway >>> have access to the clearnet anyway (at least in theory), so it's much >>> less important there. > >> Yes. > >> On a related note, a disposable Whonix-Gateway gets us closer to feature >> completion. A disposable Whonix-Gateway in combination with a disposable >> Whonix-Workstation would be more "Tails-alike". > > Hmm, in theory it should just work right now. You just need to have an > AppVM being a "template" for sys-whonix DispVM. > > Commands to setup it: > > qvm-create --class AppVM --label purple --template whonix-gw sys-whonix-base > qvm-create --class DispVM --label purple --template sys-whonix-base sys-whonix > qvm-prefs sys-whonix provides_network true > > Then use sys-whonix normally. All its data (especially private image) > will be discarded at the VM restart, and next startup will be from the > state of sys-whonix-base. Sounds good! > What about entry guards? AFAIR you've said it's better to have them > persistent? True, that I said that. In most cases, that's still my best knowledge. In specific cases however more control over entry guards is better. We documented this here: https://www.whonix.org/wiki/Tor#Entry_Guards >> Then only - DispVMs: support for in-RAM execution only (for >> anti-forensics) - https://github.com/QubesOS/qubes-issues/issues/904 - >> would be missing on the Qubes side. Once #904 would be implemented, it >> would be hard to point out any missing Whonix features with respect to >> amnesia. > > Yes. In theory it should also be possible with heavy usage of tmpfs > (it's possible to place all volatile.img there, using separate storage > pool). But in practice it may require some modifications. And since > limited amount of RAM, probably just tmpfs isn't the best option, better > use LUKS with some disposable key. Which require slightly more work. Alright. One day. :) >>> What about templates? > >> Starting the template as DispVM? I wouldn't know what that would be >> useful for except for testing. (Which sounds very useful as for a >> developer!) > > No, starting DispVM _from_ templates. Alright. >>> I think preferred is point 3a, but it require that Whonix-based >>> Disposable VMs works. > >> Is there any work left on the Whonix side to make them work as DisposableVM? > > I don't know. The first step would be testing what is missing (if > anything). There is a chance it will just work. Yes. Cheers, Patrick -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/8c06a4c3-55b4-eff0-c96e-3b2a2110dc39%40riseup.net. For more options, visit https://groups.google.com/d/optout.
