Re: [qubes-users] My Windows VM always stops after a while

[Robert Fisk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/13/2017 05:24 PM, loke...@gmail.com wrote:
> I have a Windows VM where I run Outlook for work purposes. It works
> great and I keep it in a separate xfce workspace. I'm running it in
> desktop mode (i.e. the Windows desktop is in a single Xfce
> window).
> 
> After a certain amount of time (hard to say how long, but I'd guess
> it's in the 30 minute to 1 hour range) the Windows desktop
> disappears, and in the Qubes manager the Windows VM is marked as
> yellow. It will stay yellow until I hard-kill the VM.
> 
> Does anyone have any idea what is going on, and what I can do to
> fix it?
> 

I notice this problem when a Windows VM is left running, but doesn't
receive any user input for 30min or more. The window will disappear
when I'm not looking and I later find the VM stopped.

In my case the solution is to use the VM, and it is reliable until the
work is finished and I shut it down. Just a thought - have a look
through the power saving & sleep options. It might be trying to "save
power"  and causing problems with Xen.

Regards,
Robert
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJY7x2IAAoJEN65WsAVra66Q/kP/ixQBirBWIGjP9fKCsoZFveU
BfRsxFcWoz+kdYeDDVXkcH6p8K1Zgnuo3w0ArHGt1tQHxdvLKjdBwcgpJ+iXQTLG
wDR5r6SIoN9jpnB0RBNobhEbVADpq4jiy/lidqFjEgPlPf1SM7pSXz5uV1ZMt7mE
LwuMv21zGOLjjAGvgQ7ss1Q/dEdyTC0Kcwjm2p5HEUHTe52HDXDyWxf+66usoQ+t
wo2ewkorDN003sMMXqZio70P67eJWkZcT65WLCFBOj5LCz5VwshASMUuXeDIXdP3
+BfbUzzdCRnpN8L0TBuCla13zY86GMkvf+/8A17/13nj00yaStwbB/JsGTCXhv9m
s/twtyBVNnvLoDvLkH93Tx++5afqlcWTyRY9tX2ltCaEClaHWBLHbVFIFGaEeuFQ
xksmCx9oylq/mI/GyipcPA4d9ScqsNvzaFHJVwv6ioQIEhds244zimJfZ1SVSVbA
KMQezZhu7XVDFpSYx3EBREWuJGAqAi0Dx8IwqslimWwuouFcmt334qHpTwfCf7m7
mr7R1h7cpWmOKvYliCOMI/2UidI3aFfqX6ibc0LvlBbWkP9DW0Ieqs0syc8x/oUE
JvFnhaOPPJnkVfCAU6V287AgqQC3KbPIa5tMIx/+c7bJmOU3/sylrrYG9ww3WQge
pXZin1qcKV9xCZJWJFC7
=rA5D
-END PGP SIGNATURE-

-- 
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/c78781fc-7b4c-953a-3217-e91273b861cf%40fastmail.fm.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Assigning a specific xfce virtual desktop to a VM-program pair

[Hack]

On 04/12/2017 10:26 PM, daltong defourne wrote:
> On Wednesday, April 12, 2017 at 10:08:20 PM UTC+3, Hack wrote:
>> On 04/12/2017 08:35 PM, daltong defourne wrote:
>>> On Wednesday, April 12, 2017 at 8:48:30 PM UTC+3, cooloutac wrote:
 On Wednesday, April 12, 2017 at 1:16:36 PM UTC-4, daltong defourne 
wrote:
> I know this (and similar matters) has been discussed in different 
places, on and off

>
> For example here:
> 
https://groups.google.com/forum/#!topic/qubes-users/jtjyq8N6bY0/discussion

> https://groups.google.com/forum/#!topic/qubes-users/gCklOzk9xYg
> https://github.com/QubesOS/qubes-issues/issues/2627
>
> However, now I am solidly confused and don't know what to do and how.
>
> What I want
>
> have firefox running in RedAppVM-One start on xfce desktop 1
>
> have firefox running in RedAppVM-Two start on xfce desktop 6
>
> Ideally, I'd also like to make ~all~ software from RedAppVM-One 
to start on desktop 1 , but even "solving for firefox" would be an okay 
start for me.


 I think you can do this on KDE,  for xfce you probably have to 
install a 3rd party tool to dom0.

>>>
>>> Devilspie2 does not seem to play nice with qubes (ref: 
https://github.com/QubesOS/qubes-issues/issues/2627 ) but if there is a 
"low bloodshed" way to make it work with qubes it would be nice.

>>>
>>> And yes, I'm on xfce...
>>>
>>
>> Where do you read that Devilspie2 does not play nice with Qubes? I am
>> using both of them, and it works nicely, since months! (And I was the
>> one who started this tread…)
> Hi Hack!
>
Hi!

> I have linked to the qubes-issues thread where it seemingly came up.
> The full problem quote is:
>
> "I tried to install devilspie2 for testing purposes on Qubes. 
Currently, it's not work on Qubes.
> Devilspie2 function get_window_name() return Windows names without 
AppVM labels. Therefore, it's not possible to sort windows on desktops 
by AppVM name."

>
> I reckon it is not actually correct and the lua scripts you provided 
work in Qubes 3.2 "as is"?

>

Yes, because those who failed to make it works used get_window_name() 
instead of get_class_instance_name()!!!


> If so, if I may ask a few questions:
> 1) do the lua provided "stick" the window to a given desktop (as in, 
I won't be able to send a window to a different virtual desktop even if 
I try) ?


Well, every time you launch a program, it will be automatically send to 
the chosen virtual desktop. But you can then send this program where you 
want.


With the script I provided, every program from "RedAppVM-One" will be 
send to workspace 1. But after that, if you want to send this program to 
workspace 6, you can.


You can customize it easily:
Change only these values:
dom = 'RedAppVM-One';
workspace = 1


> 2) if no, does devilspie2 provide a way to do that ?

See above.

> 3) if yes, is there a way to avoid sticking (as in, always start in 
desktop 1, but can be sent to any other desktop) ?


See 1)

But I repeat, once you have launched a program, you can then move it 
where you want.


> 4) could you please write up a quick primer on using devilspie2 with 
qubes (any caveats, etc?)

>

It works like a charm!

Devilspie2 is even quite flexible, but be careful, because if you write 
something like "RedAppVM" in dom variable, and 1 for workspace, without 
adding "-One", and so one to the name "RedAppVM", every new windows 
starting with 'RedAppVM*' will be send to the same workspace, here 1.



> Thank you very much
>

You are welcome.

--
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/ocn56k%24pk7%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] My Windows VM always stops after a while

[lokedhs]

I have a Windows VM where I run Outlook for work purposes. It works great and I 
keep it in a separate xfce workspace. I'm running it in desktop mode (i.e. the 
Windows desktop is in a single Xfce window).

After a certain amount of time (hard to say how long, but I'd guess it's in the 
30 minute to 1 hour range) the Windows desktop disappears, and in the Qubes 
manager the Windows VM is marked as yellow. It will stay yellow until I 
hard-kill the VM.

Does anyone have any idea what is going on, and what I can do to fix it?

-- 
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/5cf85e70-f517-412f-a0ea-f38522794e8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Windows Guest hides interface because qrexec installed.

[Drew White]

I have QREXEC installed in the Windows 7 Guest.

I do NOT have the GUI Agent, not have seamless turned on.

Yet upon starting, it hides the UI for Windows.

Here are the prefs...
-
[{user}@dom0 ~]$ qvm-prefs win7x64-tpl
name   : win7x64-tpl
label  : black
type   : TemplateHVM
netvm  : {netvm}
dispvm_netvm   : none
updateable : True
autostart  : False
installed_by_rpm   : False
include_in_backups : True
last_backup: None
dir: /var/lib/qubes/vm-templates/win7x64-tpl
config : /var/lib/qubes/vm-templates/win7x64-tpl/win7x64-tpl.conf
pcidevs: []
pci_strictreset: True
pci_e820_host  : True
root_img   : /var/lib/qubes/vm-templates/win7x64-tpl/root.img
root_cow_img   : /var/lib/qubes/vm-templates/win7x64-tpl/root-cow.img
root_volatile_img  : /var/lib/qubes/vm-templates/win7x64-tpl/volatile.img
private_img: /var/lib/qubes/vm-templates/win7x64-tpl/private.img
vcpus  : 4
memory : 4096
maxmem : 4096
MAC: (auto)
debug  : off
default_user   : {user}
qrexec_installed   : True
qrexec_timeout : 120
guiagent_installed : False
seamless_gui_mode  : False
drive  : None
timezone   : localtime
internal   : False
-
[{user}@dom0 ~]$ qvm-prefs {guest}
name   : {guest}
label  : yellow
type   : HVM
template   : win7x64-tpl
netvm  : {netvm}
dispvm_netvm   : {netvm} (default)
updateable : False
autostart  : False
installed_by_rpm   : False
include_in_backups : True
last_backup: None
dir: /var/lib/qubes/appvms/{guest}
config : /var/lib/qubes/appvms/{guest}/{guest}.conf
pcidevs: []
pci_strictreset: True
pci_e820_host  : True
root_img   : /var/lib/qubes/vm-templates/win7x64-tpl/root.img
root_volatile_img  : /var/lib/qubes/appvms/{guest}/volatile.img
private_img: /var/lib/qubes/appvms/{guest}/private.img
vcpus  : 2
memory : 2048
maxmem : 2048
MAC:  (auto)
debug  : off
default_user   : {user}
qrexec_installed   : True
qrexec_timeout : 60
guiagent_installed : False
seamless_gui_mode  : False
drive  : None
timezone   : localtime
internal   : False
-


Does anyone know how to resolve this please?

Sincerely,
Drew.

