On Wed, Apr 5, 2017 at 11:59 PM, Sam Hentschel <hentsche...@gmail.com> 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. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_BvCxd4iZB2ANWfaVsr8EdxY%3DtSm21RMPw2RiH0gRr3ow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
