[qubes-users] How does Qubes DNS resolving work?
When I look at /etc/resolv.conf in the following VMs it says different things: 1) Normal AppVM: nameserver 10.139.1.1 nameserver 10.139.1.2 2) Sys-firewall VM: nameserver 10.139.1.1 nameserver 10.139.1.2 3) Sys-net VM: [actual resolvers] The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net However, what I don't undersatnd is that 10.139.1.1 does not exist. That is not the IP address for any VM on the network. This can be verified in Qubes Manager looking at the IP column. In addition, 10.139.1.1 refers to different VMs depending on the VM sending the packets. In AppVM it routes to sys-firewall. In sys-firewall it routes to sys-net. So, my question is how does all of this work? Where exactly does any request to 10.139.1.1 route to the actual connected VM. Looking at IP table rules I do not see where traffic sent to 10.139.1.1 goes to [sys-firewall IP here] for example. It appears to be doing it all magically, so where is the magic? -- 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/LYegJve--3-1%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Valid Concerns Regarding Integrity of Whonix Project
Are canaries now "illegal" in Aussi law as well ??? On 2/14/19 3:26 PM, teresardavida...@gmail.com wrote: Summary: I have reason to believe the possibility that Mig5 (the new SysAdmin on Whonix project) could be compelled under federal law to provide assistance is high and the threat to the security and anonymity offered by the project could be compromised as a result is also high. I recently visited the Whonix community website for an unrelated purpose and discovered something that I think in honest to good faith deserves public discussion. I was alarmed and shocked to see my post abruptly deleted and my account permanently disabled. I would like to post my thoughts here to the Qubes User community for further scrutiny and discussion and perhaps maybe get the attention of the project maintainer who I do see regularly participate on this channel. Below is a copy paste of the submission which was deleted from the Whonix community forum. [Quote] This post is in no way doubting the integrity or calling into question the character of Mig5 the new sysadmin for the whonix project. But I do feel it is necessary to point out that the new sysadmin is Australian (or resides in Australia). Under Australian law, he can be compelled through threat of imprisonment to cooperate with the Australian government. This law is designed to compel individuals that work on projects such as Whonix to insert or write code that permits lawful access. If a person is served with such enforcement, they are required to keep it secret or risk imprisonment. This law was only recently introduced and is already being used to great effect according to recent reports. While Whonix is an open-source project it is important to remember that open source does not imply greater security. One only needs to consider one of the most widely used and scrutinized open source projects (OpenSSL) had a backdoor that went undetected for several years. It was just two lines of code. It literally broke the internet. I deeply regret having to bring this to the attention of the community please do not interpret my thoughts here as a question of Mig5's character. I value all contributions but believe the circumstances and severity of the consequences warrant public discussion. The bottom line is, as the law is written, he would be required to cooperate and in secret. I think someone like him, in a position he now occupies, represents a textbook example of why this law was written in the first place. In my opinion, it is not a question of "if" he is compelled but rather just a matter of "when". Unfortunately it is not uncommon for Whonix to be encountered by forensic analysts who have the regrettable job of investigating computer equipment seized by suspects charged with child abuse related offenses. At least not in Australia. I can say with certainty this project already has high visibility among specific cyber investigative divisions within both state and federal AG. I do not have any classified information I can share and if I did I would not share it but I can provide some information in private to Patrick that taken to its logical conclusion would suggest this project is likely to be a high priority target for these new laws. [/Quote] -- 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/813b6040-c999-105e-bf43-ef5999506e43%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Valid Concerns Regarding Integrity of Whonix Project
Summary: I have reason to believe the possibility that Mig5 (the new SysAdmin on Whonix project) could be compelled under federal law to provide assistance is high and the threat to the security and anonymity offered by the project could be compromised as a result is also high. I recently visited the Whonix community website for an unrelated purpose and discovered something that I think in honest to good faith deserves public discussion. I was alarmed and shocked to see my post abruptly deleted and my account permanently disabled. I would like to post my thoughts here to the Qubes User community for further scrutiny and discussion and perhaps maybe get the attention of the project maintainer who I do see regularly participate on this channel. Below is a copy paste of the submission which was deleted from the Whonix community forum. [Quote] This post is in no way doubting the integrity or calling into question the character of Mig5 the new sysadmin for the whonix project. But I do feel it is necessary to point out that the new sysadmin is Australian (or resides in Australia). Under Australian law, he can be compelled through threat of imprisonment to cooperate with the Australian government. This law is designed to compel individuals that work on projects such as Whonix to insert or write code that permits lawful access. If a person is served with such enforcement, they are required to keep it secret or risk imprisonment. This law was only recently introduced and is already being used to great effect according to recent reports. While Whonix is an open-source project it is important to remember that open source does not imply greater security. One only needs to consider one of the most widely used and scrutinized open source projects (OpenSSL) had a backdoor that went undetected for several years. It was just two lines of code. It literally broke the internet. I deeply regret having to bring this to the attention of the community please do not interpret my thoughts here as a question of Mig5's character. I value all contributions but believe the circumstances and severity of the consequences warrant public discussion. The bottom line is, as the law is written, he would be required to cooperate and in secret. I think someone like him, in a position he now occupies, represents a textbook example of why this law was written in the first place. In my opinion, it is not a question of "if" he is compelled but rather just a matter of "when". Unfortunately it is not uncommon for Whonix to be encountered by forensic analysts who have the regrettable job of investigating computer equipment seized by suspects charged with child abuse related offenses. At least not in Australia. I can say with certainty this project already has high visibility among specific cyber investigative divisions within both state and federal AG. I do not have any classified information I can share and if I did I would not share it but I can provide some information in private to Patrick that taken to its logical conclusion would suggest this project is likely to be a high priority target for these new laws. [/Quote] -- 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/70bbe370-1a34-4ada-8377-48c80360393e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qvm-copy-to-vm question
On 2/13/19 3:18 PM, 'awokd' via qubes-users wrote: Todd Lasman wrote on 2/13/19 1:58 AM: I'm not sure if I'm doing this correctly. According to the usage, the syntax is: qvm-copy-to-vm destination_qube_name FILE This is for copies from dom0 only. When I do this, I get a dialog that asks me which qube I want to copy my file to. Why have this, if I already specified it in the command line? Is there a way to suppress the dialog? And if not, what's the purpose of having the destination_qube_name in the command line in the first place? 3.2 used to permit the destination_qube_name in there, but 4.0+ doesn't. I'm told that some use qvm-copy instead of qvm-copy-to-vm. Whenever I use the qvm-copy command (with the destination qube and the file to copy) I always get the error message "Can't stat destination_qube. File or directory doesn't exist (or something like that)" All I want to do is copy a file from one qube to the next without hassle. Suggestions? From a terminal session inside the source qube, use "qvm-copy [filename]". It will then prompt for the destination qube. Ok. Thanks for the explanation. Still doesn't seem right to me, though. I think I should be able to do the whole copy/move with one command, rather than two. Todd -- 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/121c723b-f734-dd12-7073-f2cb6a86ca2f%40nowlas.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 13, 2019 at 08:42:10AM -0800, simon.new...@gmail.com wrote: > In 3, if i clicked on "block connections" in the Qubes manager firewall > section, there was (if memory serves me) an option to block DNS and ICMP. > > That is not present in R4 (though docs say you can disable DNS and ICMP > manually) > > I'm just wondering what the logic behind the removal was? I would have > thought that a general user who clicks "block connections" on Qube would not > expect the qube to be able to actually send out and receive network packets > such as DNS or ICMP. This presents information leakage scenarios (default DNS > lookups of given qube) and also potential egress vectors if a qube is ever > compromised (DNS tunnelling, ICMP tunnelling). Let me quote full text you can find on firewall tab there: NOTE: To block all network access, set Networking to (none) on the Basic settings tab. This tab provides a very simplified firewall configuration. All DNS requests and ICMP (pings) will be allowed. For more granular control, use the command line tool qvm-firewall. There is clear message what to do if you want to cut the qube from the network. - -- 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/THMrX1ywFAlxk5lQACgkQ24/THMrX 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3 HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1 EKOq9FhCjMI6De6nNgiMf63Y47CxuQ== =9dvG -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/20190214035356.GD9610%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Qubes 4.x Backup setting should not be set to save (replace) default settings by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This thread might be better located in qubes-users. On 2/13/19 9:49 AM, Teqleez Motley wrote: > a) Where exactly does qubes save this password/backup settings > (file+folder, please) /etc/qubes/backup/qubes-manager-backup.conf > b) It seems to be ticked by default (per 4.0.1-RC/December, not > the latest bugfix which I am about to prepare to upgrade to...), in > case that is not changed this last month, isn't that default > setting actually bad (for the personal...) security? It depends... one could argue that if an attacker has *any* access to dom0 it's game over. So unless you tend to leave your PC unlocked and walk away ... in which case the saved backup password should be the least of your issues. /Sven -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlxkq9MACgkQ2m4We49U H7ZoCQ/9HYPWOrBeiUxwSEQeqs4+Tm6QXp2ix8KmX9PNQZ2HQhmd/2EzER99VdSO B4obqlPdLc0Hr86RtwJbMFXrTjFe7HaM8ujMJPjVsvPZkEdpsMSlxZOLGDG6geL5 AYnr+ypRFJvguucSK6/CdoYj50N2wYZVxSieBHv4vVy2RO9T5bz/ihWu5EehsURs 5aV1iEqhMfi3t3qhxKdKQUyPMW9OqHcmOoHb+mFX/TCRgYIFKWbsjHq7Vi4fG9iz 8lwfKzDewoVkDyvZPjZMSRxmUf7Wop3+yzHjNsqlIrA98XnrxNBupF9PkfzoU3yl zRjJREnQ+QDcv8ivoW7WXhSxY0gBBYj9Kk8B6/XJe5ERXYPmDUdzw/YxBHJJx5q2 BSDSZHCjw++JvwyhRzPdtJAyQixa/JhwsdIz0Q1aYMEDo9kSfESXhIxH1UEJrRnv QzJcHvHtknu/W+8W9Fo9IQsi9+jhgEl/uh+qwyaxPG0DsCa/uQ7TZ+ywLCnmed4d eEUpj/A4My5O7WM17eVuU9rFo+ZQPGquqPqE0Gl0xwlSfxFsvLieS2NEfSL/M3rr +jNl/TogUM0h2bMV3W/zU5wXGj+2ZeL/nkq3kinrL75IdnJMqhdlfjgGOeg0XgkB p9Rm7ghegDcY2/dvDNRu1uN1HDaZb+5kSWEdlzgr2I6JWt6azdg= =MaKW -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/1f1a5b54-ec17-41c9-9bdc-f6383e6245a1%40SvenSemmler.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Black screen when booting Qubes 4.0.1 installer via usb
Dan Grant wrote on 2/13/19 7:20 AM: I am able to comment out the mapbs and noexitboot lines in the [qubes-verbose] section of EFI/BOOT/BOOTX64.cfg, but it is not at all clear what is meant in step 2 of this section: https://www.qubes-os.org/doc/uefi-troubleshooting/#change-installer-kernel-parameters-in-uefi what the following means exactly: "Edit your xen config (xen.cfg/BOOTX64.cfg) changing the kernel key to add your kernel parameters on the boot entry of your choice" Specifically this bit: "...changing the kernel key to add your kernel parameters on the boot entry of your choice" Does it mean something more than commenting out the mapbs and noexitboot lines in the [qubes-verbose] section? Not for what you're trying to do- just commenting those lines out should have done it. I'm guessing yes, as I get the same results booting the modified usb installer (black screen with the text shown above), but I can't find any indication what the "kernel parameters" I need to add might be, where I'd find them, or where I'd add them... ps - I'm attempting to install on a new System76 Galago Pro laptop with Insyde HxBios firmware, 8th gen I5 chip, & 32GB RAM Does it have an nvidia card? Those cause problems sometimes. Otherwise, check this out- might be complex to get Qubes installed on that laptop: https://www.mail-archive.com/qubes-users@googlegroups.com/msg13362.html. -- 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/25300da2-05d5-99d1-f087-cff3802a09f4%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qvm-copy-to-vm question
Todd Lasman wrote on 2/13/19 1:58 AM: I'm not sure if I'm doing this correctly. According to the usage, the syntax is: qvm-copy-to-vm destination_qube_name FILE This is for copies from dom0 only. When I do this, I get a dialog that asks me which qube I want to copy my file to. Why have this, if I already specified it in the command line? Is there a way to suppress the dialog? And if not, what's the purpose of having the destination_qube_name in the command line in the first place? 3.2 used to permit the destination_qube_name in there, but 4.0+ doesn't. I'm told that some use qvm-copy instead of qvm-copy-to-vm. Whenever I use the qvm-copy command (with the destination qube and the file to copy) I always get the error message "Can't stat destination_qube. File or directory doesn't exist (or something like that)" All I want to do is copy a file from one qube to the next without hassle. Suggestions? From a terminal session inside the source qube, use "qvm-copy [filename]". It will then prompt for the destination qube. -- 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/9efba8e0-a757-609f-afdc-de377fb7210c%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] AEM/HEADS and disk encryption
Frank Beuth wrote on 2/12/19 5:07 AM: Forgive me if this should be obvious, but: when using an anti-evil-made technology like Qubes AEM or HEADS, the disk encryption key is stored in the TPM. The TPM then decides to release it (or not) according to PCRs it receives. What happens if the system configuration (and the PCRs) legitimately change? How does one boot the machine, is it necessary to keep a copy of the disk encryption key somewhere safe? Or, am I not correctly understanding how these things work? The AEM readme (https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README) has a pretty straightforward procedure for configuration changes. Not exactly sure about motherboard swaps, though. For Bitlocker, you need to do something like "You just enable and clear the TPM from the BIOS on the new motherboard. Then boot the OS by typing the Recovery Password. Then add the TPM as protector. This will populate the keys in the TPM so that you can start from the TPM next time you boot the system." Some text in the AEM readme makes it look like that might happen automatically once you enter the decryption password. -- 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/06d0fef1-f944-97d4-e563-40e730b7356c%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Need guidence on setup Yubikey OTP to login webmail
monday123...@scryptmail.com wrote on 2/12/19 9:06 PM: Hello All,I'm using Qubes 4.0,w ant to setup Yubikey's OTP function to login webmails,having read quite a few posts here and Qubes document,I wan to know that,is there a way of use Yubikey as OTP to login webmail WITHOUT change anything on dom0,I understand that at this instance yubikey act as HID, a keyboard, an input device,so it needs dom0 to allow it,but on the other hand, there is no 'input' at here, plus chang anything in dom0 could be risky,so I don't want to use that approch.is there any other way? like:Use a standalone vm?Or a virtual box in a vm?or a none-qubes tempalte?or any other creative ways?Thank you for your advice, if it's a bit advanced, please kindly give some description, thanks again. If I remember those posts right, all you have to change in dom0 is a permissions file. That should be OK. If you still want to contain Yubikey to a single qube and you also have a spare USB controller, you should be able to set up an HVM with internet, attach that USB controller to it and use Yubikey directly. The trade-off is you bypass some of Qubes' security with that approach. -- 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/e1547bdb-035d-eb5d-0c46-29efa64e0517%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Which default settings have loose security? (InputMouse, VMShell on DispVMs, …)
Chris Laprise wrote on 2/11/19 7:51 PM: I would also move most VM functions to Debian. Despite recent drama over apt, its still more secure overall than Fedora. The latter is uniquely deprived of proper repository signatures to satisfy Red Hat's marketing department... its been a long-term thorn in Qubes' side. Could one say apt's security lapse is Fedora's every day? :) -- 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/5726f17d-cf76-8576-9a53-4cc434ca6570%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0.1 fails to install on dell latitude e5xxx
jonull...@gmail.com wrote on 2/9/19 6:32 PM: Den torsdag 7 februari 2019 kl. 06:51:24 UTC+1 skrev awokd: jonull...@gmail.com wrote on 2/6/19 8:43 PM: Installing works in Legacy External device boot ->sh-4.3# efibootmgr EFI variables are not supported on this system. trying to allocate efivars, but cannot find it, and a few grubs directories. From what i understand it's not necessary to run grubs in UEFI. Having a bit of trouble following what you wrote. If you installed in Legacy mode, Qubes will use Grub to boot instead of UEFI, so there wouldn't be a xen.cfg or EFI menu entry/variables. Did you notice on the first Qubes install stage which boot system it installed, and were there any errors? I am trying to install Qubes. It's a Dell Latitude newer model, which means it does not have Legacy mode, the reason for that is because Dell is trying to make Legacy Mode EOL. Legacy Exteranl Devices does exist though. If i am runing Qubes in UEFI mode i gett 4 penguin error. So i tried to run Qubes install from Legacy External Devices, and then go in to anaconda mode, and following the troubleshooting from Qubes page. The reason why i go in to anaconda mode to follow the troubleshooting for UEFI at qubes page, is because when Qubes installation is finished and i press the reboot i get the 4 penguin error. On the part 4. i try out the: efibootmgr and i recieve the error: EFI variables are not supported on this system. And the answer to your question is no i do not get any errors rather than those Pinguens in UEFI mode installation. Can you try the steps under https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda-qubes-40 ? I don't think you can do a legacy boot from USB in order to fix UEFI issues. -- 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/4defdca1-7a7f-92be-e6b1-a2abb387fce6%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How secure is google-authenticator as second or multiple factor authentication?
Hi Qubes fellows,On reading content on 2FA, and Qubes doc on MFA, there is something confuse me, so I'd like to understand better by posting here:One type of OTP,a TOTP used widely like google authenticator, bases on a shared secret key,since key can be seen in mail box, it's not quite safe, is it saved in mail box as well?(does it also travel on internet? which makes it even worse?)a U2F software can do it's work without this app, so it doesn't look like a good choice.If this is the case, why so many web mail even some promising ones still chose google-authenticator as 2FA?Although gmail itself can add yubikey as enhence for TOTP, I don't see how that's safer.because with or without press the yubikey button, an U2F software can generate same 6-digit-number as password to enter here.Today most of webmails would say they use 2FA, but not introduce in detailswhich protocol it uses. some claim it use yubikey, so is OTP here that use key pair instead ofthe shared secret key? which is muc h better.I don't find many webmail use Yubikey as 2FA on OTP,if any of you find something is rather reliable,recommend very welcome, thanks a lot. -- 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/201902132114.x1DLE1Um023591%40api2.scryptmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Is it safe to install Qubes4 on laptop used windows10 before?
Hello All,I have a laptop from family that is rarely used,but with windows10 installed on it,arguably the most infamous windows version.If I install Qubse4.0 on this laptop, would qubes completely wipe windows10 away? Since some hardware's ID numbers are registered with microsoft in update process,and maybe even UUID, would microsoft still be able to track this laptop when it's online?Second option, is to take off the harddrive with windows10 and change to a completely new one purely for qubes. with the concern above still there-the hard ware records---can microsoft track THIS laptop when it's online?* by installed with windows 10 ---I mean it pressed the agree button on microsoft agreement when new laptop switched on, this stage is offline, and pressed 'update' button, and fully updated with microsoft and registered with it, this part is online.Please advise, thank you -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/201902132055.x1DKt10X013724%40api2.scryptmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?
In 3, if i clicked on "block connections" in the Qubes manager firewall section, there was (if memory serves me) an option to block DNS and ICMP. That is not present in R4 (though docs say you can disable DNS and ICMP manually) I'm just wondering what the logic behind the removal was? I would have thought that a general user who clicks "block connections" on Qube would not expect the qube to be able to actually send out and receive network packets such as DNS or ICMP. This presents information leakage scenarios (default DNS lookups of given qube) and also potential egress vectors if a qube is ever compromised (DNS tunnelling, ICMP tunnelling). TIA -- 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/8dc8dbdf-251b-47dc-94fb-6aaa04d133ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QSB #46: APT update mechanism vulnerability
Since Qubes 4.0.1 was released [1] before your message and before the DSA [2], I assume it is not a good idea to install Debian and Whonix from the 4.0.1 installation media, is it? If it is right, then I suggest adding a note on the download page [3] until 4.0.2 release. Regards, Vít Šesták 'v6ak' [1] https://www.qubes-os.org/news/2019/01/09/qubes-401/ [2] https://www.debian.org/security/2019/dsa-4371 [3] https://www.qubes-os.org/downloads/ -- 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/a232d218-afb4-47c5-a3f2-bacd702731bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] OS rescue in Q4.0.1
Hello, in Q3.2, there was an option to boot system rescue from the installation media. In Q4, there is no longer such option. However, as MarMarek has mentioned, we can use Ctrl+Shift+F2 and commands “killall -9 anaconda; anaconda --rescue”.* This really launches the rescue. I understand why this became harder and so far, it is OK. When I run the rescue, it asks me for my password. Then, it usually fails after taking much time. Usually, I can see that the LVM has appeared there (so the LUKS is decrypted and the password was obviously correct). I can switch to another console and mount root from there. But I wonder why it does not work straightforwardly. Regards, Vít Šesták 'v6ak' *) Have you tried Googling for “anaconda rescue”? ;) -- 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/19e38941-aec8-4adb-9802-b85ad376fb71%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