-- 
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/b30ad131-f271-4536-8755-5465e98007a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Some Important Xenial templates repos unavailable inside sources.list

[Unman]

On Wed, Apr 12, 2017 at 11:15:26PM +, Nick Darren wrote:
> Hello,
> 
> If building xenial template using qubes-builder, I found that some
> "important" repos from 'Ubuntu Update Repos' that includes both
> `xenial-security` and `xenial-updates` went missing inside
> `sources.list`. How comes it doesn't include both the repos by default?
> There's no qubes-specific repo inside `sources.list.d` too. How it
> supposed to fix the bugs (provided by ubuntu & qubes upstream) by using
> this template without the important repos over there? By not using this
> repos, how exactly you come up to handle with the outdated version of
> software inside the template? How regularly you rebuild the template
> alone (by not using these repos)?

You're right Nick.
In the absence of a Qubes repo for ubuntu, I regularly rebuild the template.
Yes, at a minimum the -security  repo should be enabled by default.

-- 
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/20170413004153.GA23144%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Problems with inter-HVM networking

['Qubesfan' via qubes-users]

Hello.

I am trying to achieve a network between two HVMs one Windows and one Linux, My 
setup is as follows:

NetVM---FirewallVM---Linux VM (ubuntu)/Windows HVM.

I have followed the directions here:
https://www.qubes-os.org/doc/firewall/

but these directions do not work fully. I can establish a connection between 
both HVMs and the firewall and I can open a terminal in the firewall and ping 
both of the HVMs. However I cannot establish a connection between the two HVMs. 
I either get "destination unreachable" or "request timed out" errors.

I found this thread:
https://groups.google.com/forum/?_escaped_fragment_=topic/qubes-users/lA2SgPcV9fU#!topic/qubes-users/lA2SgPcV9fU

I tried all the suggestions in it including the following:
(1) enabling the proxy_arp cache (verified with cat) did nothing
(2) using the sudo arp -i eth0 -s   had no effect.
(3) The suggestion by Marek to change the netmask in the Windows VM did not 
work.
(4) Changing the iptables by modifying the 
/rw/config/qubes-firewall-user-script using the code lines beginning with : 
intervm_internalnet='10.137.X.0'; also did not work.

I can use the iptables -L commands to confirm that the rules are there; they 
just don't seem to be forwarding correctly. On a whim I also upgraded to Fedora 
24 and changed my firewall to match that template but it had no effect.

Other people seem to be able to get this to work but I cannot.

Thanks in advance for any assistance.

Sent with [ProtonMail](https://protonmail.com) Secure Email

-- 
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/i3jv__vSD941K-Ba8vfGPzfYQshwB1Jy9uQJZgxSwIYZ-fNeSwXyW60kN6iTiHVpVPH5mORONtfvBf2hd85d-_CmEa9n5_5229zO0K0NS2A%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Some Important Xenial templates repos unavailable inside sources.list

[Nick Darren]

Hello,

If building xenial template using qubes-builder, I found that some
"important" repos from 'Ubuntu Update Repos' that includes both
`xenial-security` and `xenial-updates` went missing inside
`sources.list`. How comes it doesn't include both the repos by default?
There's no qubes-specific repo inside `sources.list.d` too. How it
supposed to fix the bugs (provided by ubuntu & qubes upstream) by using
this template without the important repos over there? By not using this
repos, how exactly you come up to handle with the outdated version of
software inside the template? How regularly you rebuild the template
alone (by not using these repos)?

cc: 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 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/19ac5d41-539b-94f1-9acc-ee21ee2589cd%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] M.2 SSD Not recognized as a bootable device

[mystresser01]

Hello, i hope you can help me.
After I install Qubes to the SSD and reboot, it does not recognize the SSD as a 
bootable device. Using the same install procedures on another SSD (SATA), 
everything works fine. When using Qubes from the SSD (SATA) to access the M.2 
SSD, the BOOT file is empty, so there are no files to rename as you've directed 
in the UEFI troubleshooting. Also, I cannot access the /BOOT/EFI/ file on my 
SSD (SATA), it says I don't have the required permissions.
I have also compared the Partitions from my M.2 SSD and the other SSD and they 
are the same. 
M.2 SSD PARTITIONS: http://imgur.com/a/GPCYh
SSD PARTITIONS: http://imgur.com/a/QIzph

-- 
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/f31b3b9e-1bf4-463f-9f2c-eab17fee58b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Not recognized the M.2 SSD as a bootable device

[Monj]

Hello, i hope you can help me.
After I install Qubes to the SSD and reboot, it does not recognize the SSD as a 
bootable device. Using the same install procedures on a HDD, everything works 
fine. When using Qubes from the HDD to access the SSD, the BOOT file is empty, 
so there are no files to rename as you've directed in the UEFI troubleshooting. 
Also, I cannot access the /BOOT/EFI/ file on my HDD, it says I don't have the 
required permissions.

-- 
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/bc6a10da-afad-49b8-acc2-3421e0ce7e1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Question to Mirage OS firewall users

[Foppe de Haan]

Any clue why Windows 7 won't boot when I have MirageOS selected as the firewall?

-- 
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/12d7beb6-a849-4baa-9962-c44bbdfdd3e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Windows 7 installation stops

[peter799]

I follow the tips on that thread, firstly giving 4GB ram and 50GB
partition but windows 7 freezes always at the start, after changing
'xen' to 'cirrus', in this case libvirt defines 'cirrus' an invalid
argument. 
On 4/4/2017 at 1:54 PM, "Ted Brenner"  wrote:Check out this thread.
https://groups.google.com/forum/#!searchin/qubes-users/windows$20cirrus%7Csort:relevance/qubes-users/6KePeW2gIvQ/qYhr1PUvAgAJ
On Tue, Apr 4, 2017 at 6:10 AM,   wrote:
Hi
I can't install HVM with Windows 7 because the installation stops on
the screen "Starting Windows". Before this I had installed and removed
it many times. What can be succeeded? I have no problems with win8 or
linux OS.

Best
 -- 
 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/20170404111042.9C1F3C0687%40smtp.hushmail.com.
 For more options, visit https://groups.google.com/d/optout.
-- 
Sent from my Desktop 

-- 
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/20170412212435.63A742013E%40smtp.hushmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Assigning a specific xfce virtual desktop to a VM-program pair

[daltong defourne]

On Wednesday, April 12, 2017 at 10:08:20 PM UTC+3, Hack wrote:
> On 04/12/2017 08:35 PM, daltong defourne wrote:
> > On Wednesday, April 12, 2017 at 8:48:30 PM UTC+3, cooloutac wrote:
> >> On Wednesday, April 12, 2017 at 1:16:36 PM UTC-4, daltong defourne wrote:
> >>> I know this (and similar matters) has been discussed in different places, 
> >>> on and off
> >>>
> >>> For example here:
> >>> https://groups.google.com/forum/#!topic/qubes-users/jtjyq8N6bY0/discussion
> >>> https://groups.google.com/forum/#!topic/qubes-users/gCklOzk9xYg
> >>> https://github.com/QubesOS/qubes-issues/issues/2627
> >>>
> >>> However, now I am solidly confused and don't know what to do and how.
> >>>
> >>> What I want
> >>>
> >>> have firefox running in RedAppVM-One start on xfce desktop 1
> >>>
> >>> have firefox running in RedAppVM-Two start on xfce desktop 6
> >>>
> >>> Ideally, I'd also like to make ~all~ software from RedAppVM-One to start 
> >>> on desktop 1 , but even "solving for firefox" would be an okay start for 
> >>> me.
> >>
> >> I think you can do this on KDE,  for xfce you probably have to install a 
> >> 3rd party tool to dom0.
> >
> > Devilspie2 does not seem to play nice with qubes (ref: 
> > https://github.com/QubesOS/qubes-issues/issues/2627 ) but if there is a 
> > "low bloodshed" way to make it work with qubes it would be nice.
> >
> > And yes, I'm on xfce...
> >
> 
> Where do you read that Devilspie2 does not play nice with Qubes? I am 
> using both of them, and it works nicely, since months! (And I was the 
> one who started this tread…)
Hi Hack!

I have linked to the qubes-issues thread where it seemingly came up.
The full problem quote is:

"I tried to install devilspie2 for testing purposes on Qubes. Currently, it's 
not work on Qubes.
Devilspie2 function get_window_name() return Windows names without AppVM 
labels. Therefore, it's not possible to sort windows on desktops by AppVM name."

I reckon it is not actually correct and the lua scripts you provided work in 
Qubes 3.2 "as is"?

If so, if I may ask a few questions:
1) do the lua provided "stick" the window to a given desktop (as in, I won't be 
able to send a window to a different virtual desktop even if I try) ?
2) if no, does devilspie2 provide a way to do that ?
3) if yes, is there a way to avoid sticking (as in, always start in desktop 1, 
but can be sent to any other desktop) ?
4) could you please write up a quick primer on using devilspie2 with qubes (any 
caveats, etc?)

Thank you very much

-- 
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/5d590251-c618-41c9-a18a-b455ec1c521b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Secure Handling of Encrypted Drives

[Sam Hentschel]

