Re: [qubes-users] How to delete or upgrade app VMs?

2018-02-20 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-02-20 22:48, Kyle Breneman wrote:
> I'm running Qubes 3.2.  I have the default Fedora 23 template VM, and the
> default app VMs built from it, but I also installed a Fedora 26 template
> VM.  Now I want to delete or upgrade my Fedora 23 app VMs, but I cannot
> figure out how to do this.  The "Delete VM" menu option in the Qubes VM
> Manager always seems to be grayed-out.  How can I either delete these app
> VMs based on Fedora 23, or switch them over to my Fedora 26 template?
> 
> Regards,
> Kyle
> 

Does this help?

https://www.qubes-os.org/doc/templates/fedora/#after-installing

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqNELUACgkQ203TvDlQ
MDDjCBAAuCHhRevjEfHIRhSkpTs6QIh8c8BBy+dWceVM14Qu24187j6hZ5OedsJZ
QVoP00tdW+xRZfnroW15f9Rzb5MPWQp/RW84rESGVBt1f7mCwzwR1aLRa7ivBPWf
+idL5WdJIMAYrCTAaI7zksPFfYrgK9tSgmULVqrkOkpYI3K24/N8JZyRmRJc6GEU
O6+8pprFykzoRE2pvSL0J1Vg24a4paYyuaKTT1wHBqkHg87Sm42amueTQUkXP8p7
d1hQ0JHyfMma53Qv2taA0l1K9WR9ifB+HH5dc0w5d7KUvc5Bs0fr5ed/5vim75fX
HyJn5P/wugaaw0+vBwU381WkCYuq/tB/HLPDirsDjK0iX9hkh6/McDZ7uD0mWmCH
NZnHKjifEkF57P5wNLVFaz90q6YfrGnyS8jJKNEopcurZOtpd0wHKnW7eh/0iO6H
EEeYkJ5M309AvFFWLE1UDHfCuPgTll/l3WB+SzUTGeF9wq7JP6RlsT02at7kXCHt
mAxfycSJ6b3B35XxBdqVmUKo9jB/XwjgGOT/RJGU/w9PxXcgmI7yR8oOXPtopH7v
HKR/dwSHlMfox+tAzAf2SFE7KIwr3JtEjcrLDP0+fDrW3QnK0zhdC5R7jXI//cwM
bFQ7jKlS8wI1ZEOYZw2oBWm72nkFO0uIt8A+60mxdq4/zY++FPg=
=Xrgv
-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/d55b41e3-0ea9-b9d1-d073-a7160dbbe05e%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] How to delete or upgrade app VMs?

2018-02-20 Thread Kyle Breneman
I'm running Qubes 3.2.  I have the default Fedora 23 template VM, and the
default app VMs built from it, but I also installed a Fedora 26 template
VM.  Now I want to delete or upgrade my Fedora 23 app VMs, but I cannot
figure out how to do this.  The "Delete VM" menu option in the Qubes VM
Manager always seems to be grayed-out.  How can I either delete these app
VMs based on Fedora 23, or switch them over to my Fedora 26 template?

Regards,
Kyle

-- 
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/CAOtZr%3DGtXrNVFrQ3undQaom%3DGpnjBiY%3DE6cGwhMh26u7-ot6hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] extract file from image backup

2018-02-20 Thread 'MirrorWay' via qubes-users
Consider using borgbackup.

Borgbackup is bandwidth-efficient (only sends deltas), versioned (later backups 
don't overwrite earlier ones), compressed, deduplicated, and encrypted.

Here is an outline of a Qubes 4.0 setup:

BACKUP:
In dom0, borg reads the source VM's private block device and computes the delta 
(of the raw data) against all previous backups. The delta is then compressed, 
encrypted, and then streamed to a net-connected VM, which in turn ssh's the 
data to your backup server.

RESTORE:
In dom0, borg again uses the net-connected VM to mount a FUSE fs (in dom0) 
containing the block device you backed up. You then pass that block device to 
the source (or other) VM (via loop mount + qvm-block). Inside the VM, you mount 
the device read-only, and can now restore single files or rsync all files 
(restores differences!).

For example, a 20GB backup may result in a 200MB daily delta that takes 5 
minutes to backup remotly.

SECURITY:
* At no point does decrypted data leave dom0. The encryption key stays in dom0. 
Neither the remote server, nor the net-connected proxying VM, are trusted.
* You never mount the backup in dom0, only in the source or other VM
* Since the backup is orchestrated by dom0, the source VM cannot delete its own 
backups.

IMPLEMENTATION NOTE:
The key to using borg from dom0 is to use BORG_RSH= to tunnel out, something 
like
  BORG_RSH='qvm-run -p  ssh'
(This doesn't quite work since dom0's qvm-run doesn't pass extra args to the 
command it runs, but you can workaround it using a script).

-- 
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/nNSrpKGfG752_ECA-vfTKyqzD5mjAmdnDKKWmgcwUyglVMjfvmy1ufA3Hz4tG7m6-xrcrm7PZAgMmvrdI94wr6Atwyt0ppuTLiaKBbTs0bs%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-20 Thread Sonny Horton
On Tuesday, February 20, 2018 at 2:45:28 PM UTC-7, Yuraeitha wrote:
> On Tuesday, February 20, 2018 at 9:06:24 PM UTC+1, Sonny Horton wrote:
> > On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> > > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> > > > I was originally on R3.2 and created 5 Standalone VMs: antergos, kali, 
> > > > parrotOS, Ubuntu (desktop), win7
> > > > 
> > > > I upgraded along the way to various R4.0 release candidates.  I skipped 
> > > > rc1 as it was not usable on my hardware.  rc2 was usable with some 
> > > > work, and rc3 has been working great.  At each upgrade through rc3, I 
> > > > used backups of the Standalone VMs that were created in 3.2.
> > > > 
> > > > However, When I decided to take the rc4 plunge, I took fresh backups of 
> > > > the VMs from R4.0rc3.
> > > > 
> > > > All 5 VMs restored cleanly (although slowly) from backup and all 
> > > > operate normally, except:
> > > > 
> > > > None of the 5 VMs have access to the network - at all (neither browser 
> > > > nor ping - either by name or IP).
> > > > 
> > > > I've done the following:
> > > > 
> > > > Made sure that each of the VMs is using sys-firewall as its netvm.
> > > > 
> > > > Made sure that I can reach the network from sys-firewall (using both 
> > > > command line [ping] and browser tools).
> > > > 
> > > > Made sure each Standalone VM is in PVH mode (except win7, which I have 
> > > > tried both as PVH and HVM).
> > > > 
> > > > Made sure no exclusive firewall rules are in place (allow all outbound 
> > > > traffic is selected).
> > > > 
> > > > Double-checked to make sure that the new rc4 template VMs are able to 
> > > > connect to the network - they all are.  Note that the Standalone VMs 
> > > > are the ONLY ones I restored from rc3 - not any template VMs or VMs 
> > > > derived from templates.
> > > > 
> > > > Note that the state indicator in Qube Manager is yellow for each of 
> > > > these Standalone VMs when they are running.  I couldn't find a legend 
> > > > for this, but assume it is not as good as green :)
> > > > 
> > > > 
> > > > I am still a bit of a novice Qubes user, but rather competent 
> > > > otherwise.  I would welcome any informed direction on where to take my 
> > > > troubleshooting next.  My goal is to get these 5 VMs running with 
> > > > network access one rc4, especially the kali and parrotOS VMs, which are 
> > > > fairly customized setups.  The others are quite generic and are for 
> > > > testing.
> > > > 
> > > > Thanks in advance for your help!
> > > > 
> > > > Sonny Horton
> > > 
> > > Could it by any chance be that this is a similar issue to that of 
> > > standalone Windows in Qubes 4, where the old Qubes tools network service 
> > > is broken? The solution there is to disable the Qubes network service 
> > > inside Windows, and then manually set the IP/subnet/Gateway/QubesDNS. 
> > > Perhaps something similar has to be done in these other standalone VM's 
> > > now?
> > > 
> > > Windows has to be run in HVM mode though (PV probably works too, but at 
> > > least PVH is officially confirmed not to work with Windows 7).
> > > 
> > > Did you try click on the VM in the Qube Manager to see if the yellow 
> > > indicator changes? You might know this already, but the Qube Manager is 
> > > "somewhat" frozen in Qubes 4, or at the very least so slow that it 
> > > appears frozen. For example if you start a VM, or close a VM, while the 
> > > Qube Manager window is up, then it won't update the new status. Similar, 
> > > if you start th Qube Manager while your VM's are starting up or shutting 
> > > down, then they will show yellow, which they also did back in Qubes 3.2. 
> > > during start or stop of VM's. I think it's a little better with recent 
> > > updates though, if you click on the individual VM's in the window, then 
> > > the status will update upon the click. Maybe it happens automatically if 
> > > more patient? I never use the Qube Manager anymore, so I'm not sure how 
> > > its behavior changes after each update. Maybe it behaves different in Q4 
> > > RC-4? A re-install was announced not to be necessary between RC-3 and 
> > > RC-4 in the release news, but there are still some small variations 
> > > though, perhaps the Qube Manager is quicker in RC-4? At least for me, 
> > > it's very slow, and it appears frozen. 
> > > 
> > > With the standalone VM issue, manual configuration of IP's is the only 
> > > suggestion that I can think of. If you already tried that or it doesn't 
> > > work, then best wait for someone who knows more, I can only offer Qubes 
> > > trial and error suggestions at best.
> > 
> > Initially followed my ignorant reflexes and replied to the e-mail, sorry!
> > 
> > @yuraeitha - thank you for the reply.
> > 
> > I’ve had the win7 VM working in R4.0rc3 with networking, having applied the 
> > qubes tools fix [IIRC it was a simple reinstall of tools], so I don’t 
> > believe this to be the issue.
> > 

[qubes-users] Re: Installing Qubes 4 with petitboot

2018-02-20 Thread qubes-os

Tim:

Thanks for the response.

Yes, I also tried a Ubuntu DVD which I was able to boot from.

I'm running 20160818.g876c81c9 for petitiboot (via a ROM from Raptor 
Engineering).


I tried a USB stick as well and got similar results.


For KCMA-D8 and similar users, how are you booting your Qubes install? 
With coreboot? Alternative payloads? Using the proprietary BIOS? Any 
other suggestions appreciated.


Thanks in advance.

--
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/8379d379-410a-9802-7f14-1b51a6d26b01%40go-bailey.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] extract file from image backup

2018-02-20 Thread higginsonjim2
Cheers.

Have used rsync before from Debian PC to server PC - but again not sure how to 
apply within constraint of a VM backup process.

I'll have a play - after my day on the hills tomorrow.

Cheers

-- 
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/dba17601-694c-42a6-9652-e45c05a5c899%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-20 Thread brendan . hoar
On Tuesday, February 20, 2018 at 2:58:18 PM UTC-5, Yuraeitha wrote:
> wait hold on, just to be sure we're on the same page here. 
> Why would you bring up sys-usb? Putting a USB controller in sys-usb is 
> normally for the purpose to use qvm-usb/widget to virtually pass it to 
> multiple of other VM's, or just a place to hold it for keyboard/mouse. Since 
> the Yubi key didn't work for me by passing it away from the sys-usb, but 
> worked in the sys-usb itself.

My recollection is that contemporary Yubikeys (other than the U2F-only one) 
present multiple interfaces/endpoints (I am probably not getting the 
terminology right). In addition, the multiple interfaces/endpoints can be 
changes by configuration tools.

Is the issue that the ability to re-assign USB devices works well only with 
"single-interface" devices but the workaround for those is to keep such on 
their own USB bus/root?

Brendan

-- 
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/ee3c23f7-228e-4376-928a-ad3160ebaa65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-20 Thread Tim W
I know there is a post in the last month about a qubes user on the list using 
the yubikey as he was having an issue tring to use two different functions 
without unplugging the Yubikey.  He wanted iirc to use it to act as keyboard to 
send passphrase but then as a 2fa in a appvm.  What happened is whatever it was 
used for last or in the appvm stuck which makes sense as it can not know or 
have the logic in qubes to switch back and forth between functions. A dirty way 
to do it was to script reinitalizing the usb slot or device.  It would be quick 
and thus just an extra click

Either way fior your single use it should work

