On Thu, Apr 06, 2017 at 02:17:53AM -0400, Jean-Philippe Ouellet wrote: > On Wed, Apr 5, 2017 at 11:59 PM, Sam Hentschel <[email protected]> wrote: > > Hey all! > > > > So far so good with QubesOS on my end. Have almost everything up and > > running to have this as my daily carry. It's amazing how little RAM all > > these VMs actually require; and the CPU! None! > > > > Anyways, I am having some trouble configuring my DispVMs to allow me to > > use them for printing and scanning. The protocols and software for > > printing and scanning are both, as I recall, highly insecure. In > > addition, the devices that use them (i.e. printer, scanners) should be > > considered to be backdoored or owned already. > > > > I wanted to make it so that when I want to print something, I open up > > the file in a DispVM and print it from there. I then thought that I > > could approximately do the same thing with scanning. Open up a DispVM > > that is running simple-scan, scan the file into the DispVM and then copy > > it over to the VM that I want. > > > > By doing it this way I should be able to move out all the vulnerable > > printer and scanner code, and my AppVMs will never directly touch those > > devices or protocols. Instead they will be hidden behind the realtive > > safety of the Qubes file copy mechanism. > > An interesting goal. In practice I'm not sure what real benefit you'd > get from using a DispVM vs. just a regular stateful AppVM (assuming > you just use one printer/scanner). Presumably what you care about in > this context is confidentiality of your documents. Your > printer/scanner is by its very nature in a perfect position to steal > your documents, and likely also has a means to store or transmit them. > This seems true regardless of whether or not your printer/scanner can > compromise or persistently compromise a VM (which only deals with > printer drivers and documents the printer will know anyway). > > If you use multiple printers, then I can see an argument for wanting > separate AppVMs per printer, and if you constantly use different > printers then sure I guess DispVMs make sense. Is this the case? > > In other words, I'm curious what threat you're actually trying to > mitigate by doing this. > > > I tried to follow the documentation page: > > - show internal VMs > > - run gnome-terminal in fedora-23-dvm > > - install and configure the necessary applications and hardware devices > > - touch the /home/user/.qubes-dispvm-customized > > - shutdown the VM > > - regenerate the DispVM template using: qvm-create-default-dvm > > --default-template > > > > When I opened up a DispVM the software was nowhere to be found (opened > > up Firefox, right clicked on the DispVM in the VM Manager and ran > > gnome-terminal). When I reopen fedora-23-dvm the software is nowhere to > > be found. So I believe either I am doing something stupid, or the > > documentation has it wrong. I did notice that the DispVMs start with a > > ttemplate of fedora-23. So then do they not actually use the > > fedora-23-dvm template like it says? > > If you want to make additional software available, then do so in the > template of the dispvm (in your case fedora-23 (but you should really > update to fedora-24!)). > > You can think of the process of customizing a DispVM like creating a > new AppVM. Software that should be available on every run belongs in > its template. Local state (/home, etc.) happens in the AppVM. > Customizing the DispVM template is like customizing an AppVM that you > then take a snapshot of and duplicate each time you want a new DispVM. > In practice this is similar to how it's actually implemented. >
Hi Sam, I understand your goal, because I use dispVMs for scanning myself, rather than a stateful appVM. (I think Jean-Philippe missed your comment about the protocols and software being highly insecure.) I think your problem arises because of the way in which a disposableVM is generated, which hasn't been made clear enough to you. What you need to do is clone an existing template to (say) fed24-print. Then install the software drivers and printing/scanning tools on THAT template, and use it to generate a DVMTemplate. (This is the equivalent of the fedora-23-dvm you have identified.) You do this using 'qvm-create-default-dvm fed24-print' When you create a dispVM it uses the DVMTemplate to spawn a new instance. Thus the disposableVM will have the printing and scanning software and drivers in it. The customisation you have read about only refers to changes made in /home/user. This is why it uses examples of customising Firefox profiles, and why it hasn't worked in your case. Without that, each dispVM will have a home directory created from the default skel profile. Of course, it's probably occurred to you that what this means is that EVERY instance of a disposableVM will have the scan/print tools in it, and this is probably not what you want. I work around this using multiple disposableVM based off different DVMTemplates. I have a simple script that switches between the different DVMTemplates and starts a new disposableVM which effectively gives multiple template disposableVM. (This is a feature coming with v4, and my approach is at best a hack.) I have a keyboard shortcut that switches DVMTemplate and starts a "print /scan disposableVM", and another that reverts to the standard DVMTemplate. I've posted about this before, and you can see the script in this list - the thread was, I think, "Disposable VMs" a few months back. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" 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-users/20170406130314.GA19757%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