On Wednesday, April 12, 2017 at 3:20:30 PM UTC-4, Chris Laprise wrote:
> On 04/12/2017 02:37 PM, Jean-Philippe Ouellet wrote:
> > On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel  
> > wrote:
> >> On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman wrote:
> >>> On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:
>  I am trying to figure out a way to securely handle my encrypted drives
>  without two things: connecting the USB directly to the Vault (as this is
>  obviously a bad idea for security), and decrypting the USB in sys-usb
>  (also obviously a bad idea).
> 
>  As an example, I have some USB that I keep encrypted backups of my
>  important documents that I keep with me in case an emergency happens
>  (which now that I am using Qubes will probably also be in the Vault).  I
>  have files on there that I need to move to Vault, and I need to be able
>  to continue to put files onto it (whether from Vault or from a scan I
>  have done.    what I did giving DispVMs the sole ability to print and scan.>  Which I
>  know is a whole different problem; so I want to focus on just the
>  encrypted storage.
> 
>  Another example is my backup drives which are all encrypted, and that I
>  would like to have access to for the standard reasons.  I have been
>  pointed to [1] a couple days ago by JPO and I believe this is part of
>  the soution, but not the whole thing.
> 
>  My two solutions that I have thought through are: doing PCI patthrough
>  directly to the Vault (which is the least favorite of my ideas), and
>  creating a separate VM for encryption that only houses software for
>  encrypting and decrypting (dm-crypt or veracrypt).  This way the USB
>  will be passed through to this VM and will never directly touch the
>  Vault (except through qvm-move-to-vm).
> 
>  I had a third solution of adding this functionality to DispVMs, but I
>  can't PCI pass the USB to the DispVMs when they are running.  So that
>  one is out.
> 
>  Thanks in advance for the help; can't wait to see what I missed!
> 
>  [1] https://github.com/rustybird/qubes-split-dm-crypt
> 
> >>>
> >>> Hi Sam,
> >>>
> >>> I'm obviously missing something here.
> >>>
> >>> One of your two solutions fits completely within the current Qubes model
> >>> and matches exactly the specification you set; that is, qvm-block
> >>> attach the encrypted drive to a qube and decrypt it there.
> >>> Can I ask what more you are looking for?
> >>>
> >>> There's no need to do this in a separate decryptionVM - you can use a
> >>> disposableVM for the purpose.
> >>>
> >>> If you don't want to have the decryption software in a standard
> >>> template, then put it in a separate template, build a distinct
> >>> disposableVM from that template and use my hack to fire up that
> >>> disposableVM when you want to use a decrypted drive.
> >>>
> >>> unman
> >>
> >> Unman,
> >>
> >> I was just making sure I wasn't missing something or there wasn't a better 
> >> way.  Anyways, I can't set this up in a DispVM because you cannot PCI 
> >> passthrough to a VM while it is running(?)
> >
> > Your understanding is incorrect on the following details:
> >
> > 1) you *can* do pci passthrough to a vm while it's running. Depending
> > on if the device supports function-level-reset or not, you may need to
> > set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml
> >
> > 2) qvm-block is distinct from and not implemented with pci
> > passthrough, it uses xen blk{front,back}. This is an entirely
> > different and believed to be less dangerous interface to expose than
> > PCI to your actual devices.
> >
> >
> > That said, you might prefer to use a normal unencrypted filesystem,
> > only interface with the filesystem in sys-usb, and use encrypted files
> > instead.
> >
> > You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
> > into your other vm, {decrypt, manipulate, re-encrypt} them there, send
> > back new ciphertext (again via qvm-copy-to-vm) to sys-usb, and put
> > them back on the flash drive from there.
> >
> > This isolates your document processing from potential vulns in your
> > filesystem manipulation code (such as fuse-exfat which appears to be
> > the de-facto standard flash drive filesystem these days for maximum
> > interoperability).
> 
> This is confusing a fairly simple issue.
> 
> What Sam is looking for is to use 'qvm-block -a' (or the attach menu in 
> Qubes Manager) which indeed has nothing to do with PCI passthrough.
> 
> >
> > This approach likely has a higher chance of protecting your
> > document-processing VM from being exploited by filesystem
> > vulnerabilities, which may be even easier to exploit if you consider a
> > malicious flash drive with compromised firmware (manipulating metadata
> > behind your back while the drive is mounted to potentially otherwise
> > "unreachable" code path

Re: [qubes-users] Secure Handling of Encrypted Drives

[Sam Hentschel]

On Wednesday, April 12, 2017 at 2:37:46 PM UTC-4, Jean-Philippe Ouellet wrote:
> On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel  wrote:
> > On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman wrote:
> >> On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:
> >> > I am trying to figure out a way to securely handle my encrypted drives
> >> > without two things: connecting the USB directly to the Vault (as this is
> >> > obviously a bad idea for security), and decrypting the USB in sys-usb
> >> > (also obviously a bad idea).
> >> >
> >> > As an example, I have some USB that I keep encrypted backups of my
> >> > important documents that I keep with me in case an emergency happens
> >> > (which now that I am using Qubes will probably also be in the Vault).  I
> >> > have files on there that I need to move to Vault, and I need to be able
> >> > to continue to put files onto it (whether from Vault or from a scan I
> >> > have done.   >> > what I did giving DispVMs the sole ability to print and scan.>  Which I
> >> > know is a whole different problem; so I want to focus on just the
> >> > encrypted storage.
> >> >
> >> > Another example is my backup drives which are all encrypted, and that I
> >> > would like to have access to for the standard reasons.  I have been
> >> > pointed to [1] a couple days ago by JPO and I believe this is part of
> >> > the soution, but not the whole thing.
> >> >
> >> > My two solutions that I have thought through are: doing PCI patthrough
> >> > directly to the Vault (which is the least favorite of my ideas), and
> >> > creating a separate VM for encryption that only houses software for
> >> > encrypting and decrypting (dm-crypt or veracrypt).  This way the USB
> >> > will be passed through to this VM and will never directly touch the
> >> > Vault (except through qvm-move-to-vm).
> >> >
> >> > I had a third solution of adding this functionality to DispVMs, but I
> >> > can't PCI pass the USB to the DispVMs when they are running.  So that
> >> > one is out.
> >> >
> >> > Thanks in advance for the help; can't wait to see what I missed!
> >> >
> >> > [1] https://github.com/rustybird/qubes-split-dm-crypt
> >> >
> >>
> >> Hi Sam,
> >>
> >> I'm obviously missing something here.
> >>
> >> One of your two solutions fits completely within the current Qubes model
> >> and matches exactly the specification you set; that is, qvm-block
> >> attach the encrypted drive to a qube and decrypt it there.
> >> Can I ask what more you are looking for?
> >>
> >> There's no need to do this in a separate decryptionVM - you can use a
> >> disposableVM for the purpose.
> >>
> >> If you don't want to have the decryption software in a standard
> >> template, then put it in a separate template, build a distinct
> >> disposableVM from that template and use my hack to fire up that
> >> disposableVM when you want to use a decrypted drive.
> >>
> >> unman
> >
> > Unman,
> >
> > I was just making sure I wasn't missing something or there wasn't a better 
> > way.  Anyways, I can't set this up in a DispVM because you cannot PCI 
> > passthrough to a VM while it is running(?)
> 
> Your understanding is incorrect on the following details:
> 
> 1) you *can* do pci passthrough to a vm while it's running. Depending
> on if the device supports function-level-reset or not, you may need to
> set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml
> 
> 2) qvm-block is distinct from and not implemented with pci
> passthrough, it uses xen blk{front,back}. This is an entirely
> different and believed to be less dangerous interface to expose than
> PCI to your actual devices.
> 
> 
> That said, you might prefer to use a normal unencrypted filesystem,
> only interface with the filesystem in sys-usb, and use encrypted files
> instead.
> 
> You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
> into your other vm, {decrypt, manipulate, re-encrypt} them there, send
> back new ciphertext (again via qvm-copy-to-vm) to sys-usb, and put
> them back on the flash drive from there.
> 
> This isolates your document processing from potential vulns in your
> filesystem manipulation code (such as fuse-exfat which appears to be
> the de-facto standard flash drive filesystem these days for maximum
> interoperability).
> 
> This approach likely has a higher chance of protecting your
> document-processing VM from being exploited by filesystem
> vulnerabilities, which may be even easier to exploit if you consider a
> malicious flash drive with compromised firmware (manipulating metadata
> behind your back while the drive is mounted to potentially otherwise
> "unreachable" code paths in the fs drivers) to be part of your threat
> model.
> 
> Cheers,
> Jean-Philippe

That has definitely cleared up some of my misinformation.  Certainly it would 
be safer to do it file by file, and I could use qvm-copy to move it back and 
forth to vault and back.  However, I still need to be able to open the drives 
in the first p

[qubes-users] Re: Getting HVM to recognize a Windows 10 "Installation Media" bootable USB for installation

[bryce . paul . guinta]

On Monday, March 13, 2017 at 11:24:04 AM UTC-6, bryce.pa...@gmail.com wrote:
> Hi, I recently created a USB bootable installation media from my previous 
> Windows 10 installation using a Microsoft media creation tool. In addition to 
> the installation media, it contains info about my product key somehow. I've 
> done this before moving from HDD to SSD.
> 
> [dom0] mount /dev/sdd1 /mnt
> [dom0] ls /mnt
> Here's the file contents of the base directory of the only partition of the 
> usb:
> 
> autorun.inf
> bootmgr
> bootmgf.efi
> boot
> efi
> MediaMeta.xml
> setup.exe
> sources
> support
> 
> Fdisk -l tell me that the first and only usb partition (/dev/sdd1) is marked 
> as bootable. The partition type is W95 FAT32 (LBA).
> 
> My bios also successfully boots into the device.
> 
> Here's what I've tried so far:
> 
> [dom0] qvm-create win10 --hvm --label green
> [dom0] qvm-start --cdrom /dev/sdd win10
> [win10] Booting from CD-Rom...
> 7663MB medium detected
> CDROM boot failure code : 0005
> Boot from CD-Rom failed: could not read the boot disk
> [dom0] qvm-start --cdrom /dev/sdd1
> Same output
> [dom0] qvm-start --hd /dev/sdd
> CDROM boot failure code : 0002
> ..
> Boot from Hard Disk failed: not a bootable disk
> [dom0] qvm-start --hd /dev/sdd1
> Same output
> [dom0] dd if=/dev/sdd of=/windows.img
>  (all the enumerations of trying windows.img)
> [dom0] dd if=/dev/sdd1 of=/windows_sdd1.img
>  (all the enumerations of trying this image)
> 
> I've run out of things to try. I cannot boot into the old Windows install to 
> get the product key since I cloned it to a new drive, so I can't go the iso 
> route easily.
> 
> I'm running Qubes 3.2 with the latest dom0 updates.
> 
> Can anyone help me get this USB to boot into an HVM?