-- 
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/8d2819ce-01c9-4936-af6d-c7aa7f29170b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 9:06:24 PM UTC+1, Sonny Horton wrote:
> On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> > > I was originally on R3.2 and created 5 Standalone VMs: antergos, kali, 
> > > parrotOS, Ubuntu (desktop), win7
> > > 
> > > I upgraded along the way to various R4.0 release candidates.  I skipped 
> > > rc1 as it was not usable on my hardware.  rc2 was usable with some work, 
> > > and rc3 has been working great.  At each upgrade through rc3, I used 
> > > backups of the Standalone VMs that were created in 3.2.
> > > 
> > > However, When I decided to take the rc4 plunge, I took fresh backups of 
> > > the VMs from R4.0rc3.
> > > 
> > > All 5 VMs restored cleanly (although slowly) from backup and all operate 
> > > normally, except:
> > > 
> > > None of the 5 VMs have access to the network - at all (neither browser 
> > > nor ping - either by name or IP).
> > > 
> > > I've done the following:
> > > 
> > > Made sure that each of the VMs is using sys-firewall as its netvm.
> > > 
> > > Made sure that I can reach the network from sys-firewall (using both 
> > > command line [ping] and browser tools).
> > > 
> > > Made sure each Standalone VM is in PVH mode (except win7, which I have 
> > > tried both as PVH and HVM).
> > > 
> > > Made sure no exclusive firewall rules are in place (allow all outbound 
> > > traffic is selected).
> > > 
> > > Double-checked to make sure that the new rc4 template VMs are able to 
> > > connect to the network - they all are.  Note that the Standalone VMs are 
> > > the ONLY ones I restored from rc3 - not any template VMs or VMs derived 
> > > from templates.
> > > 
> > > Note that the state indicator in Qube Manager is yellow for each of these 
> > > Standalone VMs when they are running.  I couldn't find a legend for this, 
> > > but assume it is not as good as green :)
> > > 
> > > 
> > > I am still a bit of a novice Qubes user, but rather competent otherwise.  
> > > I would welcome any informed direction on where to take my 
> > > troubleshooting next.  My goal is to get these 5 VMs running with network 
> > > access one rc4, especially the kali and parrotOS VMs, which are fairly 
> > > customized setups.  The others are quite generic and are for testing.
> > > 
> > > Thanks in advance for your help!
> > > 
> > > Sonny Horton
> > 
> > Could it by any chance be that this is a similar issue to that of 
> > standalone Windows in Qubes 4, where the old Qubes tools network service is 
> > broken? The solution there is to disable the Qubes network service inside 
> > Windows, and then manually set the IP/subnet/Gateway/QubesDNS. Perhaps 
> > something similar has to be done in these other standalone VM's now?
> > 
> > Windows has to be run in HVM mode though (PV probably works too, but at 
> > least PVH is officially confirmed not to work with Windows 7).
> > 
> > Did you try click on the VM in the Qube Manager to see if the yellow 
> > indicator changes? You might know this already, but the Qube Manager is 
> > "somewhat" frozen in Qubes 4, or at the very least so slow that it appears 
> > frozen. For example if you start a VM, or close a VM, while the Qube 
> > Manager window is up, then it won't update the new status. Similar, if you 
> > start th Qube Manager while your VM's are starting up or shutting down, 
> > then they will show yellow, which they also did back in Qubes 3.2. during 
> > start or stop of VM's. I think it's a little better with recent updates 
> > though, if you click on the individual VM's in the window, then the status 
> > will update upon the click. Maybe it happens automatically if more patient? 
> > I never use the Qube Manager anymore, so I'm not sure how its behavior 
> > changes after each update. Maybe it behaves different in Q4 RC-4? A 
> > re-install was announced not to be necessary between RC-3 and RC-4 in the 
> > release news, but there are still some small variations though, perhaps the 
> > Qube Manager is quicker in RC-4? At least for me, it's very slow, and it 
> > appears frozen. 
> > 
> > With the standalone VM issue, manual configuration of IP's is the only 
> > suggestion that I can think of. If you already tried that or it doesn't 
> > work, then best wait for someone who knows more, I can only offer Qubes 
> > trial and error suggestions at best.
> 
> Initially followed my ignorant reflexes and replied to the e-mail, sorry!
> 
> @yuraeitha - thank you for the reply.
> 
> I’ve had the win7 VM working in R4.0rc3 with networking, having applied the 
> qubes tools fix [IIRC it was a simple reinstall of tools], so I don’t believe 
> this to be the issue.
> 
> With regard to win7 as well, I do have it set to use HVM (I tried PVH for 
> grins as that was how it was set initially after the restore).
> 
> I did update the Qube Manager window - both by clicking on the running VM and 
> by using the refresh button in the 

Re: [qubes-users] qrexec policies broken after QSB #38 update

2018-02-20 Thread Micah Lee
On 02/20/18 11:25, Chris Laprise wrote:
> Since several people are reporting this, I decided to try some simple
> qvm-copy tests and have been unable to reproduce the problem on R4.0-rc4.
> 
> I updated with qubes*testing and then restarted per the QSB.

I realized that I had enabled the testing repo in dom0 but not in my
templates. After enabled the testing repo in my templates and installing
updates, I no longer have this problem.

-- 
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/638b7bac-4cd8-6d92-3a81-236892923da8%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-20 Thread Sonny Horton
On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> > I was originally on R3.2 and created 5 Standalone VMs: antergos, kali, 
> > parrotOS, Ubuntu (desktop), win7
> > 
> > I upgraded along the way to various R4.0 release candidates.  I skipped rc1 
> > as it was not usable on my hardware.  rc2 was usable with some work, and 
> > rc3 has been working great.  At each upgrade through rc3, I used backups of 
> > the Standalone VMs that were created in 3.2.
> > 
> > However, When I decided to take the rc4 plunge, I took fresh backups of the 
> > VMs from R4.0rc3.
> > 
> > All 5 VMs restored cleanly (although slowly) from backup and all operate 
> > normally, except:
> > 
> > None of the 5 VMs have access to the network - at all (neither browser nor 
> > ping - either by name or IP).
> > 
> > I've done the following:
> > 
> > Made sure that each of the VMs is using sys-firewall as its netvm.
> > 
> > Made sure that I can reach the network from sys-firewall (using both 
> > command line [ping] and browser tools).
> > 
> > Made sure each Standalone VM is in PVH mode (except win7, which I have 
> > tried both as PVH and HVM).
> > 
> > Made sure no exclusive firewall rules are in place (allow all outbound 
> > traffic is selected).
> > 
> > Double-checked to make sure that the new rc4 template VMs are able to 
> > connect to the network - they all are.  Note that the Standalone VMs are 
> > the ONLY ones I restored from rc3 - not any template VMs or VMs derived 
> > from templates.
> > 
> > Note that the state indicator in Qube Manager is yellow for each of these 
> > Standalone VMs when they are running.  I couldn't find a legend for this, 
> > but assume it is not as good as green :)
> > 
> > 
> > I am still a bit of a novice Qubes user, but rather competent otherwise.  I 
> > would welcome any informed direction on where to take my troubleshooting 
> > next.  My goal is to get these 5 VMs running with network access one rc4, 
> > especially the kali and parrotOS VMs, which are fairly customized setups.  
> > The others are quite generic and are for testing.
> > 
> > Thanks in advance for your help!
> > 
> > Sonny Horton
> 
> Could it by any chance be that this is a similar issue to that of standalone 
> Windows in Qubes 4, where the old Qubes tools network service is broken? The 
> solution there is to disable the Qubes network service inside Windows, and 
> then manually set the IP/subnet/Gateway/QubesDNS. Perhaps something similar 
> has to be done in these other standalone VM's now?
> 
> Windows has to be run in HVM mode though (PV probably works too, but at least 
> PVH is officially confirmed not to work with Windows 7).
> 
> Did you try click on the VM in the Qube Manager to see if the yellow 
> indicator changes? You might know this already, but the Qube Manager is 
> "somewhat" frozen in Qubes 4, or at the very least so slow that it appears 
> frozen. For example if you start a VM, or close a VM, while the Qube Manager 
> window is up, then it won't update the new status. Similar, if you start th 
> Qube Manager while your VM's are starting up or shutting down, then they will 
> show yellow, which they also did back in Qubes 3.2. during start or stop of 
> VM's. I think it's a little better with recent updates though, if you click 
> on the individual VM's in the window, then the status will update upon the 
> click. Maybe it happens automatically if more patient? I never use the Qube 
> Manager anymore, so I'm not sure how its behavior changes after each update. 
> Maybe it behaves different in Q4 RC-4? A re-install was announced not to be 
> necessary between RC-3 and RC-4 in the release news, but there are still some 
> small variations though, perhaps the Qube Manager is quicker in RC-4? At 
> least for me, it's very slow, and it appears frozen. 
> 
> With the standalone VM issue, manual configuration of IP's is the only 
> suggestion that I can think of. If you already tried that or it doesn't work, 
> then best wait for someone who knows more, I can only offer Qubes trial and 
> error suggestions at best.

Initially followed my ignorant reflexes and replied to the e-mail, sorry!

@yuraeitha - thank you for the reply.

I’ve had the win7 VM working in R4.0rc3 with networking, having applied the 
qubes tools fix [IIRC it was a simple reinstall of tools], so I don’t believe 
this to be the issue.

With regard to win7 as well, I do have it set to use HVM (I tried PVH for grins 
as that was how it was set initially after the restore).

I did update the Qube Manager window - both by clicking on the running VM and 
by using the refresh button in the toolbar.  The icon stays yellow.  I did 
notice that state indicators do not change when you terminate a standalone VM 
outside the Qube Manager, but do if you refresh the view.  I did also notice an 
error message that reports itself as a possible bug in Qube Manager 

[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 8:44:36 PM UTC+1, William Bormann wrote:
> > oh, you make a good point. I indeed made an assumption that it was about 
> > lock-out by the "reading guides" line, and I somehow missed the line 
> > regarding Google and Facebook services. I must then have misunderstood, I 
> > apologize. 
> > 
> > I just tested the Yubi key I got laying around, it works in sys-usb, or 
> > whereever the controller is located, be it dom0 or another AppVM with a 
> > working USB controller. But it doesn't seem like either the qvm-usb (or its 
> > GUI counterpart in the menu-widget introduced in Qubes 4, works. At least 
> > it doesn't appear on my system.
> > 
> > But it works wherever the USB controller is located, just not in the VM's 
> > that are virtually linked with qvm-USB and the GUI-widget counterpart.
> > 
> > As such, one can probably estimate the Yubi key working, if one has a 
> > working USB controller to spare, and that USB controller can feasibly be 
> > passed directly to the AppVM. But it can be tricky to find hardware that 
> > allows passthrough, especially considering the drivers are often not made 
> > for it, as well as there aren't terribly many products with multiple 
> > controllers on them to pick between. On laptops, it's hard to know in 
> > advance how many controllers there are, as it's not a marketing 
> > information, nor something frequently found in product reviews, quite 
> > frustrating. But if determined, can probably get extra USB controllers to 
> > spare, but it might be on the expensive side if making a mistake, like 
> > buying a computer that only had one controller, or the extra controller 
> > can't be passed through.
> > 
> > But if one has a system with extra USB controllers, and it works to pass an 
> > USB controller directly into the AppVM (test other USB applications work), 
> > then the Yubi key should naturally work too.
> > 
> > Perhaps there are easier work-arounds, or maybe the qvm-usb/GUI-widget it 
> > works on other systems.
> 
> This is exactly what I was hoping.  I'm not planning to use it for luks or 
> Qubes user login, but as a second authentication factor when I log into Gmail 
> or (shudder) or decide to catch up on Facebook.
> 
> It turns out I do have a spare controller.  Time to bring up sys-usb.

wait hold on, just to be sure we're on the same page here. 
Why would you bring up sys-usb? Putting a USB controller in sys-usb is normally 
for the purpose to use qvm-usb/widget to virtually pass it to multiple of other 
VM's, or just a place to hold it for keyboard/mouse. Since the Yubi key didn't 
work for me by passing it away from the sys-usb, but worked in the sys-usb 
itself.

If you have a controller to spare, you'd want to put it directly into the 
AppVM. It's less secure than a sys-usb, but nonetheless, if you really need an 
USB application working, which doesn't work in the widget/qvm-USB, then you 
need to pass the USB controller directly into the very VM where you need the 
Yubi key. This can also cause problems if you need to switch the controller 
from one VM to another, for example you can't run both VM's at the same time if 
they both try to claim the controller, and if the USB controller has no 
pci-reset functionality, then you need to restart the whole computer to be able 
to move it to a new VM.

Just to be sure we're on the same page here?

-- 
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/b517045b-06b0-4c00-bd2e-8ff4be9b343f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 8:44:36 PM UTC+1, William Bormann wrote:
> > oh, you make a good point. I indeed made an assumption that it was about 
> > lock-out by the "reading guides" line, and I somehow missed the line 
> > regarding Google and Facebook services. I must then have misunderstood, I 
> > apologize. 
> > 
> > I just tested the Yubi key I got laying around, it works in sys-usb, or 
> > whereever the controller is located, be it dom0 or another AppVM with a 
> > working USB controller. But it doesn't seem like either the qvm-usb (or its 
> > GUI counterpart in the menu-widget introduced in Qubes 4, works. At least 
> > it doesn't appear on my system.
> > 
> > But it works wherever the USB controller is located, just not in the VM's 
> > that are virtually linked with qvm-USB and the GUI-widget counterpart.
> > 
> > As such, one can probably estimate the Yubi key working, if one has a 
> > working USB controller to spare, and that USB controller can feasibly be 
> > passed directly to the AppVM. But it can be tricky to find hardware that 
> > allows passthrough, especially considering the drivers are often not made 
> > for it, as well as there aren't terribly many products with multiple 
> > controllers on them to pick between. On laptops, it's hard to know in 
> > advance how many controllers there are, as it's not a marketing 
> > information, nor something frequently found in product reviews, quite 
> > frustrating. But if determined, can probably get extra USB controllers to 
> > spare, but it might be on the expensive side if making a mistake, like 
> > buying a computer that only had one controller, or the extra controller 
> > can't be passed through.
> > 
> > But if one has a system with extra USB controllers, and it works to pass an 
> > USB controller directly into the AppVM (test other USB applications work), 
> > then the Yubi key should naturally work too.
> > 
> > Perhaps there are easier work-arounds, or maybe the qvm-usb/GUI-widget it 
> > works on other systems.
> 
> This is exactly what I was hoping.  I'm not planning to use it for luks or 
> Qubes user login, but as a second authentication factor when I log into Gmail 
> or (shudder) or decide to catch up on Facebook.
> 
> It turns out I do have a spare controller.  Time to bring up sys-usb.

Glad it worked out good in the 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/b0a9b701-233d-4b35-bd93-72fa778f2280%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> I was originally on R3.2 and created 5 Standalone VMs: antergos, kali, 
> parrotOS, Ubuntu (desktop), win7
> 
> I upgraded along the way to various R4.0 release candidates.  I skipped rc1 
> as it was not usable on my hardware.  rc2 was usable with some work, and rc3 
> has been working great.  At each upgrade through rc3, I used backups of the 
> Standalone VMs that were created in 3.2.
> 
> However, When I decided to take the rc4 plunge, I took fresh backups of the 
> VMs from R4.0rc3.
> 
> All 5 VMs restored cleanly (although slowly) from backup and all operate 
> normally, except:
> 
> None of the 5 VMs have access to the network - at all (neither browser nor 
> ping - either by name or IP).
> 
> I've done the following:
> 
> Made sure that each of the VMs is using sys-firewall as its netvm.
> 
> Made sure that I can reach the network from sys-firewall (using both command 
> line [ping] and browser tools).
> 
> Made sure each Standalone VM is in PVH mode (except win7, which I have tried 
> both as PVH and HVM).
> 
> Made sure no exclusive firewall rules are in place (allow all outbound 
> traffic is selected).
> 
> Double-checked to make sure that the new rc4 template VMs are able to connect 
> to the network - they all are.  Note that the Standalone VMs are the ONLY 
> ones I restored from rc3 - not any template VMs or VMs derived from templates.
> 
> Note that the state indicator in Qube Manager is yellow for each of these 
> Standalone VMs when they are running.  I couldn't find a legend for this, but 
> assume it is not as good as green :)
> 
> 
> I am still a bit of a novice Qubes user, but rather competent otherwise.  I 
> would welcome any informed direction on where to take my troubleshooting 
> next.  My goal is to get these 5 VMs running with network access one rc4, 
> especially the kali and parrotOS VMs, which are fairly customized setups.  
> The others are quite generic and are for testing.
> 
> Thanks in advance for your help!
> 
> Sonny Horton

