[qubes-users] Re: USB & PCIe devices management questions

[squared . beta]

I have succesfully achieved this functionality by adding PCIe USB controllers 
and using PCIe passthrough to isolate them to specific domain VMs. With USB 
extension cables it is as simple to use as if VMs were separate physical hosts, 
no problems whatsoever detected.
USB controllers were produced by Unitek brand, generic chinese brand, PCie x1 
card and 3.5 external bay USB front panel. All guests detected the devices 
without any problem.

And as for GPU, I chose to use a separate machine and utilize VNC and Nvidia 
Gamestream to game on Qubes Box, using one of the VMs as a Gamestream client. 
It required minimal troubleshooting due to the usage of unofficial Moonlight 
app for the client.

-- 
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/cef58875-0a91-4be7-8f68-0966d173d7f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Lenovo Thinkpad X1 Carbon Gen3

[Sam Hentschel]

Here's my HCL before I update my kernel or anything else.

-- 
Respectfully,
Sam Hentschel

-- 
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/20170406160827.GA2200%40Personal-Email.
For more options, visit https://groups.google.com/d/optout.
---
layout:
  'hcl'
type:
  'notebook'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  ''
brand: |
  LENOVO
model: |
  20BTS1V900
bios: |
  N14ET32W (1.10 )
cpu: |
  Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA 
controller])
gpu-short: |
  FIXME
network: |
  Intel Corporation Ethernet Connection (3) I218-LM (rev 03)
  Intel Corporation Wireless 7265 (rev 99)
memory: |
  16059
scsi: |
  SAMSUNG MZNLN256 Rev: 2L6Q

versions:

- works:
'FIXME:yes|no|partial'
  qubes: |
R3.2
  xen: |
4.6.4
  kernel: |
4.4.38-11
  remark: |
FIXME
  credit: |
FIXAUTHOR
  link: |
FIXLINK

---

Re: [qubes-users] DispVM Configuration

[Sam Hentschel]

On Thu, Apr 06, 2017 at 02:03:14PM +0100, Unman wrote:
> 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  
> > 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 

Re: [qubes-users] DispVM Configuration

[Unman]

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  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 

Re: [qubes-users] DispVM Configuration

[Sam Hentschel]

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  wrote:
> 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.

On a daily basis I interact with about three printers: one at home, one
at work, and one at school.  My goals were as follows:

- Keep one printer from getting what another printer has handled
- Stop the spread of pritner malware from one printer to another (if
  that makes sense?)
- Stop the printers (which may be and probably are compromised) from
  compromising one of my security domains.
- Kind of the same reasons as moving out the networking software and
  drivers to the NetVM and the USBs to a USBVM?

An example scenario: an employer or future employer requires me to print
out some forms from an email, fill them out, scan them, and email them
back.  In this case, it would be nice to be able to print the forms via
a DispVM (which I open anyway when interacting with email attachments),
fill them out, scan them in the same or a different DispVM and send it
back.  This way the PDF or word document is never opened in my Email
Qube.  I can thus takeout extra software in that VM, and minimize it to
just working with email.

> 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!)).

Ok, if thats the case I may clone the fedora template and make one
specifically for the DispVMs.  Some of the software I want on DispVMs, I
don't want on my AppVMs and vice versa.  Since its the case that the
DispVM uses the fedora-23 template, shouldn't the document say to edit
that instead of the fedora-23-dvm AppVM?  If you agree, maybe I'll go
pull down the documentation and rewrite some of it.

-- 
Respectfully,
Sam Hentschel

-- 
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/20170406125158.GA999%40Personal-Email.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HDMI-related threats in Qubes OS

[Andrew]