Just to give an update for anyone who find this, I was never able to get the 
HVM to boot the USB.

I booted the HVM with a bootable iso with grub on it and then tried to attach 
the usb as a device and boot from there, but all the bootable isos I tried 
would not recognize the Qubes attached virtual device.

I ended up installing Windows 10 on a secondary hard drive. Unfortunately when 
things don't work and they need to work, the only option is to sacrifice some 
security.

-- 
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/00116c22-0c39-49ca-aba4-4ff0ceaa4196%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Secure Handling of Encrypted Drives

[Chris Laprise]

On 04/12/2017 02:37 PM, Jean-Philippe Ouellet wrote:

On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel  wrote:

On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman wrote:

On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:

I am trying to figure out a way to securely handle my encrypted drives
without two things: connecting the USB directly to the Vault (as this is
obviously a bad idea for security), and decrypting the USB in sys-usb
(also obviously a bad idea).

As an example, I have some USB that I keep encrypted backups of my
important documents that I keep with me in case an emergency happens
(which now that I am using Qubes will probably also be in the Vault).  I
have files on there that I need to move to Vault, and I need to be able
to continue to put files onto it (whether from Vault or from a scan I
have done.Which I
know is a whole different problem; so I want to focus on just the
encrypted storage.

Another example is my backup drives which are all encrypted, and that I
would like to have access to for the standard reasons.  I have been
pointed to [1] a couple days ago by JPO and I believe this is part of
the soution, but not the whole thing.

My two solutions that I have thought through are: doing PCI patthrough
directly to the Vault (which is the least favorite of my ideas), and
creating a separate VM for encryption that only houses software for
encrypting and decrypting (dm-crypt or veracrypt).  This way the USB
will be passed through to this VM and will never directly touch the
Vault (except through qvm-move-to-vm).

I had a third solution of adding this functionality to DispVMs, but I
can't PCI pass the USB to the DispVMs when they are running.  So that
one is out.

Thanks in advance for the help; can't wait to see what I missed!

[1] https://github.com/rustybird/qubes-split-dm-crypt



Hi Sam,

I'm obviously missing something here.

One of your two solutions fits completely within the current Qubes model
and matches exactly the specification you set; that is, qvm-block
attach the encrypted drive to a qube and decrypt it there.
Can I ask what more you are looking for?

There's no need to do this in a separate decryptionVM - you can use a
disposableVM for the purpose.

If you don't want to have the decryption software in a standard
template, then put it in a separate template, build a distinct
disposableVM from that template and use my hack to fire up that
disposableVM when you want to use a decrypted drive.

unman


Unman,

I was just making sure I wasn't missing something or there wasn't a better way. 
 Anyways, I can't set this up in a DispVM because you cannot PCI passthrough to 
a VM while it is running(?)


Your understanding is incorrect on the following details:

1) you *can* do pci passthrough to a vm while it's running. Depending
on if the device supports function-level-reset or not, you may need to
set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml

2) qvm-block is distinct from and not implemented with pci
passthrough, it uses xen blk{front,back}. This is an entirely
different and believed to be less dangerous interface to expose than
PCI to your actual devices.


That said, you might prefer to use a normal unencrypted filesystem,
only interface with the filesystem in sys-usb, and use encrypted files
instead.

You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
into your other vm, {decrypt, manipulate, re-encrypt} them there, send
back new ciphertext (again via qvm-copy-to-vm) to sys-usb, and put
them back on the flash drive from there.

This isolates your document processing from potential vulns in your
filesystem manipulation code (such as fuse-exfat which appears to be
the de-facto standard flash drive filesystem these days for maximum
interoperability).


This is confusing a fairly simple issue.

What Sam is looking for is to use 'qvm-block -a' (or the attach menu in 
Qubes Manager) which indeed has nothing to do with PCI passthrough.




This approach likely has a higher chance of protecting your
document-processing VM from being exploited by filesystem
vulnerabilities, which may be even easier to exploit if you consider a
malicious flash drive with compromised firmware (manipulating metadata
behind your back while the drive is mounted to potentially otherwise
"unreachable" code paths in the fs drivers) to be part of your threat
model.


He said /encrypted/ volume. Even an infected drive wouldn't have access 
to the filesystem.



--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

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

[qubes-users] Re: Assigning a specific xfce virtual desktop to a VM-program pair

[Hack]

On 04/12/2017 08:35 PM, daltong defourne wrote:

On Wednesday, April 12, 2017 at 8:48:30 PM UTC+3, cooloutac wrote:

On Wednesday, April 12, 2017 at 1:16:36 PM UTC-4, daltong defourne wrote:

I know this (and similar matters) has been discussed in different places, on 
and off

For example here:
https://groups.google.com/forum/#!topic/qubes-users/jtjyq8N6bY0/discussion
https://groups.google.com/forum/#!topic/qubes-users/gCklOzk9xYg
https://github.com/QubesOS/qubes-issues/issues/2627

However, now I am solidly confused and don't know what to do and how.

What I want

have firefox running in RedAppVM-One start on xfce desktop 1

have firefox running in RedAppVM-Two start on xfce desktop 6

Ideally, I'd also like to make ~all~ software from RedAppVM-One to start on desktop 1 , 
but even "solving for firefox" would be an okay start for me.


I think you can do this on KDE,  for xfce you probably have to install a 3rd 
party tool to dom0.


Devilspie2 does not seem to play nice with qubes (ref: 
https://github.com/QubesOS/qubes-issues/issues/2627 ) but if there is a "low 
bloodshed" way to make it work with qubes it would be nice.

And yes, I'm on xfce...



Where do you read that Devilspie2 does not play nice with Qubes? I am 
using both of them, and it works nicely, since months! (And I was the 
one who started this tread…)


--
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/ocltuh%24q9p%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: change when to use tor in qubes

[jacoblorenzipoole]

On Wednesday, April 12, 2017 at 2:28:43 PM UTC-4, Michael Carbone wrote:
> jacoblorenzipo...@gmail.com:
> > On Wednesday, April 12, 2017 at 1:12:11 PM UTC-4, jacoblor...@gmail.com 
> > wrote:
> >> installed qubes with tor for everything option, how to change it without a 
> >> complete reinstall?
> > 
> > I mean, I want some VM's to not automatically go through tor, as they do 
> > now.
> > During install there was an experimental option to use tor for everything, 
> > even updates.
> 
> in Qubes VM Manager select View > NetVM if it is not selected. Then you
> can easily see the networking status of all your qubes. Change them as
> you desire (right-click, VM Settings > NetVM).
> 
> Then in Qubes VM Manager go to System > Global Settings and change the
> system defaults to whatever you want -- specifically for UpdateVM,
> default netVM.
> 
> The installation option does not lead Qubes to "use tor for everything",
> it just makes your default netvm sys-whonix for newly created
> qubes/AppVMs and makes sys-whonix the netvm of templates. Whenever you
> create a new qube / AppVM you can still select what you want the
> networking to be.
> 
> If you selected Qubes to create default qubes like personal, banking,
> untrusted, vault, these all come with non-torified networking
> (sys-firewall x 3, and none respectively).
> 
> The language/description in the installer could be improved, the
> relevant issue is here:
> 
> https://github.com/QubesOS/qubes-issues/issues/2604#issuecomment-275567972
> 
> -- 
> Michael Carbone
> 
> Qubes OS | https://www.qubes-os.org
> @QubesOS 
> 
> PGP fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4

That makes sense.  Thanks!

-- 
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/89abd370-b0ab-4526-a20e-d70f04cff3e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Secure Handling of Encrypted Drives

[Jean-Philippe Ouellet]

On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel  wrote:
> On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman wrote:
>> On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:
>> > I am trying to figure out a way to securely handle my encrypted drives
>> > without two things: connecting the USB directly to the Vault (as this is
>> > obviously a bad idea for security), and decrypting the USB in sys-usb
>> > (also obviously a bad idea).
>> >
>> > As an example, I have some USB that I keep encrypted backups of my
>> > important documents that I keep with me in case an emergency happens
>> > (which now that I am using Qubes will probably also be in the Vault).  I
>> > have files on there that I need to move to Vault, and I need to be able
>> > to continue to put files onto it (whether from Vault or from a scan I
>> > have done.  > > what I did giving DispVMs the sole ability to print and scan.>  Which I
>> > know is a whole different problem; so I want to focus on just the
>> > encrypted storage.
>> >
>> > Another example is my backup drives which are all encrypted, and that I
>> > would like to have access to for the standard reasons.  I have been
>> > pointed to [1] a couple days ago by JPO and I believe this is part of
>> > the soution, but not the whole thing.
>> >
>> > My two solutions that I have thought through are: doing PCI patthrough
>> > directly to the Vault (which is the least favorite of my ideas), and
>> > creating a separate VM for encryption that only houses software for
>> > encrypting and decrypting (dm-crypt or veracrypt).  This way the USB
>> > will be passed through to this VM and will never directly touch the
>> > Vault (except through qvm-move-to-vm).
>> >
>> > I had a third solution of adding this functionality to DispVMs, but I
>> > can't PCI pass the USB to the DispVMs when they are running.  So that
>> > one is out.
>> >
>> > Thanks in advance for the help; can't wait to see what I missed!
>> >
>> > [1] https://github.com/rustybird/qubes-split-dm-crypt
>> >
>>
>> Hi Sam,
>>
>> I'm obviously missing something here.
>>
>> One of your two solutions fits completely within the current Qubes model
>> and matches exactly the specification you set; that is, qvm-block
>> attach the encrypted drive to a qube and decrypt it there.
>> Can I ask what more you are looking for?
>>
>> There's no need to do this in a separate decryptionVM - you can use a
>> disposableVM for the purpose.
>>
>> If you don't want to have the decryption software in a standard
>> template, then put it in a separate template, build a distinct
>> disposableVM from that template and use my hack to fire up that
>> disposableVM when you want to use a decrypted drive.
>>
>> unman
>
> Unman,
>
> I was just making sure I wasn't missing something or there wasn't a better 
> way.  Anyways, I can't set this up in a DispVM because you cannot PCI 
> passthrough to a VM while it is running(?)

Your understanding is incorrect on the following details:

1) you *can* do pci passthrough to a vm while it's running. Depending
on if the device supports function-level-reset or not, you may need to
set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml

2) qvm-block is distinct from and not implemented with pci
passthrough, it uses xen blk{front,back}. This is an entirely
different and believed to be less dangerous interface to expose than
PCI to your actual devices.