Could it by any chance be that this is a similar issue to that of standalone 
Windows in Qubes 4, where the old Qubes tools network service is broken? The 
solution there is to disable the Qubes network service inside Windows, and then 
manually set the IP/subnet/Gateway/QubesDNS. Perhaps something similar has to 
be done in these other standalone VM's now?

Windows has to be run in HVM mode though (PV probably works too, but at least 
PVH is officially confirmed not to work with Windows 7).

Did you try click on the VM in the Qube Manager to see if the yellow indicator 
changes? You might know this already, but the Qube Manager is "somewhat" frozen 
in Qubes 4, or at the very least so slow that it appears frozen. For example if 
you start a VM, or close a VM, while the Qube Manager window is up, then it 
won't update the new status. Similar, if you start th Qube Manager while your 
VM's are starting up or shutting down, then they will show yellow, which they 
also did back in Qubes 3.2. during start or stop of VM's. I think it's a little 
better with recent updates though, if you click on the individual VM's in the 
window, then the status will update upon the click. Maybe it happens 
automatically if more patient? I never use the Qube Manager anymore, so I'm not 
sure how its behavior changes after each update. Maybe it behaves different in 
Q4 RC-4? A re-install was announced not to be necessary between RC-3 and RC-4 
in the release news, but there are still some small variations though, perhaps 
the Qube Manager is quicker in RC-4? At least for me, it's very slow, and it 
appears frozen. 

With the standalone VM issue, manual configuration of IP's is the only 
suggestion that I can think of. If you already tried that or it doesn't work, 
then best wait for someone who knows more, I can only offer Qubes trial and 
error suggestions at 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/ed685c86-63dd-4df5-91bb-915864a9f1e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-20 Thread William Bormann
> oh, you make a good point. I indeed made an assumption that it was about 
> lock-out by the "reading guides" line, and I somehow missed the line 
> regarding Google and Facebook services. I must then have misunderstood, I 
> apologize. 
> 
> I just tested the Yubi key I got laying around, it works in sys-usb, or 
> whereever the controller is located, be it dom0 or another AppVM with a 
> working USB controller. But it doesn't seem like either the qvm-usb (or its 
> GUI counterpart in the menu-widget introduced in Qubes 4, works. At least it 
> doesn't appear on my system.
> 
> But it works wherever the USB controller is located, just not in the VM's 
> that are virtually linked with qvm-USB and the GUI-widget counterpart.
> 
> As such, one can probably estimate the Yubi key working, if one has a working 
> USB controller to spare, and that USB controller can feasibly be passed 
> directly to the AppVM. But it can be tricky to find hardware that allows 
> passthrough, especially considering the drivers are often not made for it, as 
> well as there aren't terribly many products with multiple controllers on them 
> to pick between. On laptops, it's hard to know in advance how many 
> controllers there are, as it's not a marketing information, nor something 
> frequently found in product reviews, quite frustrating. But if determined, 
> can probably get extra USB controllers to spare, but it might be on the 
> expensive side if making a mistake, like buying a computer that only had one 
> controller, or the extra controller can't be passed through.
> 
> But if one has a system with extra USB controllers, and it works to pass an 
> USB controller directly into the AppVM (test other USB applications work), 
> then the Yubi key should naturally work too.
> 
> Perhaps there are easier work-arounds, or maybe the qvm-usb/GUI-widget it 
> works on other systems.

This is exactly what I was hoping.  I'm not planning to use it for luks or 
Qubes user login, but as a second authentication factor when I log into Gmail 
or (shudder) or decide to catch up on Facebook.

It turns out I do have a spare controller.  Time to bring up sys-usb.

-- 
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/66ea85e2-440c-4e2b-8ad8-87cdeb9b3f64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] qrexec policies broken after QSB #38 update

2018-02-20 Thread Chris Laprise

On 02/20/2018 02:03 PM, Micah Lee wrote:

I just installed updates in dom0 (current-testing) after QSB #38, and
now my qrexec policies are semi-broken.

To demonstrate, I just made two new AppVMs, testvm1 and testvm2. I want
to copy a file from testvm1 to testvm2:

[user@testvm1 ~]$ echo test > test.txt
[user@testvm1 ~]$ qvm-copy test.txt
Request refused
[user@testvm1 ~]$

It immediately fails with "Request refused" and doesn't pop up a dom0
window asking where I want to copy it to. This is true when I run
`qvm-copy` in any VM, it is immediately denied without prompting me.

I'm running into the same problem with other qrexec services too, like:

[user@testvm1 ~]$ qvm-open-in-dvm https://www.eff.org/
Request refused
[user@testvm1 ~]$

My /etc/qubes-rpc/policy/qubes.Filecopy has only one line:

$anyvm $anyvm ask

However, if I edit it and add this line to the beginning:

testvm1 testvm2 allow

It works, but only if I use the deprecated `qvm-copy-to-vm`:

[user@testvm1 ~]$ qvm-copy test.txt
Request refused
[user@testvm1 ~]$ qvm-copy-to-vm testvm2 test.txt
qvm-copy-to-vm/qvm-move-to-vm tools are deprecated,
use qvm-copy/qvm-move to avoid typing target qube name twice
sent 0/1 KB
[user@testvm1 ~]$

And likewise, my qubes.Gpg policy works for the VMs where I explicitly
allow it.

I read the QSB, and it says that the '$' character is being deprecated
and replaced with the '@' character, but changing my qrexec policy to
this doesn't work:

@anyvm @anyvm ask

Is anyone else running into this problem? Any solutions?



Since several people are reporting this, I decided to try some simple 
qvm-copy tests and have been unable to reproduce the problem on R4.0-rc4.


I updated with qubes*testing and then restarted per the QSB.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
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/31326c3a-b63c-5b7f-e54d-258761ee3e8a%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: qrexec policies broken after QSB #38 update

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 8:03:31 PM UTC+1, Micah Lee wrote:
> I just installed updates in dom0 (current-testing) after QSB #38, and
> now my qrexec policies are semi-broken.
> 
> To demonstrate, I just made two new AppVMs, testvm1 and testvm2. I want
> to copy a file from testvm1 to testvm2:
> 
> [user@testvm1 ~]$ echo test > test.txt
> [user@testvm1 ~]$ qvm-copy test.txt
> Request refused
> [user@testvm1 ~]$
> 
> It immediately fails with "Request refused" and doesn't pop up a dom0
> window asking where I want to copy it to. This is true when I run
> `qvm-copy` in any VM, it is immediately denied without prompting me.
> 
> I'm running into the same problem with other qrexec services too, like:
> 
> [user@testvm1 ~]$ qvm-open-in-dvm https://www.eff.org/
> Request refused
> [user@testvm1 ~]$
> 
> My /etc/qubes-rpc/policy/qubes.Filecopy has only one line:
> 
> $anyvm $anyvm ask
> 
> However, if I edit it and add this line to the beginning:
> 
> testvm1 testvm2 allow
> 
> It works, but only if I use the deprecated `qvm-copy-to-vm`:
> 
> [user@testvm1 ~]$ qvm-copy test.txt
> Request refused
> [user@testvm1 ~]$ qvm-copy-to-vm testvm2 test.txt
> qvm-copy-to-vm/qvm-move-to-vm tools are deprecated,
> use qvm-copy/qvm-move to avoid typing target qube name twice
> sent 0/1 KB
> [user@testvm1 ~]$
> 
> And likewise, my qubes.Gpg policy works for the VMs where I explicitly
> allow it.
> 
> I read the QSB, and it says that the '$' character is being deprecated
> and replaced with the '@' character, but changing my qrexec policy to
> this doesn't work:
> 
> @anyvm @anyvm ask
> 


> Is anyone else running into this problem? Any solutions?

Yes, there is a new discussion over in Qubes devel 
https://groups.google.com/forum/#!topic/qubes-devel/c3ygyBTMVx0
I have the issue too btw, check the thread to see more. 

Try a full system restart a second time, maybe that'll help? It seems 
restarting works for some, but at least it didn't for me, and it seems like it 
didn't for Elias either. So it's a bit of a mixed response atm.

-- 
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/ae42442f-7db6-4230-ab3c-23268f4aad5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qrexec policies broken after QSB #38 update

2018-02-20 Thread Micah Lee
I just installed updates in dom0 (current-testing) after QSB #38, and
now my qrexec policies are semi-broken.

To demonstrate, I just made two new AppVMs, testvm1 and testvm2. I want
to copy a file from testvm1 to testvm2:

[user@testvm1 ~]$ echo test > test.txt
[user@testvm1 ~]$ qvm-copy test.txt
Request refused
[user@testvm1 ~]$

It immediately fails with "Request refused" and doesn't pop up a dom0
window asking where I want to copy it to. This is true when I run
`qvm-copy` in any VM, it is immediately denied without prompting me.

I'm running into the same problem with other qrexec services too, like:

[user@testvm1 ~]$ qvm-open-in-dvm https://www.eff.org/
Request refused
[user@testvm1 ~]$

My /etc/qubes-rpc/policy/qubes.Filecopy has only one line:

$anyvm $anyvm ask

However, if I edit it and add this line to the beginning:

testvm1 testvm2 allow

It works, but only if I use the deprecated `qvm-copy-to-vm`:

[user@testvm1 ~]$ qvm-copy test.txt
Request refused
[user@testvm1 ~]$ qvm-copy-to-vm testvm2 test.txt
qvm-copy-to-vm/qvm-move-to-vm tools are deprecated,
use qvm-copy/qvm-move to avoid typing target qube name twice
sent 0/1 KB
[user@testvm1 ~]$

And likewise, my qubes.Gpg policy works for the VMs where I explicitly
allow it.

I read the QSB, and it says that the '$' character is being deprecated
and replaced with the '@' character, but changing my qrexec policy to
this doesn't work:

@anyvm @anyvm ask

Is anyone else running into this problem? Any solutions?

-- 
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/a5155c72-f7dd-f0f2-a595-9b172b4cc681%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread 'Tom Zander' via qubes-users
On Tuesday, 20 February 2018 19:41:19 CET Marek Marczykowski-Górecki wrote:
> > On the 'other' side of qrexec (on dom0) you have perfect control over
> > the
> > situation and you also don't have any need for recoding or encodings or
> > anything like that. It still is just 8 bits data, not encoded.
> 
> And then, after policy evaluation, you pass that data to actual service
> to execute the operation (which may be in dom0 or another VM).

Yes, WITHOUT the escape character.

Remember, you escape the special names of VM names that dom0 will 
substitute. “$adminvm” doesn't end up being the string you offer to qubesd, 
the string “dom0” is.

Likewise; you don't start a service in Dispvm18431 and send it the text 
“$dispvm”.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
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/2032074.AZcuCm27fB%40strawberry.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Feb 20, 2018 at 06:57:34PM +0100, Tom Zander wrote:
> On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote:
> > > The thing you have to rememeber is that the escape character never needs
> > > to be typed by the user.
> > > In QRexec you are defining an API, applications like qvm-run are using
> > > that API. What the user passes into qvm-run and what is actually sent
> > > to dom0 does not have to be identical.
> > 
> > In theory yes, but this would introduce more complexity to this code
> > (taking care where which encoding is used etc).
> 
> I read the code, there is no encoding.
> You correctly used the  POSIX Portable Character Set for text. So no need 
> for encoding.
> When you use the qrexec API you just sent a struct with some arrays of bytes 
> for VM names.
> In your qrexec code you use an array of unsigned chars. Also, no encoding.
> 
> The point is that you use encodings only when you have **text** with 
> characters > 127. Which you don't allow.
> 
> The problem you fear doesn't exist.
> 
> The reason is because when accepting user-input you use encodings.
> 
> When your app starts talking to qrexec/qubsed there is no longer any 
> encoding. Just an 8-bit bytearray. The text has been standardized.
> 
> On the 'other' side of qrexec (on dom0) you have perfect control over the 
> situation and you also don't have any need for recoding or encodings or 
> anything like that. It still is just 8 bits data, not encoded.

And then, after policy evaluation, you pass that data to actual service
to execute the operation (which may be in dom0 or another VM).