Chris Laprise:
> On 04/02/2017 03:42 AM, Vít Šesták wrote:
>> Yes, disabling those features can prevent thise threats. But I wonder
>> if Qubes does this by default or if I can disable it manually.
> 
> We may want to open an issue for this, or at least a thread in
> qubes-developer.
> 
> 
>>
>> I have also an idea how to disable it, but I am unsure if it will
>> work properly: Connect laptop  HDMI port -> HDMI to DVI -> DVI to
>> HDMI -> TV HDMI port. But since no conversion is needed, you might
>> end up with full HDMI connection.
>>
>> Related quotation: “HDMI implements the EIA/CEA-861 standards, which
>> define video formats and waveforms, transport of *compressed*,
>> uncompressed, and LPCM audio, auxiliary data, and implementations of
>> the VESA EDID.[5][6](p. III) *CEA-861 signals carried by HDMI are
>> electrically compatible with the CEA-861 signals used by the digital
>> visual interface (DVI). No signal conversion is necessary*, nor is
>> there a loss of video quality when a DVI-to-HDMI adapter is
>> used.[6](§C)” (https://en.m.wikipedia.org/wiki/HDMI, emphasis is
>> mine)
> 
> I don't believe this means that HDMI features carry over to DVI outputs
> on computers, just that HDMI ports can output to DVI displays. But it
> would be good to know what an HDMI-capable monitor can do, for instance,
> if a DVI-only card is plugged into one of its DVI ports.
> 
>>
>> My notes on this:
>>
>> 1. Compressed audio is not what I want for Audio return channel :(.
>> 2. The [6](§C) links to Appendix C of HDMI spec (see
>> http://www.microprocessor.org/HDMISpecification13a.pdf ), which
>> defines *bidirectional* compatibility level between HDMI and DVI.
>>
>> Regards, Vít Šesták 'v6ak'
>>
> 
> If the compression is only in one direction (out to the display) then I
> don't think it matters... or its a feature you want to keep.
> 
> What we need is a breakdown of the supported protocols along with a
> description of their interactivity and flow.
> 

It's a bit impractical, but how about an HDMI firewall?

A Pynq-Z1 board can be had fairly cheap ($230 normally, $65 for
students), and implementing a dumb framebuffer copy with simple
open-source components is just a matter of ~10 lines of Python.

Github: https://github.com/Xilinx/PYNQ
Board shop:
http://store.digilentinc.com/pynq-z1-python-productivity-for-zynq/
Documentation doing exactly this:
https://pynq.readthedocs.io/en/latest/9_base_overlay_video.html

(no affiliation with any of the above)
Andrew

-- 
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/41bac81e-9d61-9bd0-16d2-4193cde71ca9%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] further discussion on video resolution

[Strak8]

Good evening, I can not set the resolution on HVM's in Qubes 3.2.
Beyond the fact that I have a second GPU Radeon on the Dell laptop which I 
assume can not only use for Hvm in gpu/pci passthrough mode, considering it a 
utopia. (Trying to devote the second GPU in vm-manager/vm-setting/device get a 
machine crash)
I made many tests, I do not seek prompt solution.
For now I only have 2 HVM, a Windows 10 machine and a debian based distro.
On Windows 10 I can choose different resolutions, even the largest, but 
1366x768 is not present.
On debian within only with the setting grub deprecated vga=792 to boot. Changes 
in terminal with Xandr give it full of artifacts screen, making it unusable 
(ctrl+F1 does not work). Commands vbeinfo and vbetest in grub console cause the 
crash.
On debian based I had ssh server install when I had the screen unusable. 
Although fortunately so far the login screen is always accessible, so I can set 
the test resolutions of another user, if it is unusable can easily reset the 
configuration.
I have read that there are still some problems, which might have already been 
fixed in version 4.0, and perhaps there is a great desire to operate the 3.2.
IMPORTANT:I do not seek the possibility of having the fullscreen, I would just 
have the windows of Hvm the desired resolution. I did not expect to have all 
these problems only to change resolution, and I am conscious of not being a 
super user in linux.
Maybe I could use VNC or similar software, but in addition to not be safe to 
customize the resolution should install the client in dom0, otherwise I would 
have another vm and therefore use of resources and opening firewall ports.
On Windows 10 only needed xen video drive that accepts the 1366x768 resolution
On Debian based disto I read that with xfce would solve the problems.

Thanks for your help.

good things

-- 
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/fe804fec-fa8c-46f4-ab08-86251c7dc939%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DispVM Configuration

[Jean-Philippe Ouellet]

On Wed, Apr 5, 2017 at 11:59 PM, Sam Hentschel  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.