That said, you might prefer to use a normal unencrypted filesystem,
only interface with the filesystem in sys-usb, and use encrypted files
instead.

You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
into your other vm, {decrypt, manipulate, re-encrypt} them there, send
back new ciphertext (again via qvm-copy-to-vm) to sys-usb, and put
them back on the flash drive from there.

This isolates your document processing from potential vulns in your
filesystem manipulation code (such as fuse-exfat which appears to be
the de-facto standard flash drive filesystem these days for maximum
interoperability).

This approach likely has a higher chance of protecting your
document-processing VM from being exploited by filesystem
vulnerabilities, which may be even easier to exploit if you consider a
malicious flash drive with compromised firmware (manipulating metadata
behind your back while the drive is mounted to potentially otherwise
"unreachable" code paths in the fs drivers) to be part of your threat
model.

Cheers,
Jean-Philippe

-- 
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_ChXGeH8fp%3DnM%3DuuLLGQGL-paK19mYJfrvCdQ3f_v%2BDDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Assigning a specific xfce virtual desktop to a VM-program pair

[daltong defourne]

On Wednesday, April 12, 2017 at 8:48:30 PM UTC+3, cooloutac wrote:
> On Wednesday, April 12, 2017 at 1:16:36 PM UTC-4, daltong defourne wrote:
> > I know this (and similar matters) has been discussed in different places, 
> > on and off
> > 
> > For example here:
> > https://groups.google.com/forum/#!topic/qubes-users/jtjyq8N6bY0/discussion
> > https://groups.google.com/forum/#!topic/qubes-users/gCklOzk9xYg
> > https://github.com/QubesOS/qubes-issues/issues/2627
> > 
> > However, now I am solidly confused and don't know what to do and how.
> > 
> > What I want
> > 
> > have firefox running in RedAppVM-One start on xfce desktop 1
> > 
> > have firefox running in RedAppVM-Two start on xfce desktop 6
> > 
> > Ideally, I'd also like to make ~all~ software from RedAppVM-One to start on 
> > desktop 1 , but even "solving for firefox" would be an okay start for me.
> 
> I think you can do this on KDE,  for xfce you probably have to install a 3rd 
> party tool to dom0.

Devilspie2 does not seem to play nice with qubes (ref: 
https://github.com/QubesOS/qubes-issues/issues/2627 ) but if there is a "low 
bloodshed" way to make it work with qubes it would be nice.

And yes, I'm on xfce...

-- 
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/14d2c8d4-4940-4ce7-887d-efff311b7067%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: change when to use tor in qubes

[Michael Carbone]

jacoblorenzipo...@gmail.com:
> On Wednesday, April 12, 2017 at 1:12:11 PM UTC-4, jacoblor...@gmail.com wrote:
>> installed qubes with tor for everything option, how to change it without a 
>> complete reinstall?
> 
> I mean, I want some VM's to not automatically go through tor, as they do now.
> During install there was an experimental option to use tor for everything, 
> even updates.

in Qubes VM Manager select View > NetVM if it is not selected. Then you
can easily see the networking status of all your qubes. Change them as
you desire (right-click, VM Settings > NetVM).

Then in Qubes VM Manager go to System > Global Settings and change the
system defaults to whatever you want -- specifically for UpdateVM,
default netVM.

The installation option does not lead Qubes to "use tor for everything",
it just makes your default netvm sys-whonix for newly created
qubes/AppVMs and makes sys-whonix the netvm of templates. Whenever you
create a new qube / AppVM you can still select what you want the
networking to be.

If you selected Qubes to create default qubes like personal, banking,
untrusted, vault, these all come with non-torified networking
(sys-firewall x 3, and none respectively).

The language/description in the installer could be improved, the
relevant issue is here:

https://github.com/QubesOS/qubes-issues/issues/2604#issuecomment-275567972

-- 
Michael Carbone

Qubes OS | https://www.qubes-os.org
@QubesOS 

PGP fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4


-- 
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/523ca7cf-a70d-4a08-b00d-4f15c41d8e7e%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Secure Handling of Encrypted Drives

[Sam Hentschel]

On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman wrote:
> On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:
> > I am trying to figure out a way to securely handle my encrypted drives
> > without two things: connecting the USB directly to the Vault (as this is
> > obviously a bad idea for security), and decrypting the USB in sys-usb
> > (also obviously a bad idea).
> > 
> > As an example, I have some USB that I keep encrypted backups of my
> > important documents that I keep with me in case an emergency happens
> > (which now that I am using Qubes will probably also be in the Vault).  I
> > have files on there that I need to move to Vault, and I need to be able
> > to continue to put files onto it (whether from Vault or from a scan I
> > have done.   > what I did giving DispVMs the sole ability to print and scan.>  Which I
> > know is a whole different problem; so I want to focus on just the
> > encrypted storage.
> > 
> > Another example is my backup drives which are all encrypted, and that I
> > would like to have access to for the standard reasons.  I have been
> > pointed to [1] a couple days ago by JPO and I believe this is part of
> > the soution, but not the whole thing.
> > 
> > My two solutions that I have thought through are: doing PCI patthrough
> > directly to the Vault (which is the least favorite of my ideas), and
> > creating a separate VM for encryption that only houses software for
> > encrypting and decrypting (dm-crypt or veracrypt).  This way the USB
> > will be passed through to this VM and will never directly touch the
> > Vault (except through qvm-move-to-vm).
> > 
> > I had a third solution of adding this functionality to DispVMs, but I
> > can't PCI pass the USB to the DispVMs when they are running.  So that
> > one is out.
> > 
> > Thanks in advance for the help; can't wait to see what I missed!
> > 
> > [1] https://github.com/rustybird/qubes-split-dm-crypt
> > 
> 
> Hi Sam,
> 
> I'm obviously missing something here.
> 
> One of your two solutions fits completely within the current Qubes model
> and matches exactly the specification you set; that is, qvm-block
> attach the encrypted drive to a qube and decrypt it there.
> Can I ask what more you are looking for?
> 
> There's no need to do this in a separate decryptionVM - you can use a
> disposableVM for the purpose.
> 
> If you don't want to have the decryption software in a standard
> template, then put it in a separate template, build a distinct
> disposableVM from that template and use my hack to fire up that
> disposableVM when you want to use a decrypted drive.
> 
> unman

Unman,

I was just making sure I wasn't missing something or there wasn't a better way. 
 Anyways, I can't set this up in a DispVM because you cannot PCI passthrough to 
a VM while it is running(?)

Very 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/fc9bdc01-060f-4fd8-892e-4e99a2d9da53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

[cooloutac]

On Wednesday, April 12, 2017 at 1:24:03 PM UTC-4, qubenix wrote:
> cooloutac:
> > On Wednesday, April 12, 2017 at 10:55:08 AM UTC-4, qubenix wrote:
> >> Unman:
> >>> On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher 
> >>> wrote:
>  On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote:
> > qubenix:
> >> Andrew David Wong:
> >>> On 2017-04-09 15:25, Joonas Lehtonen wrote:
>  Hi,
> >>>
>  if you setup MAC randomization via network manager in a debian 9
>  template as described here:
>  https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>  you still leak your hostname.
> >>>
>  Once your MAC address is randomized you might also want to prevent 
>  the
>  disclosure of your netvm's hostname to the network, since "sys-net"
>  might be a unique hostname (that links all your random MAC addresses 
>  and
>  the fact that you likely use qubes).
> >>>
>  To prevent the hostname leak via DHCP option (12):
>  - start the debian 9 template
>  - open the file /etc/dhcpd/dhclient.conf
>  - in line number 15 you should see "send host-name = gethostname();"
>  - comment (add "#" at the beginning) or remove that line and store 
>  the file
>  - reboot your netvm
> >>>
>  I tested the change via inspecting dhcp requests and can confirm that
>  the hostname is no longer included in dhcp requests.
> >>>
> >>>
> >>> Thanks. Added as a comment:
> >>>
> >>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
> >>>
> >>>
> >>
> >> Nice. I was just thinking about this after spending some time on my
> >> routers interface. Thanks for the post!
> >>
> >
> > After testing this, 'sys-net' still shows up on my router interface.
> >
> > -- 
> > qubenix
> > GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
>  Did the same test and got the same result.
> 
>  Anyone has a solution? I can always change my hostname for something 
>  else, but I would prefer not sending the hostname or finding a way to 
>  randomize it!!!
> 
>  Dominique
> 
> >>>
> >>> Strange, because those instructions are standard for removing the
> >>> hostname - I set it as blank, rather than commenting out. If you sniff
> >>> the traffic you will see that the hostname is indeed no longer sent.
> >>>
> >>> Why is it on your router interface?
> >>> My guess is that your router is returning the hostname that it has
> >>> associated with the MAC address. I've seen this happen when changing
> >>> hostname, and the DHCP server returns the *old* hostname as part of
> >>> the DHCP exchange. If you reboot the router and test again, you may find
> >>> that the issue goes away.
> >>
> >> Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC
> >> (which is randomized). I believe it was using process of elimination
> >> based on stored device hostnames (this is not public, devices are pretty
> >> static). Since restarting the router, it give my pc the hostname of a
> >> device which connected automatically to it (the only one it had to
> >> "guess" from).
> >>
> >>>
> >>> You could, of course, set a random hostname from rc.local on each boot of
> >>> sys-net.
> >>>
> >>> unman
> >>>
> >>>
> >>
> >>
> >> -- 
> >> qubenix
> >> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> > 
> > But why use dhcp if its a static home connection?  I feel that is a 
> > security risk for other reasons and always disable it.
> > 
> I haven't looked into the security risk for dhcp connection. I intend to
> look into it and adjust accordingly. Thanks for the suggestion.
> 
> -- 
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

yes for example consider your router unrusted even more so then the netcard on 
your pc.  Imagine a hacker hijacks it,  or someone just spoofs your router with 
a bad dhcp server.   Things like changing dns route or inject something to your 
computer.  dhclient has been found vulnerable many times for example.  Remember 
shellshock was a trivial reverse shell.

-- 
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/ef43dff5-1585-4239-a941-0b78cebf78f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Assigning a specific xfce virtual desktop to a VM-program pair

[cooloutac]

On Wednesday, April 12, 2017 at 1:16:36 PM UTC-4, daltong defourne wrote:
> I know this (and similar matters) has been discussed in different places, on 
> and off
> 
> For example here:
> https://groups.google.com/forum/#!topic/qubes-users/jtjyq8N6bY0/discussion
> https://groups.google.com/forum/#!topic/qubes-users/gCklOzk9xYg
> https://github.com/QubesOS/qubes-issues/issues/2627
> 
> However, now I am solidly confused and don't know what to do and how.
> 
> What I want
> 
> have firefox running in RedAppVM-One start on xfce desktop 1
> 
> have firefox running in RedAppVM-Two start on xfce desktop 6
> 
> Ideally, I'd also like to make ~all~ software from RedAppVM-One to start on 
> desktop 1 , but even "solving for firefox" would be an okay start for me.

I think you can do this on KDE,  for xfce you probably have to install a 3rd 
party tool to dom0.

-- 
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/b7dda1b4-3108-455d-9629-f607c782ec63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Assigning a specific xfce virtual desktop to a VM-program pair

[Hack]

On 04/12/2017 07:16 PM, daltong defourne wrote:

I know this (and similar matters) has been discussed in different places, on 
and off

For example here:
https://groups.google.com/forum/#!topic/qubes-users/jtjyq8N6bY0/discussion
https://groups.google.com/forum/#!topic/qubes-users/gCklOzk9xYg
https://github.com/QubesOS/qubes-issues/issues/2627

However, now I am solidly confused and don't know what to do and how.

What I want

have firefox running in RedAppVM-One start on xfce desktop 1

have firefox running in RedAppVM-Two start on xfce desktop 6

Ideally, I'd also like to make ~all~ software from RedAppVM-One to start on desktop 1 , 
but even "solving for firefox" would be an okay start for me.



If I am not mistaken :

1) Install DevilSpie2,
2) then, write some lua scipt like this :