> > > I guess you do the translation currently as well; '$' turns into '@' in
> > > your new code.
> > > 
> > > The consequence of this is that you don't have to limit yourself to the
> > > posix list.
> > > Using the portable characters set for a non-character simply isn't
> > > needed.
> > > 
> > > So, knowing that your API is actually based on 8-bit characters and not
> > > 7
> > > bits which you are limiting yourself to, my suggestion is to take
> > > something above 127 and below 256 as a special char.
> > > Most fun one would be “ÿ” which is a normal character you can pass on a
> > > shell script if you must, its actual byte-value is 0xFF
> > 
> > Until some helpful application (shell or else) will try to interpret it
> > as UTF-8.
> 
> Ehm, how would “some helpful application” manage to get in your qrexec 
> policy-frameowork? If you fear that you have bigger issues as they could 
> replace anything with anything...

I'm not sure if you've read the QSB carefully. The problem is how the
thing executing the service handle arguments. Not policy evaluating part
- - there '$' or other potentially shell special characters are handled
correctly. Anyone can write a qrexec service, and we want to provide a
framework that make it hard to shoot yourself in the foot.

> Anyway, to answer your fear.
> 
> No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. 
> (see attached example file) Or, more likely, it will just switch off utf-8.
> 



- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMa8cACgkQ24/THMrX
1yyE6gf+McyBJoK/NW4KAfYEL5xritven8tl35yXaWND674jddKz/WXMaaf9mdar
338xMDBLoeDMZvYVpujd2+lbbnwyMPOUvxGtDQ87R+mluWX5YkWcrzNgVWhrjbJu
GTczmlkCT+PaW5cYonXCvFMzGyB3Afu2T7BMBD947RU2SUpiaooAfUUqpS1dCGG8
cQF8xe2Ab3vCBF1e1ocOEF5KRYgsC8NsTc1KDqlDp9AORqfLOINHv0ZNFS/Gaksn
CLqvKO5VPr+oswHm8v5I4MLQPK5cQuFvn7oJOs3+pOzZqVk9y7xvjZ4xKiVNF4pB
tK0B3Tpp3F0VzI9fhAoYHi4pI2PSUg==
=mIGj
-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/20180220184119.GG2084%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-20 Thread Sonny Horton
I was originally on R3.2 and created 5 Standalone VMs: antergos, kali, 
parrotOS, Ubuntu (desktop), win7

I upgraded along the way to various R4.0 release candidates.  I skipped rc1 as 
it was not usable on my hardware.  rc2 was usable with some work, and rc3 has 
been working great.  At each upgrade through rc3, I used backups of the 
Standalone VMs that were created in 3.2.

However, When I decided to take the rc4 plunge, I took fresh backups of the VMs 
from R4.0rc3.

All 5 VMs restored cleanly (although slowly) from backup and all operate 
normally, except:

None of the 5 VMs have access to the network - at all (neither browser nor ping 
- either by name or IP).

I've done the following:

Made sure that each of the VMs is using sys-firewall as its netvm.

Made sure that I can reach the network from sys-firewall (using both command 
line [ping] and browser tools).

Made sure each Standalone VM is in PVH mode (except win7, which I have tried 
both as PVH and HVM).

Made sure no exclusive firewall rules are in place (allow all outbound traffic 
is selected).

Double-checked to make sure that the new rc4 template VMs are able to connect 
to the network - they all are.  Note that the Standalone VMs are the ONLY ones 
I restored from rc3 - not any template VMs or VMs derived from templates.

Note that the state indicator in Qube Manager is yellow for each of these 
Standalone VMs when they are running.  I couldn't find a legend for this, but 
assume it is not as good as green :)


I am still a bit of a novice Qubes user, but rather competent otherwise.  I 
would welcome any informed direction on where to take my troubleshooting next.  
My goal is to get these 5 VMs running with network access one rc4, especially 
the kali and parrotOS VMs, which are fairly customized setups.  The others are 
quite generic and are for testing.

Thanks in advance for your help!

Sonny Horton


-- 
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/a09d05b6-d8a7-4aa0-b14b-e144b09465fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread 'Tom Zander' via qubes-users
On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote:
> > The thing you have to rememeber is that the escape character never needs
> > to be typed by the user.
> > In QRexec you are defining an API, applications like qvm-run are using
> > that API. What the user passes into qvm-run and what is actually sent
> > to dom0 does not have to be identical.
> 
> In theory yes, but this would introduce more complexity to this code
> (taking care where which encoding is used etc).

I read the code, there is no encoding.
You correctly used the  POSIX Portable Character Set for text. So no need 
for encoding.
When you use the qrexec API you just sent a struct with some arrays of bytes 
for VM names.
In your qrexec code you use an array of unsigned chars. Also, no encoding.

The point is that you use encodings only when you have **text** with 
characters > 127. Which you don't allow.

The problem you fear doesn't exist.

The reason is because when accepting user-input you use encodings.

When your app starts talking to qrexec/qubsed there is no longer any 
encoding. Just an 8-bit bytearray. The text has been standardized.

On the 'other' side of qrexec (on dom0) you have perfect control over the 
situation and you also don't have any need for recoding or encodings or 
anything like that. It still is just 8 bits data, not encoded.

> > I guess you do the translation currently as well; '$' turns into '@' in
> > your new code.
> > 
> > The consequence of this is that you don't have to limit yourself to the
> > posix list.
> > Using the portable characters set for a non-character simply isn't
> > needed.
> > 
> > So, knowing that your API is actually based on 8-bit characters and not
> > 7
> > bits which you are limiting yourself to, my suggestion is to take
> > something above 127 and below 256 as a special char.
> > Most fun one would be “ÿ” which is a normal character you can pass on a
> > shell script if you must, its actual byte-value is 0xFF
> 
> Until some helpful application (shell or else) will try to interpret it
> as UTF-8.

Ehm, how would “some helpful application” manage to get in your qrexec 
policy-frameowork? If you fear that you have bigger issues as they could 
replace anything with anything...

Anyway, to answer your fear.

No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. 
(see attached example file) Or, more likely, it will just switch off utf-8.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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/2513384.SI2geNoQLk%40strawberry.
For more options, visit https://groups.google.com/d/optout.
�b


Re: [qubes-users] extract file from image backup

2018-02-20 Thread higginsonjim2
Thanks for comments. 

For info - have used Debian for around 10 years till I swapped to Qubes around 
1 year ago. Windows before that. I use CLONEZILLA as it gives easy 
backup/restore for my old (Occasional use Os's) + QUBES + my wife's UBUNTU. 
In extreme case of needing an individual old file (NOT NEEDED YET) - I could 
restore an old IMAGE to a spare HDD on chosen PC and then copy it from there. 
Not elegant but it would work.

Am retired and just experimenting the other day for general education - to see 
if I could get an individual file from an old image copy. As per above - no 
problem on non-QUBES. (TO answer one point above - I did restore full disk 
image to hda1.img and could then access all files - this was no real effort - 
enter an instruction, wait a couple of minutes and its all there).
Ideally for me there would be something simple for me with QUBES.

Have no problem backing up VM's to separate HDD on main PC and copying back as 
needed - this may be the way forward for me - but I'd still do the CLONEZILLA 
(BACKUP EVERYTHING) approach as I get a complete system if say my SSD fails.
Backing up everything and then being able to select an odd file if ever needed 
just seems a simpler concept to me!

My preference is to have "BACKUP" even of VM's on separate PC (as per my 
CLONEZILLA images) but though one can apparently use SSH to send files through 
to separate SERVER PC, I haven't yet managed to get this work - I'm OK when 
using SSH to copy from EG my DEBIAN system to SERVER - but the "right" SSH 
instruction within the QUBES BACKUP PROCESS seems to be eluding me!

The restore /var/lib/qubes and loopback approach may be a bit beyond me. Can 
see the relevant files for my live system but not sure about the data within my 
clonezilla image. 

If this is feasible from CLONEZILLA image stored on separate internal server, I 
might see if I can try and understand it - will have a look another day. Think 
I'll go hill-walking tomorrow!  

Thanks again for all comments.








-- 
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/fcba904c-6185-4371-ba5e-90e3d112ade7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] extract file from image backup

2018-02-20 Thread Chris Laprise

On 02/20/2018 10:53 AM, Yuraeitha wrote:

On Tuesday, February 20, 2018 at 3:21:23 PM UTC+1, Bernhard wrote:

Apologies, missed your post donoban. But looping the backup seems

interesting, I suppose it must be possible with the decryption too. >
Yes, it is. I backup by data that way since Q4  - the qubes-backup may
be more "handy", but I prefer knowing every single detail on encryption,
etc myself. You may mount a luks-container in sys-usb (for example), and
then attach one-by-one your app-vm private.img  to sys-usb using the
qubes widget; after mounting them (ro of course) you can simply rsync
your data, most conveniently to the backup volume. Your app-vm will not
be exposed to usb that way.

If you have a full dd take of your qubes system (I understood you inital
mail like that), be aware that the some image files are rather like "dd
disk images" rather than "dd partition images", which means you cannot
use the most straightforward mount on the loop device (you never mount a
disc, but a partition!). Instead, have to read the offset of the
partition start using fdisk or similar, and provide this offset to the
mount command. A quick google reveals the details on this procedure :)

Bernhard


That's a pretty cool and nice trick, I'm definitely gonna play with it when I 
get the time for it. I feel the same about such programs too, complex backup 
mechanisms are a single point of failure... I might just adapt your habit 
there, even though this isn't my thread/issue, I'll still say thanks for 
sharing.

Hopefully that solves the OP problem though, it seems like it's exactly what 
he's looking for by the looks of it.



There is not much difference between the manual method OP describes and 
the way qvm-backup does it (automatically).


If you follow the emergency backup recovery docs, it lays out manual 
steps for recovering Qubes data as img files which you can then mount:


https://www.qubes-os.org/doc/backup-restore/#emergency-backup-recovery-without-qubes


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
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/84b85fc0-c777-f743-9bcc-0fbb14d9dafe%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HTTP proxy & firewall woes

2018-02-20 Thread Demi M. Obenour
I use GMail and Thunderbird for email, and Firefox as my browser.  I do
email and GitHub from a different domain that is more trusted than
others (it’s blue).

I would love to restrict its networking abilities by using firewall
rules or a filtering proxy.  Sadly, I have not been able to do that
without breaking at least GMail.  For firewall rules, the culprit seems
to be Google’s use of DNS load balancing, but I am not sure what is
breaking for the filtering proxy.  OCSP stapling?

I would much prefer to be able to restrict network access, but I cannot
break what needs to work.  Does anyone have 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/8eb2fda0-f6d6-11a5-b6bb-e457900d5e74%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0xFF9C22C1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


[qubes-users] USB VM based on fedora-26 doesn't pass block devices

2018-02-20 Thread Kelly Dean
I'm getting the same bug as reported at 
https://github.com/QubesOS/qubes-issues/issues/2018

The bug was originally reported against r3.1 and fedora-23-minimal, and fixed 
in r3.2 and fedora-24-minimal. However, I'm getting it on r3.2, using fedora-26 
(full, not minimal) for both my USB VM and my appVM. Both Qubes and the 
template are fully updated. Rebooting the system doesn't fix it. Trying a 
different appVM also doesn't fix it.

qvm-block -l says the USB device is attached to the appVM. But the appVM has no 
/dev/xvdi

xl block-list shows the appVM's four standard block devices with state 4, and 
it shows a fifth device with state 3. This is the same result that the OP got. 
I don't know what the state numbers 3 and 4 mean, and neither does google. The 
man page for xl also says nothing about them.

/var/log/xen/xen-hotplug.log reveals nothing helpful.

The OP solved his problem by installing perl in the template. But I'm using the 
full fedora-26, which already has perl installed.

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


