[qubes-users] Re: Installing Qubes 4 with petitboot
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.
[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes
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: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install
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. > >
Re: [qubes-users] extract file from image backup
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.
Re: [qubes-users] extract file from image backup
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.
Re: [qubes-users] How to delete or upgrade app VMs?
-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?
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.
[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes
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: Qubes OS 4.0RC4 can't get xterm from sys-usb, sys-net, sys-whonix
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: Start VMs on boot before user login (Qubes OS 4.0rc4)
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: Installing Win7 on a Dell
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: Yubico FIDO U2F Security Key and Qubes
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: Installing Qubes 4 with petitboot
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.
[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)
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)
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] extract file from image backup
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.
Re: [qubes-users] extract file from image backup
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.
Re: [qubes-users] QSB #38: Qrexec policy bypass and possible information leak
-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.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
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
-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] Re: extract file from image backup
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
> > 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.
[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)
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
-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
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] USB VM based on fedora-26 doesn't pass block devices
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] HTTP proxy & firewall woes
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
Re: [qubes-users] extract file from image backup
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] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
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: qrexec policies broken after QSB #38 update
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
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.
Re: [qubes-users] qrexec policies broken after QSB #38 update
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.
Re: [qubes-users] extract file from image backup
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.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-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] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
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
[qubes-users] Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install
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: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install
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
[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes
> 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.
[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install
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
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
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
Re: [qubes-users] qrexec policies broken after QSB #38 update
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.