For workspace 1, on $HOME/.config/devilspie2/RedAppVM-One.lua

dom = 'RedAppVM-One';
class = get_class_instance_name();
workspace = 1;

if (string.match(class, dom)) then
set_windows_workspace(workspace)
end


For workspace 6 on $HOME/.config/devilspie2/RedAppVM-Two.lua

dom = 'RedAppVM-Two';
class = get_class_instance_name();
workspace = 6;

if (string.match(class, dom)) then
set_windows_workspace(workspace)
end

--
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/oclp1u%2417c%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

[qubenix]

cooloutac:
> On Wednesday, April 12, 2017 at 10:55:08 AM UTC-4, qubenix wrote:
>> Unman:
>>> On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote:
 On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote:
> qubenix:
>> Andrew David Wong:
>>> On 2017-04-09 15:25, Joonas Lehtonen wrote:
 Hi,
>>>
 if you setup MAC randomization via network manager in a debian 9
 template as described here:
 https://www.qubes-os.org/doc/anonymizing-your-mac-address/
 you still leak your hostname.
>>>
 Once your MAC address is randomized you might also want to prevent the
 disclosure of your netvm's hostname to the network, since "sys-net"
 might be a unique hostname (that links all your random MAC addresses 
 and
 the fact that you likely use qubes).
>>>
 To prevent the hostname leak via DHCP option (12):
 - start the debian 9 template
 - open the file /etc/dhcpd/dhclient.conf
 - in line number 15 you should see "send host-name = gethostname();"
 - comment (add "#" at the beginning) or remove that line and store the 
 file
 - reboot your netvm
>>>
 I tested the change via inspecting dhcp requests and can confirm that
 the hostname is no longer included in dhcp requests.
>>>
>>>
>>> Thanks. Added as a comment:
>>>
>>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
>>>
>>>
>>
>> Nice. I was just thinking about this after spending some time on my
>> routers interface. Thanks for the post!
>>
>
> After testing this, 'sys-net' still shows up on my router interface.
>
> -- 
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

 Did the same test and got the same result.

 Anyone has a solution? I can always change my hostname for something else, 
 but I would prefer not sending the hostname or finding a way to randomize 
 it!!!

 Dominique

>>>
>>> Strange, because those instructions are standard for removing the
>>> hostname - I set it as blank, rather than commenting out. If you sniff
>>> the traffic you will see that the hostname is indeed no longer sent.
>>>
>>> Why is it on your router interface?
>>> My guess is that your router is returning the hostname that it has
>>> associated with the MAC address. I've seen this happen when changing
>>> hostname, and the DHCP server returns the *old* hostname as part of
>>> the DHCP exchange. If you reboot the router and test again, you may find
>>> that the issue goes away.
>>
>> Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC
>> (which is randomized). I believe it was using process of elimination
>> based on stored device hostnames (this is not public, devices are pretty
>> static). Since restarting the router, it give my pc the hostname of a
>> device which connected automatically to it (the only one it had to
>> "guess" from).
>>
>>>
>>> You could, of course, set a random hostname from rc.local on each boot of
>>> sys-net.
>>>
>>> unman
>>>
>>>
>>
>>
>> -- 
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> 
> But why use dhcp if its a static home connection?  I feel that is a security 
> risk for other reasons and always disable it.
> 
I haven't looked into the security risk for dhcp connection. I intend to
look into it and adjust accordingly. Thanks for the suggestion.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/bb62f68f-75e4-677d-462d-44b0872d72ec%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Assigning a specific xfce virtual desktop to a VM-program pair

[daltong defourne]

I know this (and similar matters) has been discussed in different places, on 
and off

For example here:
https://groups.google.com/forum/#!topic/qubes-users/jtjyq8N6bY0/discussion
https://groups.google.com/forum/#!topic/qubes-users/gCklOzk9xYg
https://github.com/QubesOS/qubes-issues/issues/2627

However, now I am solidly confused and don't know what to do and how.

What I want

have firefox running in RedAppVM-One start on xfce desktop 1

have firefox running in RedAppVM-Two start on xfce desktop 6

Ideally, I'd also like to make ~all~ software from RedAppVM-One to start on 
desktop 1 , but even "solving for firefox" would be an okay start for me.

-- 
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/f700d2ec-a441-4b5d-8eb3-1d63cde4c359%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: change when to use tor in qubes

[jacoblorenzipoole]

On Wednesday, April 12, 2017 at 1:12:11 PM UTC-4, jacoblor...@gmail.com wrote:
> installed qubes with tor for everything option, how to change it without a 
> complete reinstall?

I mean, I want some VM's to not automatically go through tor, as they do now.
During install there was an experimental option to use tor for everything, even 
updates.

-- 
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/240c66f9-09b4-40fc-a421-6bd55ce93622%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] change when to use tor in qubes

[jacoblorenzipoole]

installed qubes with tor for everything option, how to change it without a 
complete reinstall?

-- 
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/7bd9cbff-6da0-49b1-97af-f1ad6a46c999%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Why is there no built-in nvidia driver support? aka GTX 980 issues

[cooloutac]

On Sunday, April 9, 2017 at 2:24:50 PM UTC-4, Daniel Acevedo wrote:
> On Sat, 8 Apr 2017 09:31:18 -0700 (PDT)
> cooloutac  wrote:
> 
> > On Friday, April 7, 2017 at 2:51:11 AM UTC-4, sl98077 wrote:
> > > On Thursday, March 9, 2017 at 11:56:52 PM UTC-5, cooloutac wrote:  
> > > > Just to add you won't get any benefit from the Nvidia card.
> > > > Qubes only uses it for desktop effects.  the vms don;t have 3d
> > > > rendering.  
> > > 
> > > 
> > > It's not only about 3D rendering it has to do with users that want
> > > to also dual boot with a spare ssd, be a little mindful others have
> > > different obligations.. if Qubes wants to grow it needs to be
> > > readily available for all users.  
> > 
> > 
> > dual booting another os? That would defeat the purpose.  Qubes is for
> > people who want some exra security.  not a cool tech experiment.   
> > 
> 
> Using a Sata Switch that plugs in a PCI slot, one can turn on/off
> different drives, allowing dual booting without diminishing the
> security.
> 
> I ordered this one (still waiting for it):
> http://thumbs.ebaystatic.com/images/g/ZBgAAOSwvg9XbqSI/s-l225.jpg