[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-20 Thread msgheap
On Tuesday, February 20, 2018 at 6:00:21 PM UTC+7, Yuraeitha wrote:
> On Tuesday, February 20, 2018 at 10:51:55 AM UTC+1, msg...@gmail.com wrote:
> > On Tuesday, February 20, 2018 at 2:49:30 PM UTC+7, Yuraeitha wrote:
> > > On Monday, February 19, 2018 at 3:37:39 PM UTC+1, msg...@gmail.com wrote:
> > > > On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote:
> > > > > On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com 
> > > > > wrote:
> > > > > > On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com 
> > > > > > wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > Is it possible to start all VMs marked as "Start qube 
> > > > > > > automatically on boot" on Qubes OS boot and not on user login in 
> > > > > > > Qubes OS?
> > > > > > > Is it possible to do it without Qubes OS autologin?
> > > > > > > I want to have a working server application on VM on Qubes OS 
> > > > > > > boot without the need to login in Qubes OS.
> > > > > > 
> > > > > > I've enabled autologin and add "xscreensaver-command -lock" in the 
> > > > > > Startup Applications as temporary solution, but it's not perfect 
> > > > > > because the system is unlocked briefly before xscreensaver will be 
> > > > > > locked and it may be exploited.
> > > > > 
> > > > > I'm no expert, but in order to bypass a Qubes login, isn't this just 
> > > > > about changing the PID levels? If this is possible to do without 
> > > > > major change in the code, of course. The various processes are 
> > > > > ordered in levels, init the root of all levels being 1, and the 
> > > > > lowest possible firmware at init 0. While root as an account is 
> > > > > disabled by default in Qubes, there should be something akin to root, 
> > > > > in a way of "system" processes. So the system processes starts up 
> > > > > during boot, which includes all autostart VM's. Which you can see in 
> > > > > "sudo journalctl --boot" and adjust it to around the time you booted 
> > > > > it up, or a much simpler appoach which is to press the F1 key after 
> > > > > LUKS password, which will show you what happens during boot, up until 
> > > > > the Qubes login for user sessions. 
> > > > > 
> > > > > I believe the AppVM's must be partly starting up in the background, 
> > > > > but all the user aspects from the user account, did not. For example 
> > > > > XFCE4, widgets, notifications, etc. are not bound by system 
> > > > > processes, but are bount by the user account processes. 
> > > > > 
> > > > > If you can change all the processes related to a Qube AppVM, and all 
> > > > > the required processes, i.e. by changing them from user processes 
> > > > > type, to a system process type, then it may very well fully boot 
> > > > > before you type in your password.
> > > > > 
> > > > > However, you will have no LUKS password, since this cannot be 
> > > > > automated even if you use other systems. Essentially, your plan seems 
> > > > > like it will fall apart, no matter what you do with current 
> > > > > technology, no matter which Linux or system you pick, they are all 
> > > > > vulnurable to this issue. Or so it seems, after all, I'm no expert. 
> > > > > 
> > > > > Essentially, you can probably work around the last Qubes login, but 
> > > > > not the first disk encryption login. And even then, putting some of 
> > > > > Qubes processes from user to system, may be risky too.
> > > > > 
> > > > > I'm sorry, but if you look at it from an abstract point of view, no 
> > > > > matter how you flip this, it just seems outright impossible if 
> > > > > preserving security is your goal. Or did I miss something crucial?
> > > > 
> > > > Thank you for the suggestion to check the boot process log, the AppVMs 
> > > > really are starting up before user login. It seems that when I've 
> > > > tested this, the testing AppVM failed to load and I couldn't connect to 
> > > > it. I've tried to connect to the ssh service in AppVM, but failed to 
> > > > connect and when I've logged in the Qubes OS I've seen the VMs just 
> > > > starting to boot from the look of it.
> > > > The problem is solved.
> > > > 
> > > > Regarding the encryption, I'm thinking of using hardware-based full 
> > > > disk encryption with the feature to remote unlocking the drive to keep 
> > > > the encryption keys away from the Qubes OS hardware. This will avoid 
> > > > the threats like meltdown/spectre/IntelME/AMD PSP stealing the 
> > > > encryption keys.
> > > 
> > > @msg...@gmail.com
> > > oh interesting, I did not know it was possible to do remote hardware 
> > > decryption, I made the mistake expecting it had to be physically at the 
> > > server. This is one powerful ability that indeed changes everything. 
> > > Looks like it might work after all then, I'm glad its starting to work 
> > > out for you.
> > > 
> > > Apologize for the large post below, but I'd argue I have a solution for 
> > > you regarding the RAM issue, but it's a different way of thinking, that's 
> > 

[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Feb 20, 2018 at 04:27:16PM +0100, 'Tom Zander' via qubes-devel wrote:
> On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote:
> > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel 
> wrote:
> > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki 
> wrote:
> > > > We've decided to deprecate the '$' character from qrexec-related
> > > > usage.
> > > > Instead, to denote special tokens, we will use the '@' character,
> > > > which we believe is less likely to be interpreted in a special way
> > > > by the relevant software.
> > > 
> > > I would argue against the @ sign on account that it is a special
> > > character in bash as well.
> > > 
> > > I don't immediately see a way to exploit it, but why risk it?
> > 
> > We absolutely need a special character that is not allowed in qube name to
> > make the special tokens immediately obvious in policy. The process I used
> > was to list available characters (POSIX Portable Character Set [1])
> []
> > If I missed something, could you please point out? I know shell just good
> > enough to know that it's not possible to know every shell quirk. :)
> 
> The thing you have to rememeber is that the escape character never needs to 
> be typed by the user.
> In QRexec you are defining an API, applications like qvm-run are using that 
> API. What the user passes into qvm-run and what is actually sent to dom0 
> does not have to be identical.

In theory yes, but this would introduce more complexity to this code
(taking care where which encoding is used etc).

> I guess you do the translation currently as well; '$' turns into '@' in your 
> new code.
> 
> The consequence of this is that you don't have to limit yourself to the 
> posix list.
> Using the portable characters set for a non-character simply isn't needed.
> 
> So, knowing that your API is actually based on 8-bit characters and not 7 
> bits which you are limiting yourself to, my suggestion is to take something 
> above 127 and below 256 as a special char.
> Most fun one would be “ÿ” which is a normal character you can pass on a 
> shell script if you must, its actual byte-value is 0xFF

Until some helpful application (shell or else) will try to interpret it
as UTF-8.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMRLUACgkQ24/THMrX
1yxCegf+Iii677oWd0CmJgoygfVfiQnmDl+a7XBX/i+tb8BMqO67AgwzoM6cWXq6
ZaA76a50qKSmcSjj6xSPtg4sPV0hqpgORsnxikAn5zg9vi7QJMJ0q+hKuKVxHAY1
TZSVFynTs6ci0JjgVRiB8QZCrl2eC9hQraGs46u6Zevvj80ZapaEqu0Sh0rowpDe
SZ+QbiKi/QD1IeSF03OjnlqtoEyAZtPJ4dMY9F8IpR0P/vzsPxnkx/493HVjSA1i
7Z7kutdCcrGAqCtROhQ9DnS7+GTfdNcDJ5zwZ5yz5fJWlrzFgDSjENuwrSUqU/13
W6HNQVwx/fW+RBseUkJ/o98GHVW8sg==
=af4O
-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/20180220155436.GC2084%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] extract file from image backup

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 3:21:23 PM UTC+1, Bernhard wrote:
> > > Apologies, missed your post donoban. But looping the backup seems
> interesting, I suppose it must be possible with the decryption too. >
> Yes, it is. I backup by data that way since Q4  - the qubes-backup may
> be more "handy", but I prefer knowing every single detail on encryption,
> etc myself. You may mount a luks-container in sys-usb (for example), and
> then attach one-by-one your app-vm private.img  to sys-usb using the
> qubes widget; after mounting them (ro of course) you can simply rsync
> your data, most conveniently to the backup volume. Your app-vm will not
> be exposed to usb that way.
> 
> If you have a full dd take of your qubes system (I understood you inital
> mail like that), be aware that the some image files are rather like "dd
> disk images" rather than "dd partition images", which means you cannot
> use the most straightforward mount on the loop device (you never mount a
> disc, but a partition!). Instead, have to read the offset of the
> partition start using fdisk or similar, and provide this offset to the
> mount command. A quick google reveals the details on this procedure :)
> 
> Bernhard

That's a pretty cool and nice trick, I'm definitely gonna play with it when I 
get the time for it. I feel the same about such programs too, complex backup 
mechanisms are a single point of failure... I might just adapt your habit 
there, even though this isn't my thread/issue, I'll still say thanks for 
sharing. 

Hopefully that solves the OP problem though, it seems like it's exactly what 
he's looking for by the looks of 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/dc2ec088-2e13-4069-a65b-7985f84d9902%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread 'Tom Zander' via qubes-users
On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote:
> On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel 
wrote:
> > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki 
wrote:
> > > We've decided to deprecate the '$' character from qrexec-related
> > > usage.
> > > Instead, to denote special tokens, we will use the '@' character,
> > > which we believe is less likely to be interpreted in a special way
> > > by the relevant software.
> > 
> > I would argue against the @ sign on account that it is a special
> > character in bash as well.
> > 
> > I don't immediately see a way to exploit it, but why risk it?
> 
> We absolutely need a special character that is not allowed in qube name to
> make the special tokens immediately obvious in policy. The process I used
> was to list available characters (POSIX Portable Character Set [1])
[]
> If I missed something, could you please point out? I know shell just good
> enough to know that it's not possible to know every shell quirk. :)

The thing you have to rememeber is that the escape character never needs to 
be typed by the user.
In QRexec you are defining an API, applications like qvm-run are using that 
API. What the user passes into qvm-run and what is actually sent to dom0 
does not have to be identical.
I guess you do the translation currently as well; '$' turns into '@' in your 
new code.

The consequence of this is that you don't have to limit yourself to the 
posix list.
Using the portable characters set for a non-character simply isn't needed.

So, knowing that your API is actually based on 8-bit characters and not 7 
bits which you are limiting yourself to, my suggestion is to take something 
above 127 and below 256 as a special char.
Most fun one would be “ÿ” which is a normal character you can pass on a 
shell script if you must, its actual byte-value is 0xFF

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
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/5355623.KmoKho9gXC%40strawberry.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] extract file from image backup

2018-02-20 Thread Bernhard

> > Apologies, missed your post donoban. But looping the backup seems
interesting, I suppose it must be possible with the decryption too. >
Yes, it is. I backup by data that way since Q4  - the qubes-backup may
be more "handy", but I prefer knowing every single detail on encryption,
etc myself. You may mount a luks-container in sys-usb (for example), and
then attach one-by-one your app-vm private.img  to sys-usb using the
qubes widget; after mounting them (ro of course) you can simply rsync
your data, most conveniently to the backup volume. Your app-vm will not
be exposed to usb that way.

If you have a full dd take of your qubes system (I understood you inital
mail like that), be aware that the some image files are rather like "dd
disk images" rather than "dd partition images", which means you cannot
use the most straightforward mount on the loop device (you never mount a
disc, but a partition!). Instead, have to read the offset of the
partition start using fdisk or similar, and provide this offset to the
mount command. A quick google reveals the details on this procedure :)

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/439262ae-b08c-fb00-d7b6-06a3c4b8d871%40web.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread donoban
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

After upgrading Qubes 3.2 with the patches all seems fine.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqMLisACgkQFBMQ2OPt
CKW0nw/8D/T+ShxOuAVnlG38T6f/LZ8Hx/1tlVe7Ad+Keihe7+eP/t8HDQmO1kpw
JJdkeOvDNEM+uUS9frEtKTDVnRQTQhKVjfGzkFAPd02opNhS7TqG2OKPqh7CUqTl
xM87mZ1OLbEnpc1ppPZ3pBM/cOFBsd8i07/skd/CN/NEBSkBABABoTSMWJwVdLEN
0GaQOaV7F+Ani7Vq8yD9RkJPuC5npMtMtXMNo1PnOtwTix6P8Q+yvF/jb+cc1uRH
FNcl7/YkDS8N492ikJwdsIA/Vss+fSRv4w85S4hWaqlb8b6C0R4+OjjovW40o5v0
XuLT6aoT3jFnAioXeSPCXY4s7+eP/DZkTJpYTcyR4aFseoQaGkU/UY3RoU+w7eL/
gqnf+F/UwjgZ4KfFoL23I2QaO4euFTHJTRfrnk4rPE0CRgj/pQ2OYRkugdPG3qON
kbpVR/HGo1DIeQzI33Qfee2wAGV2DcqW6ysg6c9G8wxLWipr1CuGTHaWgKE6voKI
d4ywuA5OpKLl1CyBAKQQ9PqfOjkXV+EQLQuCpN0xOcIlgNC8FR69BPYevHs1EDB2
pYdkwObAk+euUhsCINy/kR31SKAvIlt1JF65f3vcatAqJTXdE+efOSxPemti+FwY
psBR3gfLEN+C//Qay7Ki5wVkjGsKKtpkanRRnc+smxOkA48Tlto=
=LN7Q
-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/08645af7-3a60-2cf5-9958-a50703006bae%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] extract file from image backup

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 2:52:38 PM UTC+1, donoban wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 02/20/2018 02:16 PM, higginsonj...@gmail.com wrote:
> > Not sure if what I want to achieve is possible but I'll try and
> > summarise below.
> > 
> > With other distros that I run (WIN10, Ubuntu, Debian) as well as
> > QUBES - I make full disk images using CLONEZILLA and retain them on
> > a spare PC, running as a local server.
> > 
> > All full disk restores work fine, including QUBES OS - which is now
> > my primary system.
> > 
> > Ideally I'd like to be able to have access to individual files
> > within the image copies(if needed).
> > 
> > For DEBIAN, Ubuntu and I assume WIN10(though not really bothered
> > about that) I can go into terminal on my backup PC and key
> > something along the lines of
> > 
> > sudo cat /dir-to-images/sdb1.ext4-ptcl-img.gz.* | sudo gzip -d -c |
> > sudo partclone.ext4 -C -r -W -s - -O /dir-to-new-image/hda1.img
> > 
> > where all the key files take the form sdb1.ext4-ptcl-img.gz.* with
> > * being aa,ab,ac etc.
> > 
> > 
> > As long as I've created a restore file first (eg hda1.img in the
> > above example) the above code works fine - and if I mount the
> > hda1.img file, then all my folders and files are accessible.
> > 
> > I can then recover say an individual file without having to do full
> > disk restore etc.
> > 
> > IS THIS POSSIBLE WITH QUBES?
> > 
> > The relevant files take the form sdc1.ext4-ptcl-img.gz.aa (a single
> > file) and lots of files of the form sdc2.dd-img.aa, sdc2.dd-img.ab
> > through to sdc2.dd-img.bd.
> > 
> > The above instruction works with the sdc1 file and opens up various
> > system files - but I can't do anything to read the sdc2 series of
> > files.
> > 
> > Am not sure what to expect if I could get it to work since each VM
> > has its own DOCUMENTS, DOWNLOAD folders etc.
> > 
> > Is what I want to achieve possible and if so - grateful for any
> > suggestions as to relevant code needed.
> > 
> > If not - any suggestions about a different approach to a simple
> > "system" backup with access to individual files as needed?
> 
> I think you could restore /var/lib/qubes/appvms/vm-name/private.img
> and mount it as a loop device. Then extract the file you want.
> 
> However I don't see too much benefit with your method. Are you getting
> your whole hard disk backup on /dir-to-new-image/hda1.img? If yes it's
> not very useful for getting then one single file.
> 
> I think it's simpler and more efficient just restoring an standard
> Qubes backup (only the VM's that you need), start them, move the files
> you want outside and remove it.
> 
> With Qubes backup you have possibility to restore individual VM's,
> integrity check of the backup, possibility of encryption, and also
> store related configuration of the vm (firewall, netVM, etc...).
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqMKAkACgkQFBMQ2OPt
> CKXgRQ/9Hi8UFzT+vgZ2Zs0J6rZ12GkQYGwbTtzFMbBXeuUmPhr1TFhKXCAkLEIV
> GxBOOJdUvBeEcDwfIje7kQ1x3WdEQnArFFsmahP/N/iboS6nSWfChFJ0wt6MHRgJ
> h6jXn/VoRzNpc6/ONMda7ErvHaDvNA1MGKXIBTO136cfJBv7CoOVGx/22KbDbXy5
> j80NqW3nmOodHZ4IPmSgAV7B4r2ATGS0ki8plMNg/fmzM7ipzbFSl9Vgk0kIGkJq
> hN5OUEz3WBWQE7K1UWDo8O0qW14tJ1lhfu4wDGSEhg2JPM2VkTVxxEciB8D0+tew
> PEVlehCZ/1VJ5LK8irbo0ZcPzhEkI+mVFr+RmwLVvqwnn+0jkw0tUlWrTEhpEK2c
> JkI8rr+ib4409sRZyqrNSpCI8zQZzF8cFFC/dIhr66Q3t2QHDzlayEf+qPDEls2I
> T/qqNILdDtx27r0T86ORRsf2NTTaMKchz1I9YujK730JRDrsIO70rW3bQLfWxlfO
> 6BZuqMhslSnwQ/TWjsAtFS7l9nWxqEJEbDnUxGc6v/JJShBYg+0Rw/Cs1U+4KLI/
> KU4KMqjC186b9QacmduuyTKlhTyWeZJB18sosMDWRgJbCbhR6mzL1oK2vHqG7q1U
> wTIQZWI28s6XP9QbtnsmZdXfSKiYiluWlOEgSMuz7PzB1zrb6O8=
> =97+k
> -END PGP SIGNATURE-

Apologies, missed your post donoban. But looping the backup seems interesting, 
I suppose it must be possible with the decryption too.

-- 
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/d2cdfd3f-bca9-4f7b-99a0-272ebde1dccc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: extract file from image backup

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 2:16:52 PM UTC+1, higgin...@gmail.com wrote:
> Not sure if what I want to achieve is possible but I'll try and summarise 
> below.
> 
> With other distros that I run (WIN10, Ubuntu, Debian) as well as QUBES - I 
> make full disk images using CLONEZILLA and retain them on a spare PC, running 
> as a local server.
> 
> All full disk restores work fine, including QUBES OS - which is now my 
> primary system.
> 
> Ideally I'd like to be able to have access to individual files within the 
> image copies(if needed).
> 
> For DEBIAN, Ubuntu and I assume WIN10(though not really bothered about that) 
> I can go into terminal on my backup PC and key something along the lines of
> 
>   sudo cat /dir-to-images/sdb1.ext4-ptcl-img.gz.* | sudo gzip -d -c | sudo 
> partclone.ext4 -C -r -W -s - -O /dir-to-new-image/hda1.img
> 
> where all the key files take the form sdb1.ext4-ptcl-img.gz.*
> with * being aa,ab,ac etc.
> 
> 
> As long as I've created a restore file first (eg hda1.img in the above 
> example) the above code works fine - and if I mount the hda1.img file, then 
> all my folders and files are accessible.
> 
> I can then recover say an individual file without having to do full disk 
> restore etc.
> 
> IS THIS POSSIBLE WITH QUBES?
> 
> The relevant files take the form sdc1.ext4-ptcl-img.gz.aa (a single file) and 
> lots of files of the form sdc2.dd-img.aa, sdc2.dd-img.ab through to 
> sdc2.dd-img.bd.
> 
> The above instruction works with the sdc1 file and opens up various system 
> files - but I can't do anything to read the sdc2 series of files. 
> 
> Am not sure what to expect if I could get it to work since each VM has its 
> own DOCUMENTS, DOWNLOAD folders etc.
> 
> Is what I want to achieve possible and if so - grateful for any suggestions 
> as to relevant code needed.
> 
> If not - any suggestions about a different approach to a simple "system" 
> backup with access to individual files as needed?

I'm not sure about extracting from the backup (it's probably possible), but you 
can do something else though. 

The concern is full restore, right? 

How familiar are you with the qvm-backup/qvm-backup-restore exclusion or 
inclusion methods? I.e. only backup or restore a single or handful of AppVM's 
without the rest of the system, etc. 

Also are you familiar with qvm-backup/qvm-backup-restore profiles?

I know it's still overkill to restore a full AppVM, having to delete it all 
again after extracting the specific file(s), but if you're not doing this 
already, atleast this can get you halfway there.

For example if you have a work AppVM, you can make a profile for it and do 
frequent backups of just that one AppVM and nothing else, then it'll go pretty 
fast too in encryption/decryption, compared to a full system procedure.

It's not perfect, but maybe it's something?

-- 
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/d066a1a5-e309-4edd-a903-924f497ba727%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] extract file from image backup

2018-02-20 Thread donoban
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/20/2018 02:16 PM, higginsonj...@gmail.com wrote:
> Not sure if what I want to achieve is possible but I'll try and
> summarise below.
> 
> With other distros that I run (WIN10, Ubuntu, Debian) as well as
> QUBES - I make full disk images using CLONEZILLA and retain them on
> a spare PC, running as a local server.
> 
> All full disk restores work fine, including QUBES OS - which is now
> my primary system.
> 
> Ideally I'd like to be able to have access to individual files
> within the image copies(if needed).
> 
> For DEBIAN, Ubuntu and I assume WIN10(though not really bothered
> about that) I can go into terminal on my backup PC and key
> something along the lines of
> 
> sudo cat /dir-to-images/sdb1.ext4-ptcl-img.gz.* | sudo gzip -d -c |
> sudo partclone.ext4 -C -r -W -s - -O /dir-to-new-image/hda1.img
> 
> where all the key files take the form sdb1.ext4-ptcl-img.gz.* with
> * being aa,ab,ac etc.
> 
> 
> As long as I've created a restore file first (eg hda1.img in the
> above example) the above code works fine - and if I mount the
> hda1.img file, then all my folders and files are accessible.
> 
> I can then recover say an individual file without having to do full
> disk restore etc.
> 
> IS THIS POSSIBLE WITH QUBES?
> 
> The relevant files take the form sdc1.ext4-ptcl-img.gz.aa (a single
> file) and lots of files of the form sdc2.dd-img.aa, sdc2.dd-img.ab
> through to sdc2.dd-img.bd.
> 
> The above instruction works with the sdc1 file and opens up various
> system files - but I can't do anything to read the sdc2 series of
> files.
> 
> Am not sure what to expect if I could get it to work since each VM
> has its own DOCUMENTS, DOWNLOAD folders etc.
> 
> Is what I want to achieve possible and if so - grateful for any
> suggestions as to relevant code needed.
> 
> If not - any suggestions about a different approach to a simple
> "system" backup with access to individual files as needed?

I think you could restore /var/lib/qubes/appvms/vm-name/private.img
and mount it as a loop device. Then extract the file you want.

However I don't see too much benefit with your method. Are you getting
your whole hard disk backup on /dir-to-new-image/hda1.img? If yes it's
not very useful for getting then one single file.

I think it's simpler and more efficient just restoring an standard
Qubes backup (only the VM's that you need), start them, move the files
you want outside and remove it.

With Qubes backup you have possibility to restore individual VM's,
integrity check of the backup, possibility of encryption, and also
store related configuration of the vm (firewall, netVM, etc...).
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqMKAkACgkQFBMQ2OPt
CKXgRQ/9Hi8UFzT+vgZ2Zs0J6rZ12GkQYGwbTtzFMbBXeuUmPhr1TFhKXCAkLEIV
GxBOOJdUvBeEcDwfIje7kQ1x3WdEQnArFFsmahP/N/iboS6nSWfChFJ0wt6MHRgJ
h6jXn/VoRzNpc6/ONMda7ErvHaDvNA1MGKXIBTO136cfJBv7CoOVGx/22KbDbXy5
j80NqW3nmOodHZ4IPmSgAV7B4r2ATGS0ki8plMNg/fmzM7ipzbFSl9Vgk0kIGkJq
hN5OUEz3WBWQE7K1UWDo8O0qW14tJ1lhfu4wDGSEhg2JPM2VkTVxxEciB8D0+tew
PEVlehCZ/1VJ5LK8irbo0ZcPzhEkI+mVFr+RmwLVvqwnn+0jkw0tUlWrTEhpEK2c
JkI8rr+ib4409sRZyqrNSpCI8zQZzF8cFFC/dIhr66Q3t2QHDzlayEf+qPDEls2I
T/qqNILdDtx27r0T86ORRsf2NTTaMKchz1I9YujK730JRDrsIO70rW3bQLfWxlfO
6BZuqMhslSnwQ/TWjsAtFS7l9nWxqEJEbDnUxGc6v/JJShBYg+0Rw/Cs1U+4KLI/
KU4KMqjC186b9QacmduuyTKlhTyWeZJB18sosMDWRgJbCbhR6mzL1oK2vHqG7q1U
wTIQZWI28s6XP9QbtnsmZdXfSKiYiluWlOEgSMuz7PzB1zrb6O8=
=97+k
-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/5f949260-d99d-5bb4-0d92-847e13599aad%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] extract file from image backup

2018-02-20 Thread higginsonjim2
Not sure if what I want to achieve is possible but I'll try and summarise below.

With other distros that I run (WIN10, Ubuntu, Debian) as well as QUBES - I make 
full disk images using CLONEZILLA and retain them on a spare PC, running as a 
local server.

All full disk restores work fine, including QUBES OS - which is now my primary 
system.

Ideally I'd like to be able to have access to individual files within the image 
copies(if needed).

For DEBIAN, Ubuntu and I assume WIN10(though not really bothered about that) I 
can go into terminal on my backup PC and key something along the lines of

  sudo cat /dir-to-images/sdb1.ext4-ptcl-img.gz.* | sudo gzip -d -c | sudo 
partclone.ext4 -C -r -W -s - -O /dir-to-new-image/hda1.img

where all the key files take the form sdb1.ext4-ptcl-img.gz.*
with * being aa,ab,ac etc.


As long as I've created a restore file first (eg hda1.img in the above example) 
the above code works fine - and if I mount the hda1.img file, then all my 
folders and files are accessible.

I can then recover say an individual file without having to do full disk 
restore etc.

IS THIS POSSIBLE WITH QUBES?

The relevant files take the form sdc1.ext4-ptcl-img.gz.aa (a single file) and 
lots of files of the form sdc2.dd-img.aa, sdc2.dd-img.ab through to 
sdc2.dd-img.bd.

The above instruction works with the sdc1 file and opens up various system 
files - but I can't do anything to read the sdc2 series of files. 

Am not sure what to expect if I could get it to work since each VM has its own 
DOCUMENTS, DOWNLOAD folders etc.

Is what I want to achieve possible and if so - grateful for any suggestions as 
to relevant code needed.

If not - any suggestions about a different approach to a simple "system" backup 
with access to individual files as needed?