You can also unplug the drives,  Its not only the drive that you need to worry 
about though. https://www.qubes-os.org/doc/multiboot/

-- 
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/fca90a7f-4027-4eab-adbd-be9428469651%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qubes boot repair

[jacoblorenzipoole]

On Wednesday, April 12, 2017 at 12:00:00 PM UTC-4, Holger Levsen wrote:
> On Wed, Apr 12, 2017 at 08:42:49AM -0700, jacoblorenzipo...@gmail.com wrote:
> > bios update resulted in loosing qubes option in efi boot menu
> > I can boot into qubes boot repair but not sure what to do after
> > Any suggestions?
>  
> after you chrooted into the system as suggested by the repair script, 
> running these commands helped me in a similar situation:
> 
> man efibootmgr
> efibootmgr -c -L Qubes -l /EFI/qubes/xen.efi 
> 
> (the -L is very much optional, the -l not so much :)
> 
> 
> -- 
> cheers,
>   Holger

Worked great! Much appreciated

-- 
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/4868844d-2749-4ae5-906d-c819104110b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Stripping down dom0 kernels: Any tips?

[cooloutac]

On Tuesday, April 11, 2017 at 6:29:40 PM UTC-4, Reg Tiangha wrote:
> So I've been playing around with kernels in Qubes and successfully run
> kernel 4.10 in dom0 and any domUs where grsecurity-based kernels create
> too many issues. My next goal is to try and see if I can get coldkernel
> running in dom0 alongside the Qubes-specific kernel patches. I had tried
> a couple of months ago, but my machine kernel panicked and I ran out of
> time before I had to get back to work on other things so I stopped my
> trials.
> 
> I realized that the grsecurity patches can be configured for either a VM
> host or a guest, and I had previously only been compiling guest kernels
> and used that kernel.config to build my dom0 test kernel. I've been
> trying to avoid having to compile things twice, but if it not being a
> host kernel was why I was having issues, then maybe there is no choice
> but to have two separate kernel configs.
> 
> So if that's the case and I have to compile a separate dom0 kernel with
> its own configuration anyway, I might as well go all the way. I already
> customize my kernels for my specific hardware (for example, I strip away
> all of the AMD CPU specific stuff because I only run Intel hardware, and
> take out some drivers for hardware that I don't have or will never use,
> etc), but I'm thinking I can go much further for a dom0 kernel.
> 
> I'm talking about stripping away things like the TCP/IP stack,
> netfilter, every single hardware driver outside of disk, graphics, and
> keyboard/mouse, and maybe a few other things too.
> 
> The question I had was about Xen since I'm not as familiar with it as I
> am with building kernels in general:  How much does Xen need in dom0 in
> order to work with the hardware?  For example, since sys-net has my wifi
> drivers, can I remove wifi driver support in the dom0 kernel? Or does
> Xen need a driver for it in order to pass it along to sys-net? Same kind
> of question for keyboard/mouse; if I have a sys-usb VM, could I
> theoretically strip away all USB drivers from the dom0 kernel? I'm
> thinking I'd at least need USB keyboard in order to input the disk
> passphrase on boot and could probably ditch everything else, but maybe not?
> 
> I'll probably start playing around with seeing how far I can cut down
> the dom0 kernel this weekend, but figured in the meantime I'd ask the
> list if they have any advice or tips if they've tried something like
> this in the past.

I don't have the foggiest clue,  but sounds like a great idea!

-- 
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/749f9783-db9e-4f7e-96f2-d521d77811d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Breaking the Security Model of Subgraph OS

[cooloutac]

On Wednesday, April 12, 2017 at 4:34:48 AM UTC-4, Bernhard wrote:
> > What exactly makes subgraph special and not just another
> > apparmor/selinux MAC type clone?
> >
> > The firewall is a neat bit of progress however, but again that can
> > also be accomplished with an apparmor MAC default profile however
> > allow app to access site etc is only on an IP basis not a DNS basis
> > (dns basis is sketchy anyways).
> I perfectly agree that this 'phone home' business is inaccaptable. If
> you consider that this type of firewall is easy to set up within qubes I
> invite you to write a small tutorial on the subject for 'normal users' 
>  thank you! Bernhard

with Qubes its so easy to stop,  for example for the "phoning home from media 
players"  I just use a media-vm and disable internet access on it.  Of course 
the firewall deny except is an easy option too if you want to limit internet 
access on a specific vm.

For my case, only reason I would need custom firewall scripts, is to log 
network activity,  but problem is some Qubes system processes I would not be 
able to log. 

And Can't believe Subraph is still in alpha. I feel like I tried it out over a 
year or two ago?   If you compile your own grsec kernel and use the automatic 
desktop security over performance settings You will have more kernel 
protections then they have.  I don't understand that.  It doesn't actually hurt 
performance that I have ever noticed.  And their whole arrogant and nonchalant 
attitude about everything is hard to take serious.  David Mirza is an extremely 
nice guy, but I think hes just the marketing guy he doesn't really know how 
anything works,  Bruce Leidl is really the brains behind it and he seemed a 
little vindictive to me.  They are very typical imo,  ITL is anything but.  To 
me its like theory vs real world.

-- 
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/e1b8ba47-96de-4d0d-b70d-6a592600c360%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

[cooloutac]

On Wednesday, April 12, 2017 at 10:55:08 AM UTC-4, qubenix wrote:
> Unman:
> > On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote:
> >> On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote:
> >>> qubenix:
>  Andrew David Wong:
> > On 2017-04-09 15:25, Joonas Lehtonen wrote:
> >> Hi,
> >
> >> if you setup MAC randomization via network manager in a debian 9
> >> template as described here:
> >> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
> >> you still leak your hostname.
> >
> >> Once your MAC address is randomized you might also want to prevent the
> >> disclosure of your netvm's hostname to the network, since "sys-net"
> >> might be a unique hostname (that links all your random MAC addresses 
> >> and
> >> the fact that you likely use qubes).
> >
> >> To prevent the hostname leak via DHCP option (12):
> >> - start the debian 9 template
> >> - open the file /etc/dhcpd/dhclient.conf
> >> - in line number 15 you should see "send host-name = gethostname();"
> >> - comment (add "#" at the beginning) or remove that line and store the 
> >> file
> >> - reboot your netvm
> >
> >> I tested the change via inspecting dhcp requests and can confirm that
> >> the hostname is no longer included in dhcp requests.
> >
> >
> > Thanks. Added as a comment:
> >
> > https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
> >
> >
> 
>  Nice. I was just thinking about this after spending some time on my
>  routers interface. Thanks for the post!
> 
> >>>
> >>> After testing this, 'sys-net' still shows up on my router interface.
> >>>
> >>> -- 
> >>> qubenix
> >>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
> >>
> >> Did the same test and got the same result.
> >>
> >> Anyone has a solution? I can always change my hostname for something else, 
> >> but I would prefer not sending the hostname or finding a way to randomize 
> >> it!!!
> >>
> >> Dominique
> >>
> > 
> > Strange, because those instructions are standard for removing the
> > hostname - I set it as blank, rather than commenting out. If you sniff
> > the traffic you will see that the hostname is indeed no longer sent.
> > 
> > Why is it on your router interface?
> > My guess is that your router is returning the hostname that it has
> > associated with the MAC address. I've seen this happen when changing
> > hostname, and the DHCP server returns the *old* hostname as part of
> > the DHCP exchange. If you reboot the router and test again, you may find
> > that the issue goes away.
> 
> Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC
> (which is randomized). I believe it was using process of elimination
> based on stored device hostnames (this is not public, devices are pretty
> static). Since restarting the router, it give my pc the hostname of a
> device which connected automatically to it (the only one it had to
> "guess" from).
> 
> > 
> > You could, of course, set a random hostname from rc.local on each boot of
> > sys-net.
> > 
> > unman
> > 
> > 
> 
> 
> -- 
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

But why use dhcp if its a static home connection?  I feel that is a security 
risk for other reasons and always disable it.

-- 
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/43eca04b-7f97-4c27-873a-1a85d2920361%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qubes boot repair

[Holger Levsen]

On Wed, Apr 12, 2017 at 08:42:49AM -0700, jacoblorenzipo...@gmail.com wrote:
> bios update resulted in loosing qubes option in efi boot menu
> I can boot into qubes boot repair but not sure what to do after
> Any suggestions?
 
after you chrooted into the system as suggested by the repair script, 
running these commands helped me in a similar situation:

man efibootmgr
efibootmgr -c -L Qubes -l /EFI/qubes/xen.efi 

(the -L is very much optional, the -l not so much :)


-- 
cheers,
Holger

-- 
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/20170412155952.GA19003%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [qubes-users] Display issues with Kali HVM

[Micah Lee]

On 04/11/2017 11:48 AM, Micah Lee wrote:
> When I install Kali in an HVM it has this terrible display issue [1].
> When I move the mouse to the top-left of the window, I can see the
> cursor navigate over the Application menu in the bottom left. Does
> anyone know how to fix this?

I just realized this question has already been asked:

https://groups.google.com/forum/#!topic/qubes-users/u7COjQTy1_I
https://github.com/QubesOS/qubes-issues/issues/1981

Also, I've noticed that this exact problem happens when installing
Subgraph OS in an HVM.

-- 
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/68bdd2af-acaa-39b0-a795-ca03f60a9444%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qubes boot repair

[jacoblorenzipoole]

bios update resulted in loosing qubes option in efi boot menu
I can boot into qubes boot repair but not sure what to do after
Any suggestions?

-- 
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/0655f06e-eeda-4b8b-80a7-25bc63ce5c59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Install wget?

[Chris Laprise]

On 04/12/2017 10:39 AM, henrydoblin...@gmail.com wrote:

Ok. I found the network connections setup (from my previous post "Newbie question on 
VPN"). Now I want to download the ca certificate.

However "wget" doesn't work (on the dom0 terminal). No problem there is a manual about a 
qubes builder (wich maybe a bit of an overkill for my task). Anyway, the manual says "sudo dnf 
install ..." doesn't work either.

So whatever the method is, is there a method to download the certificates (to 
dom0, where I suppose it belongs to) so that I can complete the vpn setup?

Thanx in advance,

A.


No. The Qubes way is to do all that in VMs. The VPN certificate belongs 
in the VPN VM.


Assuming you have a new proxyVM called 'VPN', you could run wget in 
there. Or, if downloading to the VPN VM makes you worried, run wget in 
another VM and use qvm-copy-to-vm to send it to the VPN VM. (Using 
qvm-copy like this to make downloads/uploads indirect can reduce risk.)


I'm not sure what you need with qubes-builder; if your goal is just to 
setup a VPN VM that seems totally unnecessary.


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/c8fad4e5-6a8b-7e0e-3c4e-22963e24712d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too

[qubenix]

Unman:
> On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote:
>> On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote:
>>> qubenix:
 Andrew David Wong:
> On 2017-04-09 15:25, Joonas Lehtonen wrote:
>> Hi,
>
>> if you setup MAC randomization via network manager in a debian 9
>> template as described here:
>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>> you still leak your hostname.
>
>> Once your MAC address is randomized you might also want to prevent the
>> disclosure of your netvm's hostname to the network, since "sys-net"
>> might be a unique hostname (that links all your random MAC addresses and
>> the fact that you likely use qubes).
>
>> To prevent the hostname leak via DHCP option (12):
>> - start the debian 9 template
>> - open the file /etc/dhcpd/dhclient.conf
>> - in line number 15 you should see "send host-name = gethostname();"
>> - comment (add "#" at the beginning) or remove that line and store the 
>> file
>> - reboot your netvm
>
>> I tested the change via inspecting dhcp requests and can confirm that
>> the hostname is no longer included in dhcp requests.
>
>
> Thanks. Added as a comment:
>
> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628
>
>

 Nice. I was just thinking about this after spending some time on my
 routers interface. Thanks for the post!

>>>
>>> After testing this, 'sys-net' still shows up on my router interface.
>>>
>>> -- 
>>> qubenix
>>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
>>
>> Did the same test and got the same result.
>>
>> Anyone has a solution? I can always change my hostname for something else, 
>> but I would prefer not sending the hostname or finding a way to randomize 
>> it!!!
>>
>> Dominique
>>
> 
> Strange, because those instructions are standard for removing the
> hostname - I set it as blank, rather than commenting out. If you sniff
> the traffic you will see that the hostname is indeed no longer sent.
> 
> Why is it on your router interface?
> My guess is that your router is returning the hostname that it has
> associated with the MAC address. I've seen this happen when changing
> hostname, and the DHCP server returns the *old* hostname as part of
> the DHCP exchange. If you reboot the router and test again, you may find
> that the issue goes away.

Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC
(which is randomized). I believe it was using process of elimination
based on stored device hostnames (this is not public, devices are pretty
static). Since restarting the router, it give my pc the hostname of a
device which connected automatically to it (the only one it had to
"guess" from).

> 
> You could, of course, set a random hostname from rc.local on each boot of
> sys-net.
> 
> unman
> 
> 


-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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/9245f24a-f51e-1ea8-10d1-55d92abfd6c8%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Install wget?

[henrydoblinger]

Ok. I found the network connections setup (from my previous post "Newbie 
question on VPN"). Now I want to download the ca certificate.

However "wget" doesn't work (on the dom0 terminal). No problem there is a 
manual about a qubes builder (wich maybe a bit of an overkill for my task). 
Anyway, the manual says "sudo dnf install ..." doesn't work either. 

So whatever the method is, is there a method to download the certificates (to 
dom0, where I suppose it belongs to) so that I can complete the vpn setup?

Thanx in advance,

A.

-- 
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/eade0739-974e-426f-aebd-26d77aefdb8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: off topic - invite codes to 'riseup'

[Tobias Bredemeier]

I would appreciate it if two people would be so generous to send me invitation 
codes.

Thank you

-- 
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/894a8ea3-a379-4bc4-9bf9-d946d1c6ba09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Breaking the Security Model of Subgraph OS

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/2017 10:34 AM, Bernhard wrote:

> I perfectly agree that this 'phone home' business is inaccaptable.
> If you consider that this type of firewall is easy to set up within
> qubes I invite you to write a small tutorial on the subject for
> 'normal users'  thank you! Bernhard

Such advanced firewall is on my todo list for ages.
My first candidate is running suricata in a proxyVM

https://suricata-ids.org/

However I had no RAM to play with such things in my machines.
No I have enough computing resource - but not enough free time :(


- -- 
Zrubi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY7e5NAAoJEH7adOMCkunmtEIP/1KGn93gd3WdfC1on3+//f4e
/ht1q6yVosHXypBT0WpRLrdWWEy+oBRfiMTbxq9xi/1CIwvMIcvOZHj0+rb+XHnZ
3j8qmmUFQQtVqyazlJuyJZYiDU1DFQl+CEA1NP/31TWNsv5bClH3jTgks68D8dr5
eUQml9KZBIgMTUfuwAJh3cx6r8/0BBET6+50wUTtua9ZXodIv1sP4xFhiZ5t/n0S
Vkc8g3MQ7YjHcBEqtbAlHTW6a9WfMEzXvHhikmUH2hE2/tp7ZFjyBv/2nHNHQUTY
2J4z7wBiLNx2Ix8ww3NsDUMVS+GV3ZvvRVveBQyx3/baQRWZik+fL3sTmpj+gGZX
uGZVblFEyE3/Q1pDk6L+0QLAZdLrre8fsYI/6uXumJYmB6LizVm7sNDLDfXyi3v2
MbleTOF0emif2B6/nfPkdXIbdolnyFTGvIf3a8emZKGwdyuuOpOVfnVdydAOLHjX
IqGZ8480UW0DSOixoTXqKB7+Gtv0o2xILuAsaPKA0DcXfbGWIysvzEc7pvXsOemf
ibKn4ZV0XJmXwqrP3Qk+dfmWh3gGxkB1OWmB/RFTKBQGk1TUlPV9ZlZ1B0FrsfkW
cZ534dmp8GkC8B/tCMAWma9lMKDaxYIo8VwEv2LkuT772bFxZZw3lKBxYqLtEALO
ZU3XD7jyaYjEt4vjNpzh
=DZ1F
-END PGP SIGNATURE-

-- 
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/6eb2987e-949c-4e2b-4018-8d4fdbc02841%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Breaking the Security Model of Subgraph OS

[Bernhard]

> What exactly makes subgraph special and not just another
> apparmor/selinux MAC type clone?
>
> The firewall is a neat bit of progress however, but again that can
> also be accomplished with an apparmor MAC default profile however
> allow app to access site etc is only on an IP basis not a DNS basis
> (dns basis is sketchy anyways).
I perfectly agree that this 'phone home' business is inaccaptable. If
you consider that this type of firewall is easy to set up within qubes I
invite you to write a small tutorial on the subject for 'normal users' 
 thank you! Bernhard


-- 
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/6c8dc688-20c2-f88e-c2ae-555258bb5da2%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Secure Handling of Encrypted Drives

[Unman]

On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:
> I am trying to figure out a way to securely handle my encrypted drives
> without two things: connecting the USB directly to the Vault (as this is
> obviously a bad idea for security), and decrypting the USB in sys-usb
> (also obviously a bad idea).
> 
> As an example, I have some USB that I keep encrypted backups of my
> important documents that I keep with me in case an emergency happens
> (which now that I am using Qubes will probably also be in the Vault).  I
> have files on there that I need to move to Vault, and I need to be able
> to continue to put files onto it (whether from Vault or from a scan I
> have done.   what I did giving DispVMs the sole ability to print and scan.>  Which I
> know is a whole different problem; so I want to focus on just the
> encrypted storage.
> 
> Another example is my backup drives which are all encrypted, and that I
> would like to have access to for the standard reasons.  I have been
> pointed to [1] a couple days ago by JPO and I believe this is part of
> the soution, but not the whole thing.
> 
> My two solutions that I have thought through are: doing PCI patthrough
> directly to the Vault (which is the least favorite of my ideas), and
> creating a separate VM for encryption that only houses software for
> encrypting and decrypting (dm-crypt or veracrypt).  This way the USB
> will be passed through to this VM and will never directly touch the
> Vault (except through qvm-move-to-vm).
> 
> I had a third solution of adding this functionality to DispVMs, but I
> can't PCI pass the USB to the DispVMs when they are running.  So that
> one is out.
> 
> Thanks in advance for the help; can't wait to see what I missed!
> 
> [1] https://github.com/rustybird/qubes-split-dm-crypt
> 

Hi Sam,

I'm obviously missing something here.

One of your two solutions fits completely within the current Qubes model
and matches exactly the specification you set; that is, qvm-block
attach the encrypted drive to a qube and decrypt it there.
Can I ask what more you are looking for?

There's no need to do this in a separate decryptionVM - you can use a
disposableVM for the purpose.

If you don't want to have the decryption software in a standard
template, then put it in a separate template, build a distinct
disposableVM from that template and use my hack to fire up that
disposableVM when you want to use a decrypted drive.

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 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/20170412081505.GA19662%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Windows 7 installation stops

[Nick Geary]

I went through the process just a couple of nights ago. So far the clearest 
instructions I've found are listed here. Related to the Xen video driver as a 
previous member has mentioned.

https://github.com/QubesOS/qubes-issues/issues/2488

-- 
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/b9f425cc-6b38-4192-a798-8586afe974f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.