-- 
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/08ed550a-6e46-46a9-880b-c7a79eb4ca84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 10:51:55 AM UTC+1, msg...@gmail.com wrote:
> On Tuesday, February 20, 2018 at 2:49:30 PM UTC+7, Yuraeitha wrote:
> > On Monday, February 19, 2018 at 3:37:39 PM UTC+1, msg...@gmail.com wrote:
> > > On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote:
> > > > On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com 
> > > > wrote:
> > > > > On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com 
> > > > > wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > Is it possible to start all VMs marked as "Start qube automatically 
> > > > > > on boot" on Qubes OS boot and not on user login in Qubes OS?
> > > > > > Is it possible to do it without Qubes OS autologin?
> > > > > > I want to have a working server application on VM on Qubes OS boot 
> > > > > > without the need to login in Qubes OS.
> > > > > 
> > > > > I've enabled autologin and add "xscreensaver-command -lock" in the 
> > > > > Startup Applications as temporary solution, but it's not perfect 
> > > > > because the system is unlocked briefly before xscreensaver will be 
> > > > > locked and it may be exploited.
> > > > 
> > > > I'm no expert, but in order to bypass a Qubes login, isn't this just 
> > > > about changing the PID levels? If this is possible to do without major 
> > > > change in the code, of course. The various processes are ordered in 
> > > > levels, init the root of all levels being 1, and the lowest possible 
> > > > firmware at init 0. While root as an account is disabled by default in 
> > > > Qubes, there should be something akin to root, in a way of "system" 
> > > > processes. So the system processes starts up during boot, which 
> > > > includes all autostart VM's. Which you can see in "sudo journalctl 
> > > > --boot" and adjust it to around the time you booted it up, or a much 
> > > > simpler appoach which is to press the F1 key after LUKS password, which 
> > > > will show you what happens during boot, up until the Qubes login for 
> > > > user sessions. 
> > > > 
> > > > I believe the AppVM's must be partly starting up in the background, but 
> > > > all the user aspects from the user account, did not. For example XFCE4, 
> > > > widgets, notifications, etc. are not bound by system processes, but are 
> > > > bount by the user account processes. 
> > > > 
> > > > If you can change all the processes related to a Qube AppVM, and all 
> > > > the required processes, i.e. by changing them from user processes type, 
> > > > to a system process type, then it may very well fully boot before you 
> > > > type in your password.
> > > > 
> > > > However, you will have no LUKS password, since this cannot be automated 
> > > > even if you use other systems. Essentially, your plan seems like it 
> > > > will fall apart, no matter what you do with current technology, no 
> > > > matter which Linux or system you pick, they are all vulnurable to this 
> > > > issue. Or so it seems, after all, I'm no expert. 
> > > > 
> > > > Essentially, you can probably work around the last Qubes login, but not 
> > > > the first disk encryption login. And even then, putting some of Qubes 
> > > > processes from user to system, may be risky too.
> > > > 
> > > > I'm sorry, but if you look at it from an abstract point of view, no 
> > > > matter how you flip this, it just seems outright impossible if 
> > > > preserving security is your goal. Or did I miss something crucial?
> > > 
> > > Thank you for the suggestion to check the boot process log, the AppVMs 
> > > really are starting up before user login. It seems that when I've tested 
> > > this, the testing AppVM failed to load and I couldn't connect to it. I've 
> > > tried to connect to the ssh service in AppVM, but failed to connect and 
> > > when I've logged in the Qubes OS I've seen the VMs just starting to boot 
> > > from the look of it.
> > > The problem is solved.
> > > 
> > > Regarding the encryption, I'm thinking of using hardware-based full disk 
> > > encryption with the feature to remote unlocking the drive to keep the 
> > > encryption keys away from the Qubes OS hardware. This will avoid the 
> > > threats like meltdown/spectre/IntelME/AMD PSP stealing the encryption 
> > > keys.
> > 
> > @msg...@gmail.com
> > oh interesting, I did not know it was possible to do remote hardware 
> > decryption, I made the mistake expecting it had to be physically at the 
> > server. This is one powerful ability that indeed changes everything. Looks 
> > like it might work after all then, I'm glad its starting to work out for 
> > you.
> > 
> > Apologize for the large post below, but I'd argue I have a solution for you 
> > regarding the RAM issue, but it's a different way of thinking, that's why 
> > it needs to be compiling different pieces of logics together. There are 
> > ways you can raise un-tapped potential for security here if you look for 
> > measures outside the computer itself.
> > 
> > 
> > 
> > 
> > First an established 

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 10:51:55 AM UTC+1, msg...@gmail.com wrote:
> On Tuesday, February 20, 2018 at 2:49:30 PM UTC+7, Yuraeitha wrote:
> > On Monday, February 19, 2018 at 3:37:39 PM UTC+1, msg...@gmail.com wrote:
> > > On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote:
> > > > On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com 
> > > > wrote:
> > > > > On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com 
> > > > > wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > Is it possible to start all VMs marked as "Start qube automatically 
> > > > > > on boot" on Qubes OS boot and not on user login in Qubes OS?
> > > > > > Is it possible to do it without Qubes OS autologin?
> > > > > > I want to have a working server application on VM on Qubes OS boot 
> > > > > > without the need to login in Qubes OS.
> > > > > 
> > > > > I've enabled autologin and add "xscreensaver-command -lock" in the 
> > > > > Startup Applications as temporary solution, but it's not perfect 
> > > > > because the system is unlocked briefly before xscreensaver will be 
> > > > > locked and it may be exploited.
> > > > 
> > > > I'm no expert, but in order to bypass a Qubes login, isn't this just 
> > > > about changing the PID levels? If this is possible to do without major 
> > > > change in the code, of course. The various processes are ordered in 
> > > > levels, init the root of all levels being 1, and the lowest possible 
> > > > firmware at init 0. While root as an account is disabled by default in 
> > > > Qubes, there should be something akin to root, in a way of "system" 
> > > > processes. So the system processes starts up during boot, which 
> > > > includes all autostart VM's. Which you can see in "sudo journalctl 
> > > > --boot" and adjust it to around the time you booted it up, or a much 
> > > > simpler appoach which is to press the F1 key after LUKS password, which 
> > > > will show you what happens during boot, up until the Qubes login for 
> > > > user sessions. 
> > > > 
> > > > I believe the AppVM's must be partly starting up in the background, but 
> > > > all the user aspects from the user account, did not. For example XFCE4, 
> > > > widgets, notifications, etc. are not bound by system processes, but are 
> > > > bount by the user account processes. 
> > > > 
> > > > If you can change all the processes related to a Qube AppVM, and all 
> > > > the required processes, i.e. by changing them from user processes type, 
> > > > to a system process type, then it may very well fully boot before you 
> > > > type in your password.
> > > > 
> > > > However, you will have no LUKS password, since this cannot be automated 
> > > > even if you use other systems. Essentially, your plan seems like it 
> > > > will fall apart, no matter what you do with current technology, no 
> > > > matter which Linux or system you pick, they are all vulnurable to this 
> > > > issue. Or so it seems, after all, I'm no expert. 
> > > > 
> > > > Essentially, you can probably work around the last Qubes login, but not 
> > > > the first disk encryption login. And even then, putting some of Qubes 
> > > > processes from user to system, may be risky too.
> > > > 
> > > > I'm sorry, but if you look at it from an abstract point of view, no 
> > > > matter how you flip this, it just seems outright impossible if 
> > > > preserving security is your goal. Or did I miss something crucial?
> > > 
> > > Thank you for the suggestion to check the boot process log, the AppVMs 
> > > really are starting up before user login. It seems that when I've tested 
> > > this, the testing AppVM failed to load and I couldn't connect to it. I've 
> > > tried to connect to the ssh service in AppVM, but failed to connect and 
> > > when I've logged in the Qubes OS I've seen the VMs just starting to boot 
> > > from the look of it.
> > > The problem is solved.
> > > 
> > > Regarding the encryption, I'm thinking of using hardware-based full disk 
> > > encryption with the feature to remote unlocking the drive to keep the 
> > > encryption keys away from the Qubes OS hardware. This will avoid the 
> > > threats like meltdown/spectre/IntelME/AMD PSP stealing the encryption 
> > > keys.
> > 
> > @msg...@gmail.com
> > oh interesting, I did not know it was possible to do remote hardware 
> > decryption, I made the mistake expecting it had to be physically at the 
> > server. This is one powerful ability that indeed changes everything. Looks 
> > like it might work after all then, I'm glad its starting to work out for 
> > you.
> > 
> > Apologize for the large post below, but I'd argue I have a solution for you 
> > regarding the RAM issue, but it's a different way of thinking, that's why 
> > it needs to be compiling different pieces of logics together. There are 
> > ways you can raise un-tapped potential for security here if you look for 
> > measures outside the computer itself.
> > 
> > 
> > 
> > 
> > First an established 

[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 10:30:45 AM UTC+1, Tim W wrote:
> On Sunday, February 18, 2018 at 3:17:39 PM UTC-5, Yuraeitha wrote:
> > On Sunday, February 18, 2018 at 3:51:00 AM UTC+1, William Bormann wrote:
> > > On a lark, I purchased a Yubico FIDO U2F Security key.  It's an 
> > > inexpensive USB token that can be used for two-factor authentication for 
> > > Gmail and Facebook, among others.  I'd like to use it on my Qubes RC4 
> > > system.
> > > 
> > > I've read the USB documentation, but thought I'd see if somebody else 
> > > running Qubes has managed to get this working as advertised on their 
> > > system. The current path that seems most promising is to bring up 
> > > SYS-USB, but I have some concerns about doing this since my keyboard and 
> > > mouse are both usb devices.
> > > 
> > > Can anyone reply with a "hand waving" set of steps I should follow?  I 
> > > would greatly appreciate hearing your solution.
> > 
> > I did not yet get around to testing it out for locking down Qubes my self 
> > just yet, but there should be quite a lot of people who managed to. 
> > Consider that there are at least a good amount of people wanting this, and 
> > generally you see people posting about whether to do it or not (like your 
> > post), over people who somehow messed it up and are locked out of their 
> > system. 
> > 
> > From that, I'd deduce that it is probably safe. But you may want to do 
> > backup first, at least of your most important AppVM's, just in case 
> > something should go south. You never know, whatever can go wrong, will 
> > eventually go wrong, as the saying goes.
> > 
> > Also for what purposes? LUKS disk decryption? Qubes password login/logout 
> > when insert/retracting the Yubi-key? Third-party services in AppVM's?
> > 
> > But having said that, I doubt it's a big issue, especially not if you 
> > backup first. Also from what I can read, your old password still works, in 
> > case the key isn't working anymore, or is lost/stolen. This isn't a measure 
> > against cracking, but a measure against people looking over a persons 
> > shoulder, or if sitting under a camera, stuff like that where the password 
> > can be stolen. Although of course, it can also servee as a means to 
> > memorize a crazy long strong password with high entropy, which makes 
> > cracking your drive even harder.
> > 
> > Whatever the case, you should probably have a means to remember a long 
> > random password with strong entropy, in case you loose your hardware key, 
> > for example write it on a piece of paper and hide it inside a wall (or 
> > something crazy like that). You can alaos backup the hardware key's seed, 
> > which is recommended in case you loose the key and need a new key with same 
> > 2nd factoring credentials.
> > 
> > Essentially, it likely more boils down to how you handle your key, and how 
> > you prevent loosing it, or exposing it to potential attackers in the 
> > physical world. Just search these google mails, you probably won't find 
> > many having issues, and instead find people asking questions before they 
> > start using it
> 
> 
> I do not think he wants this for qubes luks login or even Qubes user login 
> but for 2 factor auth pin such as google auth or better yet oathtool.  This 
> should be much easier.

oh, you make a good point. I indeed made an assumption that it was about 
lock-out by the "reading guides" line, and I somehow missed the line regarding 
Google and Facebook services. I must then have misunderstood, I apologize. 

I just tested the Yubi key I got laying around, it works in sys-usb, or 
whereever the controller is located, be it dom0 or another AppVM with a working 
USB controller. But it doesn't seem like either the qvm-usb (or its GUI 
counterpart in the menu-widget introduced in Qubes 4, works. At least it 
doesn't appear on my system.

But it works wherever the USB controller is located, just not in the VM's that 
are virtually linked with qvm-USB and the GUI-widget counterpart.

As such, one can probably estimate the Yubi key working, if one has a working 
USB controller to spare, and that USB controller can feasibly be passed 
directly to the AppVM. But it can be tricky to find hardware that allows 
passthrough, especially considering the drivers are often not made for it, as 
well as there aren't terribly many products with multiple controllers on them 
to pick between. On laptops, it's hard to know in advance how many controllers 
there are, as it's not a marketing information, nor something frequently found 
in product reviews, quite frustrating. But if determined, can probably get 
extra USB controllers to spare, but it might be on the expensive side if making 
a mistake, like buying a computer that only had one controller, or the extra 
controller can't be passed through.

But if one has a system with extra USB controllers, and it works to pass an USB 
controller directly into the AppVM (test other USB applications work), then the 
Yubi 

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-20 Thread msgheap
On Tuesday, February 20, 2018 at 2:49:30 PM UTC+7, Yuraeitha wrote:
> On Monday, February 19, 2018 at 3:37:39 PM UTC+1, msg...@gmail.com wrote:
> > On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote:
> > > On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com wrote:
> > > > On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com 
> > > > wrote:
> > > > > Hello,
> > > > > 
> > > > > Is it possible to start all VMs marked as "Start qube automatically 
> > > > > on boot" on Qubes OS boot and not on user login in Qubes OS?
> > > > > Is it possible to do it without Qubes OS autologin?
> > > > > I want to have a working server application on VM on Qubes OS boot 
> > > > > without the need to login in Qubes OS.
> > > > 
> > > > I've enabled autologin and add "xscreensaver-command -lock" in the 
> > > > Startup Applications as temporary solution, but it's not perfect 
> > > > because the system is unlocked briefly before xscreensaver will be 
> > > > locked and it may be exploited.
> > > 
> > > I'm no expert, but in order to bypass a Qubes login, isn't this just 
> > > about changing the PID levels? If this is possible to do without major 
> > > change in the code, of course. The various processes are ordered in 
> > > levels, init the root of all levels being 1, and the lowest possible 
> > > firmware at init 0. While root as an account is disabled by default in 
> > > Qubes, there should be something akin to root, in a way of "system" 
> > > processes. So the system processes starts up during boot, which includes 
> > > all autostart VM's. Which you can see in "sudo journalctl --boot" and 
> > > adjust it to around the time you booted it up, or a much simpler appoach 
> > > which is to press the F1 key after LUKS password, which will show you 
> > > what happens during boot, up until the Qubes login for user sessions. 
> > > 
> > > I believe the AppVM's must be partly starting up in the background, but 
> > > all the user aspects from the user account, did not. For example XFCE4, 
> > > widgets, notifications, etc. are not bound by system processes, but are 
> > > bount by the user account processes. 
> > > 
> > > If you can change all the processes related to a Qube AppVM, and all the 
> > > required processes, i.e. by changing them from user processes type, to a 
> > > system process type, then it may very well fully boot before you type in 
> > > your password.
> > > 
> > > However, you will have no LUKS password, since this cannot be automated 
> > > even if you use other systems. Essentially, your plan seems like it will 
> > > fall apart, no matter what you do with current technology, no matter 
> > > which Linux or system you pick, they are all vulnurable to this issue. Or 
> > > so it seems, after all, I'm no expert. 
> > > 
> > > Essentially, you can probably work around the last Qubes login, but not 
> > > the first disk encryption login. And even then, putting some of Qubes 
> > > processes from user to system, may be risky too.
> > > 
> > > I'm sorry, but if you look at it from an abstract point of view, no 
> > > matter how you flip this, it just seems outright impossible if preserving 
> > > security is your goal. Or did I miss something crucial?
> > 
> > Thank you for the suggestion to check the boot process log, the AppVMs 
> > really are starting up before user login. It seems that when I've tested 
> > this, the testing AppVM failed to load and I couldn't connect to it. I've 
> > tried to connect to the ssh service in AppVM, but failed to connect and 
> > when I've logged in the Qubes OS I've seen the VMs just starting to boot 
> > from the look of it.
> > The problem is solved.
> > 
> > Regarding the encryption, I'm thinking of using hardware-based full disk 
> > encryption with the feature to remote unlocking the drive to keep the 
> > encryption keys away from the Qubes OS hardware. This will avoid the 
> > threats like meltdown/spectre/IntelME/AMD PSP stealing the encryption keys.
> 
> @msg...@gmail.com
> oh interesting, I did not know it was possible to do remote hardware 
> decryption, I made the mistake expecting it had to be physically at the 
> server. This is one powerful ability that indeed changes everything. Looks 
> like it might work after all then, I'm glad its starting to work out for you.
> 
> Apologize for the large post below, but I'd argue I have a solution for you 
> regarding the RAM issue, but it's a different way of thinking, that's why it 
> needs to be compiling different pieces of logics together. There are ways you 
> can raise un-tapped potential for security here if you look for measures 
> outside the computer itself.
> 
> 
> 
> 
> First an established logic analogy that embodies everything below:
> The whole logic below can be summarized as an analogy of the difference 
> between ps/2 and USB. First establishing a logic here through an analogy 
> between USB/ps/2. USB is universal, advanced, and powerful, it can do a lot 

[qubes-users] Re: Qubes OS 4.0RC4 can't get xterm from sys-usb, sys-net, sys-whonix

2018-02-20 Thread Yuraeitha
On Tuesday, February 20, 2018 at 12:24:09 AM UTC+1, wyory wrote:
> Hi,
> 
> I can't get anything to run using 'qvm-run' on the sys-vms (sys-usb,
> sys-net, sys-whonix). Is this intentional? I'd like to get xterm on
> sys-usb to run some disk diagnostics on an external drive using 'smartctl.'
> 
> Any suggestions?
> 
> Using Qubes OS 4.0RC4.
> 
> Thanks in advance.
> 
> -wyory

I use Q4-RC3, so I'm not sure if the smaller variations not included in the 
RC-4 updates makes a difference here on an RC-3 install. No re-install was 
recommended, but there can still be small variations.

For me it works, all commands below work on my Q4-RC3 fully updated system.



Try see if this works for you too in dom0: qvm-run sys-net 'gnome-terminal -e 
xterm' 

You can also try this one if there is something wrong with xterm "qvm-run 
sys-net 'gnome-terminal -e smartctl, your command etc.'

As I recall, Marek was looking to purge some packages during RC-4 compiling, 
because it was just about a bit bigger than what could be fit on a DVD size. So 
some things had to be removed. Perhaps xterm was one of those. Try check if 
it's installed in your template. As far as I know it wasn't removed for 
security reasons, it was size reasons. So I don't think its a problem to just 
manually install it yourself. Assuming, it's gone, it's a guess on my part. 
I've seen others report Thunar missing in dom0 too in RC-4. As far as I 
understand the same goes here, Thunar might just be removed for size reduction, 
and not due to security. Although it's a security concern if users have an 
easier time to access dom0, Qubes 4 seems to be a bit early to remove such 
things just for this. Maybe it could be done in Qubes 5 or Qubes 6, but there 
are still too many things to be done in dom0, just yet. Either way, this might 
explain it if xterm isn't installed, but used to be installed in the past. Try 
check if its there or not.

Another alternative could be to put a script inside your AppVM that does the 
smartctl execution. Then Execute the script with 

qvm-run sys-net 'bash /path/to/script'

If none of this is working, then perhaps something more serious is going on? No 
error messages or such sorts?

-- 
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/732eef5d-386c-487d-8178-45d1358157aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes

2018-02-20 Thread Tim W
On Sunday, February 18, 2018 at 3:17:39 PM UTC-5, Yuraeitha wrote:
> On Sunday, February 18, 2018 at 3:51:00 AM UTC+1, William Bormann wrote:
> > On a lark, I purchased a Yubico FIDO U2F Security key.  It's an inexpensive 
> > USB token that can be used for two-factor authentication for Gmail and 
> > Facebook, among others.  I'd like to use it on my Qubes RC4 system.
> > 
> > I've read the USB documentation, but thought I'd see if somebody else 
> > running Qubes has managed to get this working as advertised on their 
> > system. The current path that seems most promising is to bring up SYS-USB, 
> > but I have some concerns about doing this since my keyboard and mouse are 
> > both usb devices.
> > 
> > Can anyone reply with a "hand waving" set of steps I should follow?  I 
> > would greatly appreciate hearing your solution.
> 
> I did not yet get around to testing it out for locking down Qubes my self 
> just yet, but there should be quite a lot of people who managed to. Consider 
> that there are at least a good amount of people wanting this, and generally 
> you see people posting about whether to do it or not (like your post), over 
> people who somehow messed it up and are locked out of their system. 
> 
> From that, I'd deduce that it is probably safe. But you may want to do backup 
> first, at least of your most important AppVM's, just in case something should 
> go south. You never know, whatever can go wrong, will eventually go wrong, as 
> the saying goes.
> 
> Also for what purposes? LUKS disk decryption? Qubes password login/logout 
> when insert/retracting the Yubi-key? Third-party services in AppVM's?
> 
> But having said that, I doubt it's a big issue, especially not if you backup 
> first. Also from what I can read, your old password still works, in case the 
> key isn't working anymore, or is lost/stolen. This isn't a measure against 
> cracking, but a measure against people looking over a persons shoulder, or if 
> sitting under a camera, stuff like that where the password can be stolen. 
> Although of course, it can also servee as a means to memorize a crazy long 
> strong password with high entropy, which makes cracking your drive even 
> harder.
> 
> Whatever the case, you should probably have a means to remember a long random 
> password with strong entropy, in case you loose your hardware key, for 
> example write it on a piece of paper and hide it inside a wall (or something 
> crazy like that). You can alaos backup the hardware key's seed, which is 
> recommended in case you loose the key and need a new key with same 2nd 
> factoring credentials.
> 
> Essentially, it likely more boils down to how you handle your key, and how 
> you prevent loosing it, or exposing it to potential attackers in the physical 
> world. Just search these google mails, you probably won't find many having 
> issues, and instead find people asking questions before they start using it


I do not think he wants this for qubes luks login or even Qubes user login but 
for 2 factor auth pin such as google auth or better yet oathtool.  This should 
be much easier.

-- 
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/0fcdabba-283b-471c-95ea-9d870ea1f0a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Installing Win7 on a Dell

2018-02-20 Thread Yuraeitha
On Monday, February 19, 2018 at 7:41:55 PM UTC+1, Glen H wrote:
> On Monday, February 19, 2018 at 1:05:09 AM UTC-5, Yuraeitha wrote:
> > On Monday, February 19, 2018 at 6:08:44 AM UTC+1, Glen H wrote:
> > > On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote:
> > > > On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
> > > > > Hi,
> > > > > 
> > > > > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 
> > > > > 4rc4.  I have a Dell e7440 and it doesn't come with a Windows .iso.  
> > > > > Before I installed Qubes I used the Dell recovery tool to create a 
> > > > > recovery usb disk for Win7 to re-install the OS but I'm not sure if 
> > > > > this is usable to install with Qubes.
> > > > > 
> > > > > I tried following the instructions on the Qubes website by creating a 
> > > > > new Qube without a template but I could not change it from PVM to 
> > > > > HVM.  Then when I tried booting from the USB recovery disk it would 
> > > > > load up a terminal and then exit after 10 seconds.
> > > > > 
> > > > > When I try to boot the recovery USB disk from the main BIOS it boots 
> > > > > up fine.  Does anyone have any tips for installing Win7 in Qubes 4?
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Glen
> > > > 
> > > > Hi,
> > > > 
> > > > Check out these two issues:
> > > > Installing Windows 7: 
> > > > https://github.com/QubesOS/qubes-issues/issues/3592
> > > > Installing Qubes Windows Tools: 
> > > > https://github.com/QubesOS/qubes-issues/issues/3585
> > > > 
> > > > The two problems you describe in the post seem to be the following:
> > > > 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
> > > > 2. Make sure you set the video-model to cirrus for install.
> > > > 
> > > > Best,
> > > > Daniel
> > > 
> > > Hi,
> > > 
> > > Thanks for the tips Daniel.  I'm stuck at not being able to boot from the 
> > > usb disk.  I am doing:
> > > 
> > > ```
> > > qvm-create --class StandaloneVM --label red win7new
> > > qvm-prefs win7new virt_mode hvm
> > > qvm-prefs win7new memory 4000
> > > qvm-prefs win7new maxmem 4000
> > > qvm-prefs win7new kernel ''
> > > qvm-volume extend win7new:root 25g
> > > qvm-prefs win7new debug True
> > > qvm-features win7new video-model cirrus
> > > 
> > > # Then attach usb drive to untrusted, but all of these fail to boot:
> > > 
> > > qvm-start --hddisk untrusted:sda win7new
> > > qvm-start --hddisk untrusted:sda1 win7new
> > > qvm-start --hddisk untrusted:/dev/sda win7new
> > > qvm-start --hddisk untrusted:/dev/sda1 win7new
> > > ```
> > > 
> > > I'm not sure whether to use the whole drive (no name) or the first 
> > > partition (named DELLRESTORE)...but I tried both.
> > > 
> > > I get the error message in the win7new terminal:
> > > 
> > > ```
> > > SeaBIOS (version ...)
> > > Machine UUID ...
> > > Booting from Hard Disk...
> > > Boot failed: not a bootable disk
> > > 
> > > Booting from Floppy...
> > > Boot failed: could not read the boot disk
> > > 
> > > No bootable device.
> > > ```
> > > 
> > > So it seems that it doesn't recognize the USB drive as bootable even 
> > > though I can boot it from the main BIOS (in legacy mode).  
> > > 
> > > Any help would be appreciated.
> > > 
> > > Glen
> > 
> > First, welcome to the Qubes community! :)
> > 
> > A few things first, starting to use Qubes can be a bit overwhelming, but 
> > you'll get the hang of it over time if you keep using it. For starters, 
> > look here in the command you use "untrusted:sda" which is something Qubes 
> > exclusive and you therefore had no chance knowing this. Untrusted, is a 
> > word that needs replacing for whichever untrusted AppVM you're using to 
> > hold your USB or SATA controllers. It's called untrusted because dom0 is 
> > trusted, and you need to use an less untrusted domain that doesn't 
> > compromise your more trusted domain, dom0. This is a bit tricky for new 
> > users to catch on, on, as it's ambiguity for new users, at best. To solve 
> > this, then you first need to figure out where your controller is located. 
> > If you have no sys-usb or similar, then it's likely still in dom0. It's 
> > insecure to keep this in the secure dom0 domain, but mostly you should be 
> > fine for some time yet if you're not a high target profile, and never leave 
> > your computer unattended in public or near people you don't trust with your 
> > life. Still, having it in dom0 is still more secure than not using Qubes. 
> > Just keep in mind you eventually want to migrate away from using dom0 for 
> > anything, but it's not always easy just yet due to some fixes and hardwares 
> > require you still manually manage dom0 from time to time, so it's not yet 
> > entirely a users responsibility, as there are still times when you need to 
> > use dom0.
> > 
> > So if your USB or SATA controllers are in dom0 (Your SATA controllers will 
> > be if you did not move them yourself, and USB controllers depend on your 
> > hardware, the 

[qubes-users] Re: Installing Qubes 4 with petitboot

2018-02-20 Thread Tim W
On Monday, February 19, 2018 at 1:25:51 PM UTC-5, qube...@go-bailey.com wrote:
> I have a new KCMA-D8 based machine with petitboot installed. When I 
> attempt to boot from the Qubes 4 DVD, the install media is not 
> recognized by petitboot. Other installation media that I've tried, like 
> a Ubuntu CD, are recognized and I'm able to boot.
> 
> I've attempted to boot using a new manual entry in petitboot.
> 
> That has been somewhat successful as I've been able to get to the Qubes 
> loading screen but eventually it just stops loading (no errors, etc.).
> 
> I suspect the problem is having the proper entires in my manual entry.
> 
> Currently I have:
> 
> kernel - /isolinux/vmlinuz
> initrd - /isolinux/initrd.img
> boot arguments - append xen.gz console=none --- vmlinuz 
> inst.stage2=hd:LABEL=Qubes-R4.0-rc4-x86_64 i915.preliminary_hw_support=1 
> quiet rhgb --- initrd.img
> 
> based on what I could find in the DVD's isolinux folder.
> 
> Not sure if that is what should be used. Can anyone with a KCMA-D8 or 
> similar setup with petitboot shed any light?
> 
> Thanks in advance.

Did you try a different install DVD not CD?  I ask as I recall a fedora bug 
from awhile ago (fc21 2014/15ish) with petitboot where it would not recognize 
specifically a DVD install media to show up in the boot list.  It had to be 
done manually as you have done.  It has to do with how it reads grub.  It did 
not have support ['FOR' loops] in grub.conf/grub2.conf

This at least would confirm if the issue is specific to Qubes installer which 
is just a slightly modified anaconda installer i.e. fedora SOP (less likely) or 
an issue with petitboot handling of DVD mentioned above.

Here is what is needed to be added to petitboot code and speaks to the issue:

http://git.ozlabs.org/?p=petitboot;a=commit;h=1b272c7d47390077eee0a0638329b1a7df521329


What version of petitboot do you have?  It should print something like this: 
dev.20141013 or maybe 32e2eac7  ?  You could look to confirm you are using a 
version that had these changes applied.  Confirm those additions were actually 
add as well.  I only looked quickly so did not confirm.

I know you maybe set on DVD for a some reason i.e. extra security; but honestly 
USB has for years been the most trouble-free way to install Qubes.


Sorry I can not be more help but you could check the grub.conf from a USB 
install stick after you confirm it works for your setup and does not fail at 
same point

-- 
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/13d0fd7a-2b94-42fe-94c9-d16903880baa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.