Re: [qubes-users] Anyone gotten bitcoind to install via snapcraft on an AppVM?
On Tue, Mar 03, 2020 at 11:17:53AM +, qubenix wrote: That's true, but using a pruned bitcoind will limit its usefulness as a backend for other software (eg. electrum servers, block explorers). You may be able to use it for a specific purpose (eg. joinmarket), but the point of my guides is that you can keep adding new software that comes out (eg. btcpayserver, lnd, c-lightning, esplora) and connect it to your bitcoind VM without having to reindex the chain. Makes sense. - it would be really nice to use bind-dirs to avoid creating a second Whonix WS templateVM (which takes up lots of disk space) -- unfortunately I haven't figured out how to create a new user and keep that user persistent (see prior email) This is a good point. Unfortunately I don't have a lot of extra time/motivation currently to make sweeping changes like that. That's why my btcpayserver branch hasn't been worked on since November. Yes, I tried to do it (see earlier email in this thread) but it's not quite trivial. Bind-dir'ing /etc/passwd and related files seemed to break `adduser`. It's nice to know that someone somewhere is paying attention to work I've done with these. Thank you for that. Thank you for doing them! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305131523.GA1307%40danwin1210.me.
Re: [qubes-users] Manual VPN installation issues
On Tue, Mar 03, 2020 at 09:18:54AM -0500, Chris Laprise wrote: Assuming nothing's terribly wrong, it may be worth posting your public key fingerprint used for code signing somewhere! The B281C952 key is a subkey of F07F1886; Import both and the former will be listed under the latter. Ok, thanks for clarifying! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305131627.GB1307%40danwin1210.me.
Re: [qubes-users] Building an X-230 into a Qubes machine.
On Wed, Mar 04, 2020 at 04:51:38AM -0800, ggg...@gmail.com wrote: As I could not afford a Privacy Beast, I bought a refurbished X-230 Core I5, 4 GB RAM to convert on my own. Soon I will get the 16 GB of RAM to put into it. I am looking to buy a ch-431a to program it from Amazon. I know the guys at Insurgo list on they use from China, but right now, I am not much interested in ordering one delivered from China. Not sure when it would be delivered, and whether I want it into my house. Most of these products come from China. If you use a Raspberry Pi then it comes from the UK, I think. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305131754.GC1307%40danwin1210.me.
Re: [qubes-users] Why not make it possible to use a custom key combination for changing the keyboard layout when installing Qubes OS ?
On Thu, Mar 05, 2020 at 03:33:54AM -0800, A wrote: When installing Qubes OS, it’s possible to choose between some predetermined key combinations for changing the keyboard layout. Why not also make it possible for the user to make his or her own key combination for changing the keyboard layout when installing Qubes OS ? I still haven't figured out how to change the key combination once the install is complete... -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305131950.GD1307%40danwin1210.me.
Re: [qubes-users] Obtaining genuine Qubos installer
On Thu, Mar 05, 2020 at 06:33:38PM +, Mark Fernandes wrote: By the way, I consider that I am being completely reasonable with my threat model, whilst also employing critical thinking. How hard is it to go to a large PC store, and pick at random one Linux distribution, to take home, to better ensure you have system integrity? Sounds like the solution is pretty easy: go to a large PC store, buy a PC and pick a random Linux distribution off the shelf, then use all that to do your verifying. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200307145241.GA1104%40danwin1210.me.
Re: [qubes-users] Why not make it possible to use a custom key combination for changing the keyboard layout when installing Qubes OS ?
On Tue, Mar 10, 2020 at 11:58:21AM -0700, 'M' via qubes-users wrote: torsdag den 5. marts 2020 kl. 14.19.59 UTC+1 skrev tetra...@danwin1210.me: On Thu, Mar 05, 2020 at 03:33:54AM -0800, A wrote: >When installing Qubes OS, it’s possible to choose between some predetermined key combinations for changing the keyboard layout. > >Why not also make it possible for the user to make his or her own key >combination for changing the keyboard layout when installing Qubes OS ? I still haven't figured out how to change the key combination once the install is complete... You can't. It's made as so as a security measure. This makes no sense to me. The Qubes security model is that dom0 is assumed clean, and if dom0 is compromised the whole machine is compromised. How would making it impossible to change the key combination from dom0 improve security? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200313184016.GA2050%40danwin1210.me.
[qubes-users] Cloning a DVM: some apps don't start disposably
I have a dispVM `my-dvm` where everything works as it should: if I open Firefox, that Firefox instance starts in a new disp VM. I want to clone that dispVM and create a new dispVM connected to a different network-providing VM, so I do exactly that: clone `my-dvm` and set the netVM for `my-new-dvm` to `my-other-netvm`. When I start XTerm in `my-new-dvm` the new XTerm window starts in a disp disposable VM, as it should. When I start Firefox in `my-new-dvm`, however, Firefox starts up in the underlying `my-new-dvm` template, not in a disp disposable VM. This means that the Firefox browsing history and prefs are saved, any malware gets to persist, etc. Comparing the output of `qvm-prefs my-new-dvm` and `qvm-prefs my-dvm`, all settings are identical except for things that should obviously be different (the netvm, the GUID, the IP address, etc). Any idea what the problem could be? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200327090912.GA1402%40danwin1210.me.
Re: [qubes-users] Cloning a DVM: some apps don't start disposably
On Fri, Mar 27, 2020 at 09:09:12AM +, tetrahedra via qubes-users wrote: I have a dispVM `my-dvm` where everything works as it should: if I open Firefox, that Firefox instance starts in a new disp VM. I want to clone that dispVM and create a new dispVM connected to a different network-providing VM, so I do exactly that: clone `my-dvm` and set the netVM for `my-new-dvm` to `my-other-netvm`. When I start XTerm in `my-new-dvm` the new XTerm window starts in a disp disposable VM, as it should. When I start Firefox in `my-new-dvm`, however, Firefox starts up in the underlying `my-new-dvm` template, not in a disp disposable VM. This means that the Firefox browsing history and prefs are saved, any malware gets to persist, etc. Comparing the output of `qvm-prefs my-new-dvm` and `qvm-prefs my-dvm`, all settings are identical except for things that should obviously be different (the netvm, the GUID, the IP address, etc). After further testing, the problem does not appear when cloning a Whonix workstation dispVM -- the problem only appears when cloning a Fedora-based dispVM. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200331213554.GA1071%40danwin1210.me.
[qubes-users] Making boot-from-CD permanent for an appVM
Is it possible to make the `--drive` option for `qvm-start` permanent? For example, to configure a Tails AppVM with no persistency but also without creating a separate TemplateVM, DispVM template, and then DispVM. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200419102746.GA1095%40danwin1210.me.
[qubes-users] Salt worm
Qubes uses Salt, and there's something nasty going around: https://saltexploit.com/ -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200506055615.GA1083%40danwin1210.me.
Re: [qubes-users] Salt worm
On Wed, May 06, 2020 at 02:17:15PM +0100, unman wrote: Salt is used to provision the qubes at initial install - I'd also argue that you *should* use salt to set up and control your templates and qubes, since it allows you to rebuild your system automatically. No more trying to remember what packages you installed in a template, or how you set up a particular qube. That sounds excellent. I've never used Salt. Is there a writeup anywhere explaining how to use it for setting up & controlling templates? In Qubes, by default, there is one minion, in dom0, which isn't networked. So there is no scope for this vulnerability to impact the salt configuration that Qubes uses, and to undermine the security of dom0. Great, thanks for clearing this up! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200506164258.GA2789%40danwin1210.me.
Re: [qubes-users] Salt worm
On Fri, May 08, 2020 at 02:29:02PM +0100, unman wrote: If there is a basic writeup out there with examples how to automate tempalte setup for Qubes ... that would be really great. I ran some training a few years back, and the notes are here: https://github.com/unman/notes/tree/master/salt Thanks! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200515181443.GA1086%40danwin1210.me.
Re: [qubes-users] Hallo, es kann langsam losgehen mit Qubes Deutschland Forum, sowie mit der Software Übersetzung in deutsche Sprache
On Fri, May 15, 2020 at 10:27:06AM -0700, wirsindei...@gmail.com wrote: Hallo liebe Mädels und Jungs, das ist jetzt mein Qubes Forum in deutsche Sprache. https://qubes-deutschland-forum.gegenseitige-hilfe.org/index.php Bitte schaut mal rein und sagt mir, was man noch verbessern bzw. umsetzen kann. Ihr könnt euere Verbesserungsvorschläge hier reinschreiben. https://qubes-deutschland-forum.gegenseitige-hilfe.org/viewforum.php?f=138 Verbesserungsvorschlag: email-liste statt Webforum! Oder mindestens Discourse (was beides macht) (ich, vermutlich auch andere, finde es viel leichter Updates per Mail zu bekommen) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200515182324.GB1086%40danwin1210.me.
[qubes-users] A lot of dom0 updates recently
dom0 seems to be getting a lot of updates at the moment (3x in the last 1-2 weeks?) ... are there any security holes we should know about? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200617045326.GA5613%40danwin1210.me.
Re: [qubes-users] A lot of dom0 updates recently
On Fri, Jun 19, 2020 at 04:41:03AM +, Logan wrote: I've been noticing this, too. Something interesting has been occurring in about half of my Dom0 updates lately: In the "details" section of the Qubes Updater it shows no detail, only: Fairly ambiguous. Did it even update? Same thing happening to me. Must be those NSA "ghost updates" when they install the backdoor :) note to tinfoil hat crowd: JUST KIDDING (hopefully) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200621165723.GA1138%40danwin1210.me.
Re: [qubes-users] Re: A lot of dom0 updates recently
On Fri, Jun 19, 2020 at 07:28:52AM -0700, Lorenzo Lamas wrote: Security issues are always published in Qubes Security Bulletins, which are also in the News section of Qubes website. The only recent Security Bulletin is about the new Intel CPU vulnerabilities, but that isn't in the stable updates repository yet, so unless you updated dom0 with testing repository, all your recent updates are not security updates. Thanks! Yes, I haven't seen any announcements, so that's why I was wondering. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200621165753.GB1138%40danwin1210.me.
Re: [qubes-users] Some questions about Electrum split wallet
On Sun, Jun 21, 2020 at 03:33:57PM +, 'Totally Zoid' via qubes-users wrote: The instructions for using Electrum split wallet on the Qubes website recommend installing electrum with dnf. However this gives electrum 3.3.4, which is not the most recent version, that is 3.3.8, available from electrum's website. Would it be safer to install the most recent version from the website? For the "hot" side of the wallet you probably want the most recent version. For the "cold" / offline side it should not matter. Also does anyone know if it's possible to have a split wallet with a bitcoin-core own node instead of relying on electrum? Yes, see the howto using `electrs` or Electrum Personal Server: https://github.com/qubenix/qubes-whonix-bitcoin Note that for real privacy you will need to use JoinMarket. I don't know if Qubenix takes donations but if so it's definitely worth supporting him for putting together such an epic HOWTO! Another thing is that a lot of menu options in electrum lead to web addresses and these very frustratingly open in Firefox inside the electrum VM. Is there a way to force these links to open in a dispVM? That should work the same as changing the default URL for any other application. I think that is already covered in the Qubes docs. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200621170258.GC1138%40danwin1210.me.
[qubes-users] Google requiring login to access qubes-users
WHen I try to access the Google Groups qubes-users site, sometimes (circa 50%) I'm presented with a Google login prompt and can't access the qubes-users group unless I have a Google account. Since Qubes is privacy-focused it seems like maybe the Qubes mailing lists should migrate to a less Orwellian mailing list provider. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200815193919.GA1104%40danwin1210.me.
Re: [qubes-users] Calling all humans! (from Nina)
On Sun, Oct 11, 2020 at 11:42:27PM +0500, Stumpy wrote: Thanks for this, I have filled it out and volunteered but really really really wanted to iterate one big (for me) point, and that is include at least some of the things listed in the documentation as an option in the setup. Side idea: include the documentation in the base install! And then it's easier to point to the relevant bits of the documentation post-install... -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20201012180112.GC1220%40danwin1210.me.
Re: [qubes-users] [unofficial] Qubes security advisory
On Mon, Oct 26, 2020 at 04:04:30PM -0400, Chris Laprise wrote: On 10/25/20 10:24 PM, 'J.M. Porup' via qubes-users wrote: One morning last week, I launched a disposable Debian 10 template with my preset defaults of no netvm and a blank page preset--but instead a default page of "https://www.youtube.com/"; appeared. It only happened once, but it was enough. So to clarify, you launched a dispVM with no networking, and a youtube page was loaded and rendered on screen? That seems highly unlikely to be an accidental input or glitch. No, he's saying the Firefox homepage in his Debian-10 template was changed from about:blank to youtube.com, leading the debian-10 template-based DispVM to launch Firefox with youtube.com as the default page. Ergo someone compromised his Debian-10 template and changed the Firefox homepage... or, there was an error in the template configuration leading to him accidentally changing the hompeage in what sounds like a stressful situation. J.M., assuming you are indeed correct about a major attack, most of the major Xen vulnerabilities that threaten a Qubes full compromise involve sys-net. Since Five Eyes may get advance notice of Xen holes, if your machine was indeed fully rooted it could be you were hit by the PCI vulnerability from a while back. Due to precisely these kinds of issues, there is discussion for using the much-harder-to-exploit OpenBSD as an operating system for the sys-net VM: https://github.com/QubesOS/qubes-issues/issues/5294 You may want to give it a go (after buying a new laptop, of course). Additionally, if a sys-net based attack is indeed a concern for your threat model, consider disabling wi-fi entirely and using an ethernet cable, wi-fi drivers are generally terrible. Nevertheless if you are really up against serious Five Eyes type adversaries then it's unlikely you'll be able to keep *any* computer secure for long and should probably buy that cabin in the Rockies you always wanted... -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20201105222013.GA1107%40danwin1210.me.
[qubes-users] Opening applications using qvm-run
I'm trying to figure out how to open applications in VMs from dom0 using qvm-run, and how to do so without blocking the terminal in dom0. For example: ``` $ qvm-run anon "torbrowser qubes-os.org" Running 'torbrowser qubes-os.org' on anon ``` The above command sucessfully launches Tor Browser in the `anon` VM, but I can't run another command in the same dom0 terminal window until Tor Browser (in the VM) finishes (exits). Alternately I can do something like ``` $ qvm-run anon "gnome-terminal -- torbrowser qubes-os.org" ``` but that leaves a terminal window running in the `anon` VM. I've also tried all the usual variations on `nohup`, `disown`, `&`, and the like, but none of them seem to do the trick. Any ideas? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YDjjDMmmzJzTkk0J%40danwin1210.me.
[qubes-users] Opening applications using qvm-run
I'm trying to figure out how to open applications in VMs from dom0 using qvm-run, and how to do so without blocking the terminal in dom0. For example: ``` $ qvm-run anon "torbrowser qubes-os.org" Running 'torbrowser qubes-os.org' on anon ``` The above command sucessfully launches Tor Browser in the `anon` VM, but I can't run another command in the same dom0 terminal window until Tor Browser (in the VM) finishes (exits). Alternately I can do something like ``` $ qvm-run anon "gnome-terminal -- torbrowser qubes-os.org" ``` but that leaves a terminal window running in the `anon` VM. I've also tried all the usual variations on `nohup`, `disown`, `&`, and the like, but none of them seem to do the trick. Any ideas? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YDpUQIsYO4hJyRt4%40danwin1210.me.
Re: [qubes-users] Opening applications using qvm-run
On Sat, Feb 27, 2021 at 11:57:32PM +, unman wrote: Is this Torbrowser specific? Because it doesn't block with other programs (or at least doesn't seem to do so for me). On what is the "anon" qube based? How is it configured to run torbrowser with no path? It's not Torbrowser specific for me, that was just an example using a Whonix Workstation VM. (it does work as stated -- I did test it) In actuality I want to launch specific applications (that launch fine using applications menu) from a dom0 script, but the only way I can find to launch them without blocking the script execution is using gnome-terminal. And that opens an extra (unneeded) terminal window. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YDuQ6zSFT31ESepY%40danwin1210.me.
Re: [qubes-users] Opening applications using qvm-run
On Sun, Feb 28, 2021 at 11:49:04PM +, unman wrote: It's not Torbrowser specific for me, that was just an example using a Whonix Workstation VM. (it does work as stated -- I did test it) In actuality I want to launch specific applications (that launch fine using applications menu) from a dom0 script, but the only way I can find to launch them without blocking the script execution is using gnome-terminal. And that opens an extra (unneeded) terminal window. Do you have the same problem with non Whonix qubes? I dont use Whonix, and dont have this problem with any of my other template based qubes. Yes. But the other solution (qubes.StartApp) did the trick. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YDz2ddi0Rrp6RuLw%40danwin1210.me.
Re: [qubes-users] Opening applications using qvm-run
On Sun, Feb 28, 2021 at 08:03:47PM +0100, airelemental via qubes-users wrote: Try: $ qvm-run --service anon qubes.StartApp+janondisttorbrowser $ qvm-run --service untrusted qubes.StartApp+firefox $ qvm-run --service personal qubes.StartApp+thunderbird Thanks, that did the trick! Two questions: 1. Is there any way to pass arguments? 2. for some applications the name I have to pass to qubes.StartApp is not the same as the command used on the command line (e.g `janondisttorbrowser` instead of `torbrowser`). How do I find out the correct name for an arbitrary application? is it always the same as the name of the .desktop file in /usr/share/applications? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YDwdXuakojz8gdV8%40danwin1210.me.
[qubes-users] Qubes AEM: write protecting BIOS is not possible
The [Qubes AEM docs](https://github.com/QubesOS/qubes-antievilmaid) recommend: Some hints: connect the write protect pin on BIOS flash chip to ground (prevents attacker from booting their own software which would bypass BIOS protections and overwrite it) and make sure physically accessing the chip will be tamper-evident by eg. covering the screws holding laptop body together in glitter and taking high-res photos, then examining before each use. However, the given suggestion will do nothing on most laptops, providing a false sense of security. The reason is that many/most BIOS flash chips require the SRWD and block protect bits to be set **in software** before the **hardware** write protect pins will do anything. Unfortunately, Flashrom does not currently support setting these bits, though there is an open proposal to add support: https://github.com/flashrom/flashrom/issues/142 https://github.com/flashrom/flashrom/issues/185 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YEagdOwtmnEOZ6PR%40danwin1210.me.
Re: [qubes-users] Survey from HackerNCoder: Colors in QubesOS
On Mon, Mar 15, 2021 at 10:16:04PM +, hackerncoder wrote: I have created a survey about colors in Qubes, to help understand users: Are there too many colors? Too few? What do users associate with the colors? what are they used for? There wasn't any space in the survey for general comments, so let me say here: more colors, please! I find it makes the most sense to be able to isolate *both* by threat level and theme, and there simply aren't enough colors to do that. Colors are not just about preventing one VM from pretending to be another VM. Colors also really help prevent *user error*, where you accidentally confuse e.g your chat window with Mom with the chat window you use for communicating with journalistic sources -- and end up asking Mom to get undercover footage from North Korea. Woops! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YFD9hgjWUbvDtUvA%40danwin1210.me.
[qubes-users] Qubes-backup verify only verifies dom0, not appVMs
When I verify my backups, it happens ~instantaneously. It used to take hours, because it would extract every VM backup and verify it. Judging by the logs, it's only verifying dom0. Unless something has changed with how Qubes verifies its backups, there may be a bug that causes verification to only check dom0, rather than verifying the AppVMs as well. This is really bad, because what I care about is the data in the AppVMs... being able to restore the AppVMs is more important than being able to restore dom0! Here's how I back up: ``` nice qvm-backup \ --verbose \ --passphrase-file $PASSFILE \ --exclude $IGNORE_VM \ --dest-vm $DEST_VM \ --compress \ --yes \ $BACKUP_DIR ``` And here's how I restore: ``` qvm-backup-restore \ --dest-vm $DEST_VM \ --passphrase-file $PASSFILE \ --verify-only \ --verbose \ $BACKUP_FILE ``` When it starts restoring, it shows that none of my VMs will be restored, except for dom0: ``` The following VMs are included in the backup: +--+---+-++ name | type | template | netvm | label | +--+---+-++ dom0 | AdminVM | n/a | (default) | black | myvm | StandaloneVM | n/a | my-net-vm-x | orange | <-- Excluded from restore my-other-vm-xxx |AppVM | debian-10 | (default) | blue | <-- Excluded from restore another-vm-xx |AppVM | fedora-33 | (default) | green | <-- Excluded from restore [... continuing for the list of all VMs ...] ``` And in fact only dom0 gets verified, the others seem to be ignored. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YSYjit8%2BhYGbkJrI%40danwin1210.me.
Re: [qubes-users] Qubes-backup verify only verifies dom0, not appVMs
On Wed, Aug 25, 2021 at 07:31:33AM -0700, Andrew David Wong wrote: And in fact only dom0 gets verified, the others seem to be ignored. I cannot seem to reproduce this. My verify-only attempts also verify domUs. I'm using the same qvm-backup-restore command, just without `--verbose`. That's very strange. Are restore settings stored anywhere on the local machine, like how VMs can have an "exclude from backups" option? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YSeUe5O1IEUt12if%40danwin1210.me.
Re: [qubes-users] Trezor in Qubes
On Thu, Aug 26, 2021 at 02:27:35PM +, 'taran1s' via qubes-users wrote: Hello all, I would like to start to use Trezor with my qubes. I would like to follow this guide here https://wiki.trezor.io/Qubes_OS. My intention is to use the Trezor HW wallet in a anon-whonix AppVm with Trezor Suite qube through Tor. I run qubes on X230 Nitropad. I would like to check if the guide to install the Trezor Bridge and Udev rules in the sys-usb (see the official Trezor guide) is advised by qubes community or is it good practice not to install anything in the sys-usb and instead install the packages (bridge, udev rules and suite) in the target anon-whonix AppVM. It should be fine. See my pull request for step by step instructions: https://github.com/Qubes-Community/Contents/pull/145 https://github.com/Qubes-Community/Contents/blob/3e1785a11e90b52e086fb8b3b246e5c2de7faca5/docs/common-tasks/setup-trezor-cryptocurrency-hardware-wallet.md -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YSjVraLa/O2lQYOX%40danwin1210.me.
Re: [qubes-users] Trezor error with qubes
have you seen this? https://github.com/Qubes-Community/Contents/blob/e7443c960228c1abec9b97f2c2027dbc01f45f63/docs/common-tasks/setup-trezor-cryptocurrency-hardware-wallet.md On Tue, Aug 31, 2021 at 02:53:47PM +, 'taran1s' via qubes-users wrote: Hello, In my last message I mentioned my attempts to start using the Trezor with qubes. I try to follow this guide, from the official trezor website: https://wiki.trezor.io/Qubes_OS I use the sys-usb based on debian-10 and tried the same with sys-usb based on debian-10-minimal with similar error. My online AppVM in anon-whonix. After I finished the procedures described in the guide, I installed the trezor Bridge and Udev rules in the sys-usb, and the Trezor Suite in the anon-whonix, with sudo dpkg -i required-package. Once I start both sys-usb and anon-whonix and attach the trezor-T I get following error (suite is seen by the sys-usb): 2021-08-31T14:38:06.967Z - ERROR(process-trezord): Status error: request to http://127.0.0.1:21325/ failed, reason: connect ECONNREFUSED 127.0.0.1:21325 Do you see any workarounds to make it work? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/753fdebf-f149-5ba4-8f24-f19802a0b525%40mailbox.org. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YTPcR2PRFOL/AjKf%40danwin1210.me.
Re: [qubes-users] Trezor in Qubes
On Fri, Sep 03, 2021 at 07:54:56AM +, taran1s wrote: Thank you for the guide. I tried to follow the official guide on trezor wiki, abstaining from fedora a bit more, but still erroring. To your guide. The last 4 lines: copy to fedora-3x in fedora-3x sudo rpm -i /path/to/trezor.rpm ...are to be done in the fedora-3x template, right? Will it work on fedora-33-minimal too, or it needs to be full template? I don't know. All done, but I wasnt able to find any signed hash of the bridge or something and so I get this error: [user@fedora-33-min-trezor ~]$ sudo rpm -i trezor-bridge-2.0.27-1.x86_64.rpm warning: trezor-bridge-2.0.27-1.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID b9a02a3d: NOKEY package trezor-bridge-2.0.27-1.x86_64 does not verify: Header V4 RSA/SHA256 Signature, key ID b9a02a3d: NOKEY Weird. You have to install the Trezor verification key. I had to do this the first time I installed, but after re-imaging my system, it wasn't necessary on the most recent install, so I took the section out of my notes. Unfortunately I don't remember what the steps were to install the key! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YTPfjQCizVDm8sen%40danwin1210.me.
Re: [qubes-users] Qubes-backup verify only verifies dom0, not appVMs
On Thu, Aug 26, 2021 at 07:11:49AM -0700, Andrew David Wong wrote: It's possible to create "backup profiles," but I haven't personally used them, so I'm not familiar with the details of how they work. This option is mentioned in the `--help` text for qvm-backup but not qvm-backup-restore. It looks like the profiles are stored in /etc/qubes/backup/. I checked that directory and there are no profiles, so that can't be the problem. Unfortunately at this point I'm all out of ideas for troubleshooting this -- even though it's a very important issue! Unverified backups are very dangerous, and I've caught problems before because backups failed to verify. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YT%2BOWhaS0TGZke4v%40danwin1210.me.
[qubes-users] Re: Trezor error with qubes
Ah, I think I forgot to verify. You need to install the public key so you can verify the trezor-bridge RPM file. Unfortunately I don't remember how to do this. On Fri, Sep 24, 2021 at 01:58:34PM +, taran1s wrote: Dear tetrahedra, I am just resending the email in case it didn't catch your attention last time. Could you please have a look at the issue and guide me a little? I tried everything but wasn't able to make it run. Thank you a ton! taran1s taran1s: have you seen this? https://github.com/Qubes-Community/Contents/blob/e7443c960228c1abec9b97f2c2027dbc01f45f63/docs/common-tasks/setup-trezor-cryptocurrency-hardware-wallet.md Actually I did do the process based on this guide. Everything is set up except bridge verification. The issue is that once I download the bridge from https://wallet.trezor.io/#/bridge I cannot verify it with gpg2 --verify It returns: [user@fedora-33-min-trezor ~]$ gpg2 --verify trezor-bridge-2.0.27-1.x86_64.rpm gpg: no valid OpenPGP data found. gpg: the signature could not be verified. Please remember that the signature file (.sig or .asc) should be the first file given on the command line. If I try to use rpm directly, it returns this: [user@fedora-33-min-trezor ~]$ sudo rpm -i trezor-bridge-2.0.27-1.x86_64.rpm warning: trezor-bridge-2.0.27-1.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID b9a02a3d: NOKEY package trezor-bridge-2.0.27-1.x86_64 does not verify: Header V4 RSA/SHA256 Signature, key ID b9a02a3d: NOKEY Fedora min template has following packages installed: gnome-keyring qubes-core-agent-nautilus qubes-mgmt-salt-vm-connector qubes-usb-proxy and of course trezor-common On Tue, Aug 31, 2021 at 02:53:47PM +, 'taran1s' via qubes-users wrote: Hello, In my last message I mentioned my attempts to start using the Trezor with qubes. I try to follow this guide, from the official trezor website: https://wiki.trezor.io/Qubes_OS I use the sys-usb based on debian-10 and tried the same with sys-usb based on debian-10-minimal with similar error. My online AppVM in anon-whonix. After I finished the procedures described in the guide, I installed the trezor Bridge and Udev rules in the sys-usb, and the Trezor Suite in the anon-whonix, with sudo dpkg -i required-package. Once I start both sys-usb and anon-whonix and attach the trezor-T I get following error (suite is seen by the sys-usb): 2021-08-31T14:38:06.967Z - ERROR(process-trezord): Status error: request to http://127.0.0.1:21325/ failed, reason: connect ECONNREFUSED 127.0.0.1:21325 Do you see any workarounds to make it work? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/753fdebf-f149-5ba4-8f24-f19802a0b525%40mailbox.org. -- Kind regards taran1s gpg: 12DDA1FE5FB39C110F3D1FD5A664B90BD3BE59B3 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YU8wtsy8Y8/P7lwX%40danwin1210.me.
[qubes-users] Whonix upgrade fails after interruption
I started uprading Whonix using the salt command, but the process was interrupted. On retrying, it fails, unable to create the whonix WS VM due to "permission denied". From journalctl: Oct 08 11:24:35 dom0 qubesd[2098]: permission denied for call b'admin.vm.Create.AppVM'+b'whonix-ws-16' (b'dom0' → b'dom0') with payload of 31 bytes (see below for the salt output) When I run the qvm-create command from the salt output manually, it also fails, because the whonix-ws-16 template doesn't exist: $ qvm-create --verbose whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 --label=red 2021-10-08 11:33:54,499 [MainProcess qvm_create.main:177] app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details. I assume all this is related to the failed previous attempt. How do I reset the state so that I can successfully do the upgrade? [user@dom0 ~]$ sudo qubesctl state.sls qvm.anon-whonix [WARNING ] /var/cache/salt/minion/extmods/states/ext_state_qvm.py:146: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 status = Status(retcode=1, result=False, stderr=err.message + '\n') [ERROR ] == ['features'] == Virtual Machine does not exist! == ['tags'] == [SKIP] Skipping due to previous failure! [ERROR ] == ['present'] == == stderr == /usr/bin/qvm-create whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 --label=red app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details. == ['prefs'] == Virtual Machine does not exist! == ['features'] == [SKIP] Skipping due to previous failure! == ['tags'] == [SKIP] Skipping due to previous failure! local: -- ID: template-whonix-ws-16 Function: pkg.installed Name: qubes-template-whonix-ws-16 Result: True Comment: Package qubes-template-whonix-ws-16 is already installed Started: 11:24:14.138294 Duration: 5796.629 ms Changes: -- ID: whonix-ws-tag Function: qvm.vm Name: whonix-ws-16 Result: False Comment: == ['features'] == Virtual Machine does not exist! == ['tags'] == [SKIP] Skipping due to previous failure! Started: 11:24:19.979281 Duration: 271.503 ms Changes: -- ID: whonix-ws-update-policy Function: file.prepend Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy Result: True Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state Started: 11:24:20.261980 Duration: 14.769 ms Changes: -- ID: whonix-get-date-policy Function: file.prepend Name: /etc/qubes-rpc/policy/qubes.GetDate Result: True Comment: File /etc/qubes-rpc/policy/qubes.GetDate is in correct state Started: 11:24:20.277092 Duration: 12.533 ms Changes: -- ID: template-whonix-gw-16 Function: pkg.installed Name: qubes-template-whonix-gw-16 Result: True Comment: Package qubes-template-whonix-gw-16 is already installed Started: 11:24:20.289981 Duration: 1.316 ms Changes: -- ID: whonix-gw-tag Function: qvm.vm Name: whonix-gw-16 Result: True Comment: == ['features'] == [SKIP] Feature already in desired state: ENABLE 'whonix-gw' = Enabled == ['tags'] == [SKIP] All requested tags already set: created-by-dom0,whonix-updatevm Started: 11:24:20.291708 Duration: 4714.395 ms Changes: -- ID: whonix-gw-update-policy Function: file.prepend Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy Result: True Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state Started: 11:24:25.006518 Duration: 7.468 ms Changes: -- ID: sys-net Function: qvm.exists Result: True Comment: /usr/bin/qvm-check sys-net None Started: 11:24:25.014322 Duration: 2048.565 ms Changes: -- ID: sys-firewall Function: qvm.exists Result: True Comment: /usr/bin/qvm-check sys-firewall None Started: 11:24:27.065077 Duration: 1868.662 ms Changes: -- ID: sys-whonix Function: qvm.exists Result: True Comment: /usr/bin/qvm-check sys-whonix None Started: 11:24:28.935733 Duration: 1744.59 ms Changes: -- ID: whonix-ws-16-dvm Function: qvm.vm Result: False Comment: == ['present'] == == stderr == /usr/bin/qvm-create whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 --label=red app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details. == ['prefs'] == Virtual Machine does not exist!
[qubes-users] qubes.TemplateSearch is missing
The process of upgrading my debian-11 and fedora-34 templates to 4.1 did not work out, and I need to reinstall those templates. When I go to do sudo qubes-dom0-update --action=reinstall qubes-template-debian-11 I get the error: $ sudo qubes-dom0-update --action=reinstall qubes-template-debian-11 Redirecting to 'qvm-template reinstall debian-11' [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory ERROR: qrexec call 'qubes.TemplateSearch' failed. Where can I get the TemplateSearch service? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YmpHNFL4o1fYfB%2BG%40danwin1210.de.
[qubes-users] Re: qubes.TemplateSearch is missing
On Thu, Apr 28, 2022 at 07:51:14AM +, tetrahe...@danwin1210.de wrote: Where can I get the TemplateSearch service? The solution is to ensure the UpdateVM is using a 4.1-compatible template: https://github.com/QubesOS/qubes-issues/issues/7120 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YmpfbuBeLQneMzT1%40danwin1210.de.
Re: [qubes-users] Re: How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
On Tue, May 31, 2022 at 11:54:24PM -0700, Viktor Ransmayr wrote: I've performed the same task today - and - the same 14 packages were removed again ... So it's clear now that something went wrong with my 'in-place upgrade' ! Anything that I could try, beside a completely fresh installation of Qubes OS R4.1 ? I've had similar issues: https://github.com/QubesOS/qubes-issues/issues/7503 Maybe try some of the ideas suggested there? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YpfiIoiraPydfevk%40danwin1210.de.
Re: [qubes-users] Re: sys-firewall freezing on resume from suspend
On Fri, Jun 03, 2022 at 04:00:20PM +0200, 'qtpie' via qubes-users wrote: So, apparently, this is not a sys-firewall, but a clocksync issue. To root out any causes, I moved the clocksync service to a separate, brand new qube (named sys-clock). And voila: sys-firewall no longer 'crashes' on resume from suspend, now it's sys-clock. This should probably be filed as an issue: github.com/QubesOS/qubes-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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YpssUiKTrfhVS/og%40danwin1210.de.
Re: [qubes-users] Re: whonix tor browser customization
On Fri, Sep 06, 2019 at 09:00:00AM +, Patrick Schleizer wrote: panina: On 8/9/19 9:05 AM, Patrick Schleizer wrote: panina: Namely, they removed NoScript from the toolbar, so that the NoScript cannot be used as intended. We did not. Decision by upstream, The Tor Project. https://forums.whonix.org/t/workstation-15-dropped-both-noscript-and-https/7733 Thanks, duly noted. Is there any chance to get them to add a setting for this? Or re-think their decision? It's not up to me at all. The Tor Project is the only point of contact fo this. Did upstream (Tor) also change the NoScript settings to block all javascript on all sites by default, even at the lowest Tor Browser security level? This is what seems to be happening for me. It is a pain, since any attempt to fix the settings goes away once the disposable Whonix VM dies. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190908102257.GA997%40danwin1210.me.
[qubes-users] Is it safe to reinstall templates automatically again?
The docs on template reinstallation indicate that QSB 050 means it is not safe to automatically reinstall templates: https://www.qubes-os.org/doc/reinstall-template/ However QSB 050 suggests that patches were pushed out some time ago: https://www.qubes-os.org/news/2019/07/24/qsb-050/ Indeed `sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing` says no new patches are available. Does this mean that (contrary to the template reinstall docs) it is safe to use automatic reinstallation now? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190911074607.GA2011%40danwin1210.me.
[qubes-users] Making a DispVM permanent
I start working on a project with some untrusted data in a DispVM. Then I decide the project is bigger or going to take longer than anticipated and I need to keep the DispVM around, so I don't lose my work prematurely. Is there a way to turn currently-running DispVM instance into a regular permanent AppVM, which I can delete later? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190921112708.GA1007%40danwin1210.me.
[qubes-users] Per-VM stream isolation in Whonix
Is there any way to automatically do stream isolation on a per-VM basis? For example: I start AppVM "A", with networking via Whonix, and interact with the internet as "Alice" I start AppVM "B", with networking via Whonix, and interact with the internet as "Bob" Naturally I want Alice to appear to be using a different IP address than Bob, else the two identities are linked. Right now it appears this is not necessarily the case -- the network traffic of AppVMs A and B may end up using the same Tor circuits (and exit nodes). Is there a way to set this up? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190922142428.GB2032%40danwin1210.me.
Re: [qubes-users] Per-VM stream isolation in Whonix
On Sun, Sep 22, 2019 at 02:51:00PM +, 'awokd' via qubes-users wrote: tetrahedra via qubes-users: Is there any way to automatically do stream isolation on a per-VM basis? Right now it appears this is not necessarily the case -- the network traffic of AppVMs A and B may end up using the same Tor circuits (and exit nodes). Is there a way to set this up? Stream isolation is enabled out of the box- per application in most cases, per tab & TLD in Tor Browser's (https://www.whonix.org/wiki/Stream_Isolation). I am referring to stream isolation for non-Whonix Workstation based VMs, and/or for applications which are not wrapped by `uwt`. (e.g Signal) It would seem that different VMs ought to be stream isolated by default (they are different VMs, we obviously want them isolated as much as possible!)... -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190922160655.GA2477%40danwin1210.me.
Re: [qubes-users] using two whonix-gw instances
On Wed, Sep 25, 2019 at 11:32:20PM +, 'awokd' via qubes-users wrote: Sven Semmler: On 9/25/19 5:26 PM, 'Jackie' via qubes-users wrote: even different applications within the same vm, will use different tor circuits. I know this is true of apps that come with whonix-ws, but is it the case for apps added later like Signal? I think you'd still be OK if Signal was the only thing added, but don't know about something like Signal and Discord in the same AppVM. I'm fairly sure the answer is "no, stream isolation is only automatic for apps which are wrapped by `uwt` or which otherwise take steps to be isolated, and this just happens to be the case for most whonix-default apps"... -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190926092207.GA1787%40danwin1210.me.
Re: [qubes-users] Per-VM stream isolation in Whonix
On Fri, Sep 27, 2019 at 01:37:06PM +, Claudia wrote: Isolating apps in the same VM is a different issue, but you're saying traffic from different VMs is appearing to come from the same address? Hmm, that definitely should not be happening. VM isolation is enabled out of the box. Different VMs, whonix or otherwise, should never share circuits. IsolateClientAddr (on by default) in whonix-gw's torrc should isolate streams originating from different addresses/VMs, no matter what OS or apps they're running. I don't see that setting in /usr/local/etc/torrc.d/40_tor_control_panel.conf or in 50_user.conf ... which torrc is that setting supposed to be in? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190928110536.GA1832%40danwin1210.me.
Re: [qubes-users] Per-VM stream isolation in Whonix
On Sun, Sep 29, 2019 at 02:42:29PM +, Claudia wrote: You can try viewing your active tor settings in Nyx (preinstalled in Whonix) rather than from torrc directly. Just in case some setting is being overridden or something like that. See https://www.whonix.org/wiki/Tor_Controller and https://nyx.torproject.org/#config_editor I don't see any mention of the relevant settings at all in the "Arm tor controller" app. Nyx does not appear to be installed at all. On further troubleshooting it looks like separate VMs may have been connecting to the same IP addresses (as part of checking for updates) at the same time, and that may have been producing the effects I have seen. IsolateSOCKSAuth appears to be working as intended. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190930141749.GA1010%40danwin1210.me.
[qubes-users] vif-route-qubes fails when setting up a 'provides network' VM
I am trying to duplicate a previously-successful configuration of a Debian based ProxyVM/'provides network' VM. However with the new VM (call it proxy2) the client VMs are unable to reach the proxy (ping returns 'Destination Host Unreachable'). The proxy2 VM only shows two network interfaces in the output of `ifconfig`: eth0 and lo The (working, older) proxy1 VM shows three network interfaces in the output of `ifconfig: eth0, lo, and vif22.0 When I start a client VM, the following lines appear in the output of `journalctl` on proxy2: Sep 30 16:08:03 proxy2 root[5360]: /etc/xen/scripts/vif-route-qubes: offline type_if=vif XENBUS_PATH=backend/vif/51/0 Sep 30 16:08:03 proxy2 root[5372]: /etc/xen/scripts/vif-route-qubes: Writing backend/vif/51/0/hotplug-error /etc/xen/scripts/vif-route-qubes failed; error detected. backend/vif/51/0/hotplug-status error to xenstore. Sep 30 16:08:03 proxy2 root[5374]: /etc/xen/scripts/vif-route-qubes: /etc/xen/scripts/vif-route-qubes failed; error detected. This suggests that vif-route-qubes is failing to set up the interface, but I am not sure how to fix it. Any suggestions? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190930143458.GB1010%40danwin1210.me.
Re: [qubes-users] Per-VM stream isolation in Whonix
On Mon, Sep 30, 2019 at 08:05:44AM +, Claudia wrote: Glad to hear it's working. I guess I should have asked at the beginning... What brought you to the conclusion they were using the same circuits? I assumed you were using check.torproject.org or another "what is my IP" site, but if looking at tcpdump or something, there are plenty of reasons they might connect to the same IP. Although, I think you would only see the local connection to sys-whonix, so I'm still not exactly sure what's going on here. I am using the Onion Circuits GUI app to display all outgoing circuits and their destination IPs. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191001022935.GA1014%40danwin1210.me.
Re: [qubes-users] using two whonix-gw instances
On Thu, Sep 26, 2019 at 10:09:04AM -0500, Sven Semmler wrote: My understanding is that TOR actually runs in the gateway and the the workstation(s) enable typical Qubes style compartmentalization. Meaning that if app-anon-1 is compromised, the sys-whonix and a potential app-anon-2 are not. When I create a second sys-whonix-id I can see via the Tor control panel that it uses a different Onion circuits than the first instance. Would it be recommended to use a separate sys-whonix gateway for applications where one needs to expose the Tor ControlPort to AppVMs? While the ControlPort would be protected by a password (this is mandatory for non-local access) it seems conceivable that either: a) the AppVM that has legitimate access (and the password) to the ControlPort might get compromised, or b) another AppVM (without legit access or the password) might be used to exploit a vulnerability in the exposed ControlPort A 2nd sys-whonix gateway for this situation would seem to reduce the vulnerability. Or maybe I am just being paranoid? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191001025926.GA1477%40danwin1210.me.
Re: [qubes-users] vif-route-qubes fails when setting up a 'provides network' VM
On Mon, Sep 30, 2019 at 04:34:58PM +0200, tetrahedra via qubes-users wrote: I am trying to duplicate a previously-successful configuration of a Debian based ProxyVM/'provides network' VM. However with the new VM (call it proxy2) the client VMs are unable to reach the proxy (ping returns 'Destination Host Unreachable'). The proxy2 VM only shows two network interfaces in the output of `ifconfig`: eth0 and lo The (working, older) proxy1 VM shows three network interfaces in the output of `ifconfig: eth0, lo, and vif22.0 When I start a client VM, the following lines appear in the output of `journalctl` on proxy2: Sep 30 16:08:03 proxy2 root[5360]: /etc/xen/scripts/vif-route-qubes: offline type_if=vif XENBUS_PATH=backend/vif/51/0 Sep 30 16:08:03 proxy2 root[5372]: /etc/xen/scripts/vif-route-qubes: Writing backend/vif/51/0/hotplug-error /etc/xen/scripts/vif-route-qubes failed; error detected. backend/vif/51/0/hotplug-status error to xenstore. Sep 30 16:08:03 proxy2 root[5374]: /etc/xen/scripts/vif-route-qubes: /etc/xen/scripts/vif-route-qubes failed; error detected. This suggests that vif-route-qubes is failing to set up the interface, but I am not sure how to fix it. Any suggestions? This issue has since resolved itself. The solution... was to reboot the whole system. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191001030738.GA1767%40danwin1210.me.
Re: [qubes-users] Per-VM stream isolation in Whonix
On Mon, Sep 30, 2019 at 04:15:26PM +, Claudia wrote: To make sure IsolateClientAddr is working (as opposed to IsolateSOCKSAuth), you can run curl.anondist-orig https://check.torproject.org in two different whonix-ws VMs at the same time, and make sure they output different addresses. You should also see check.torproject.org:443 pop up in Onion Circuits under different circuits. If they show up under the same circuit, or output the same address, then IsolateClientAddr is indeed broken. Bonus points: try running that command twice in the **same** VM, and it should (usually) output the same address both times. Both steps worked exactly as they should have. Thank you for your help! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191002113420.GA2217%40danwin1210.me.
[qubes-users] Tabs mangled when copying between AppVMs
When copying from AppVM to AppVM, tabs and/or spaces often get mangled (additional tabs/spaces inserted). For example, if I have a block of text in one AppVM that looks like: def my_function(): msg = "foo" othermsg = "bar" print(msg + othermsg) When I Ctrl-C (or Ctrl-Insert) and Ctrl-Shift-C this block of text, then Ctrl-Shift-V and Shift-Insert it into an editor in another VM, it sometimes comes out looking like: def my_function(): msg = "foo" othermsg = "bar" print(msg + othermsg) The issue does not crop up every time. Unfortunately, I haven't been able to figure out a pattern or logic for when it occurs vs when it does not occur. Any suggestions for how to stop this happening? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191007075323.GA1939%40danwin1210.me.
Re: [qubes-users] Tabs mangled when copying between AppVMs
On Tue, Oct 08, 2019 at 08:26:34PM -0500, Andrew David Wong wrote: Are you, by any chance, copying into Vi/Vim? That sort of thing happens when you have "smart indentation" (or similar) enabled in Vim. Ah, yes, that would explain it. Thanks! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191009100510.GA1203%40danwin1210.me.
[qubes-users] VMs refuse to start after being shut down (following latest update)
After the latest round of updates I have started seeing some odd behavior: VMs will only start once per system boot. This is rather a problem (it makes Qubes much less usable!), should I also add it to the Github tracker? Further details: After a VM has been shut down, when I try to start it again I get the notification: "Domain MYVM has failed to start: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-MYVM.log for details" In the relevant file I find the following block of ugly text. The "start job is running" part is interesting as there is a similar message when I go to reboot the machine (which I need to do to use the VM again!)... on shut down, it hangs at the various "stop job is running" messages (which it rotates through) until timeout. There are also further errors which scroll past, but which I could not note down in time. [3.659414] intel_rapl: Found RAPL domain core [3.659429] intel_rapl: Found RAPL domain uncore [.[0;1;31mFAILED.[0m] Failed to start Init Qubes Services settings. See 'systemctl status qubes-sysinit.service' for details. [.[0;32m OK .[0m] Found device /dev/hvc0. [.[0;32m OK .[0m] Found device /dev/xvdc1. [.[0;1;31mFAILED.[0m] Failed to activate swap /dev/xvdc1. See 'systemctl status dev-xvdc1.swap' for details. [.[0;1;33mDEPEND.[0m] Dependency failed for Swap. [.[0;1;31mFAILED.[0m] Failed to start Initialize and mount /rw and /home. See 'systemctl status qubes-mount-dirs.service' for details. [.[0;1;31mFAILED.[0m] Failed to start Adjust root filesystem size. See 'systemctl status qubes-rootfs-resize.service' for details. ^M[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (30s / n o limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polli ng (30s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… pro gress polling (31s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (31s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (32s / no limit)^M.[K[.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (33s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (33s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (34s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (34s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (35s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (36s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m] A start job is running for Monitori… progress polling (36s / no limit)^M.[K[ .[0;31m*.[0m] A start job is running for Monitori… progress polling (37s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m] A start job is running for Monitori… progress polling (37s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (38s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (38s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (39s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (40s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (40s / no limit)^M.[K[.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (41s / no limit)^M.[K[.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (41s / no limit)^M.[K[.[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (42s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (43s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m* .[0m] A start job is running for Monitori… progress polling (43s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m.[0;31m*.[0m] A start job is running for Monitori… progress polling (44s / no limit)^M.[K[ .[0;31m*.[0;1;31m*.[0m] A start job is running for Monitori… progress polling (44s / no limit)^M.[K[ .[0;31m*.[0m] A start job i: -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191011154426.GA1244%40danwin1210.me.
Re: [qubes-users] VMs refuse to start after being shut down (following latest update)
On Fri, Oct 11, 2019 at 05:44:26PM +0200, tetrahedra via qubes-users wrote: After the latest round of updates I have started seeing some odd behavior: VMs will only start once per system boot. This is rather a problem (it makes Qubes much less usable!), should I also add it to the Github tracker? Further details: After a VM has been shut down, when I try to start it again I get the notification: "Domain MYVM has failed to start: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-MYVM.log for details" Key discovery: when I updated Qubes, around the same time I decreased the starting memory for some VMs to 200MB (from 400MB), and only those VMs were affected by this issue. Solution: raise the starting memory back to 400MB. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191012034520.GA1020%40danwin1210.me.
[qubes-users] How to set template-wide gnome-terminal default profile?
Common scenario: 1) create new appVM 2) open terminal 3) "oh no, the color scheme and font and terminal settings are all wrong" 4) spend some time clicking around in menus fixing it Is there a way to create a template-wide default gnome-terminal profile? (The terminal profile that I set in the template is not propagated to appVMs based on that template) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191012034803.GB1020%40danwin1210.me.
Re: [qubes-users] How to set template-wide gnome-terminal default profile?
On Sun, Oct 13, 2019 at 01:39:42PM +0100, unman wrote: The settings are stored in .config/dconf Configure the template. Copy .config/dconf to /etc/skel in the template. Now every new appVM you create will inherit your configuration. Perfect, just what I wanted. Added an issue to get this put in the community docs: https://github.com/Qubes-Community/Contents/issues/73 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191014132708.GA2138%40danwin1210.me.
[qubes-users] `sanity-squashfs` available and removed notifications
Dom0 device notifications (same style as when attaching a USB stick) keep popping up, along the lines of: /tmp/sanity-squashfs-290* (deleted) is available /tmp/sanity-squashfs-290* (deleted) is removed As far as I know there is no update process running in the background. journalctl in dom0 doesn't show anything useful either. Does anyone know what this is? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191016033119.GA1665%40danwin1210.me.
[qubes-users] Fixing a VM's botched grub install
As a result of some issues in a standaloneVM (debian-9), I ended up using the Xen hypervisor serial console to migrade to debian-9-testing -- part way. Sadly the hypervisor console does NOT support curses-style modal dialog boxes, and the process of updating GRUB involves navigating one of these. I did my best, but I do not think it worked. I have included a copy of the console output at the end of this message for reference. Now when I do `sudo file -s /dev/xvda[1..3]` I do not see any grub installation, and running `grub-emu` also suggests that the system will not recover from being rebooted: it is all "error: no such device" and "error: can't find command `linux`" and "error: can't find command `initrd`"... Unfortunately the Qubes documentation does not really describe what kind of bootloader Qubes expects to find on VM images, nor where it expects to find them. Any suggestions? Console output: .[1;23r.[4l.)0.[m.(B.[1;23r.[H.[J.[1;1HPackage configuration.[6;20H.[1K ┌───┤ Configuring grub-pc ├───┐.[7;20H.[1K │ GRUB install devices:.[15C│.[8;20H.[1K │.[37C│.[9;20H.[1K │[.[7m .[m.(B] /dev/xvda (21223 MB; ???)│.[10;20H.[1K │[ ] /dev/xvdb (4349 MB; ???).[5C│.[11;20H.[1K │[ ] /dev/xvdc (10737 MB; ???)│.[12;20H.[1K │[ ] /dev/xvdd (524 MB; ???).[6C│.[13;20H.[1K │[ ] /dev/xvda3 (21010 MB; ???) │.[14;20H.[1K │.[37C│.[15;20H.[1K │.[37C│.[16;20H.[1K │.[15C.[18C│.[17;20H.[1K │.[37C│.[18;20H.[1K └─┘.[9;30H.[9;27H .[10;27H.[7m .[10;30H.[10;27H.[m.(B .[11;27H.[7m .[11;30H.[11;27H.[m.(B .[12;27H.[7m .[12;30H.[12;27H.[m.(B .[13;27H.[7m .[13;3.[1;23r.[4l.)0.[m.(B.[1;23r.[H.[J.[1;1HPackage configuration.[3;2H┌──┤ Configuring grub-pc ├──┐.[4;2H│.[75C│.[5;2H│ You chose not to install GRUB to any devices. If you continue, the boot │.[6;2H│ loader may not be properly configured, and when this computer next.[8C│.[7;2H│ starts up it will use whatever was previously in the boot sector. If.[6C│.[8;2H│ there is an earlier version of GRUB 2 in the boot sector, it may be.[7C│.[9;2H│ unable to load modules or handle the current configuration file..[10C│.[10;2H│.[75C│.[11;2H│ If you are already using a different boot loader and want to carry on.[5C│.[12;2H│ doing so, or if this is a special environment where you do not need a.[5C│.[13;2H│ boot loader, then you should continue anyway. Otherwise, you should.[7C│.[14;2H│ install GRUB somewhere..[51C│.[15;2H│.[75C│.[16;2H│ Continue without installing GRUB?.[41C│.[17;2H│.[75C│.[18;2H│.[20C.[23C.[7m.[23C.[m.(B│.[19;2H│.[75C│.[20;2H└───┘.[18;52H.[18;23H.[7m.[23C.[m.(B.[23C.[18;24.[23C.[7m.[23C.[18;52H.[18;23H.[23C.[m.(B.[23C.[18;24H.[2Generating grub configuration file ... -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191017041105.GA3805%40danwin1210.me.
Re: [qubes-users] Fixing a VM's botched grub install
On Thu, Oct 17, 2019 at 04:58:00AM +, 'awokd' via qubes-users wrote: In Qube Settings, is the kernel set to None? If not, it boots from a kernel provided by Qubes anyways so you don't need grub in that case. It might be a good idea to qvm-copy out anything you need while you still can, in case you can't get it to boot up again. Also try "sudo grub-install /dev/xvda" if your kernel is set to none. No, kernel is set to the default value. Looks like I'm safe then! Backups have already been made :) Thanks! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191017064043.GA4554%40danwin1210.me.
Re: [qubes-users] Fixing a VM's botched grub install
On Thu, Oct 17, 2019 at 01:06:24PM -0700, Jin-oh Kang wrote: This is what I see from your output: https://asciinema.org/a/2sMvgiISVELkjTxAjDlfoNP5Z That's really cool! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191019035452.GA1016%40danwin1210.me.
Re: [qubes-users] Fixing a VM's botched grub install
On Thu, Oct 17, 2019 at 01:24:00PM -0700, Jin-oh Kang wrote: The escape sequence crippling is caused by https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.8/patch-tools-xenconsole-replace-ESC-char-on-xenconsole-outp.patch , which is reasonable given the Qubes security model. For interactive console you could use `qvm-console-dispvm ` provided by the qubes-core-admin package. I wish I had seen that tool earlier! Here's a PR for the community docs: https://github.com/Qubes-Community/Contents/pull/74 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191019044205.GB1016%40danwin1210.me.
Re: [qubes-users] Fixing a VM's botched grub install
On Sun, Oct 20, 2019 at 01:28:29PM +0900, Jin-oh Kang wrote: I'll submit the correction PR when I get to have some free time for it. I apologize for not having made this clear. Meanwhile if you'd like to do it instead -- since you're also the author of the article -- then I'd appreciate it ;) awokd beat us to it. But please do submit a more in-depth explanation when you get a moment! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191020195710.GA4476%40danwin1210.me.
[qubes-users] whonix-ws-15-dvm terminal opens in template
Expected behavior: choosing "Disposable: whonix-ws-15 dvm" | Xfce Terminal from the applications menu opens a terminal window in a new DispVM Actual behavior: terminal opens in the whonix-ws-15-dvm template (equivalent to qvm-run -a) did I miss something somewhere, or is this a bug? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191021131528.GA1622%40danwin1210.me.
Re: [qubes-users] whonix-ws-15-dvm terminal opens in template
On Tue, Oct 22, 2019 at 12:09:27AM +, 'Jackie' via qubes-users wrote: Is the appmenus-dispvm feature turned on for the dvm template? qvm-features dvm-template-name appmenus-dispvm 1 https://www.qubes-os.org/doc/disposablevm-customization/ Tor Browser opens in a DispVM (only xfce-terminal opens in the template) and `qvm-features dvm-template-name` returns appmenus-dispvm 1 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191022040833.GA2748%40danwin1210.me.
[qubes-users] Activating FDE on lid close
From Ratliff's "The Mastermind": "...they were told to close the computer immediately. The TrueCrypt software would be activated as soon as the laptop lid was shut." While most Qubes users are probably not interested in starting global criminal empires, this specific idea seems useful enough. Currently there is no option in Xfce Power Manager to shut down the laptop entirely, and "hibernate" is not supported by Xen. Is there another way to ensure FDE gets fully enabled when the laptop lid is shut? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191024131738.GA6294%40danwin1210.me.
Re: [qubes-users] Activating FDE on lid close
On Thu, Oct 31, 2019 at 11:47:31AM +, Claudia wrote: There is also the possibility of a physical attacker booting their own OS that pretends to be your FDE lock prompt as a way to steal your passphrase. This all depends on the scenario. Specifically, it assumes an evil maid attack, where the machine is compromised and then used by the rightful user again. There are other scenarios where the idea would be useful. Consider if your suspended laptop is just simply stolen by your local county police (who don't know how to mount a real evil maid attack but can perform a cold boot attack). There's a big difference between the key being in RAM or not. The original scenario is that the user shuts the laptop lid knowing that an adversary is about to take control of the machine. In this case, an evil maid attack is not really an issue... by the time the user gets the laptop back, the old infosec adage "nuke it from orbit, it's the only way to be sure" is liable to apply. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191101063853.GA2577%40danwin1210.me.
Re: [qubes-users] Using Mullvad VPN in Qubes
On Fri, Nov 01, 2019 at 06:36:20PM -0400, 'Micah Lee' via qubes-users wrote: In case anyone is interested, I just wrote a blog post about how I configure Mullvad in Qubes, using NetworkManager, a script to auto-connect, and the Qubes firewall. https://micahflee.com/2019/11/using-mullvad-in-qubes/ Any reason you didn't use qubes-vpn-support? https://github.com/tasket/Qubes-vpn-support -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191102091923.GA4590%40danwin1210.me.
[qubes-users] Days since last backup
The built-in Qubes backup functionality is great but it's very easy to forget to run a backup and end up going days (or weeks, or months...) without it. MacOS has a handy feature where it will remind you if it has been more than 10 days since your last backup. This would be great to have in Qubes. And it shouldn't be that hard to run a daily cron job that pops up a notification if there hasn't been a backup for a while. However, I am stuck on how to determine how many days it has actually been since the last backup. Potential options: 1) Assume all backups are done by a shell script, and that shell script somehow saves the date to disk. How do we do this in an easy-to-parse way? 2) Assume backups may happen by command line or GUI (assume we don't know). Where can we find the date of the last backup on disk, and parse it into an integer value that can be checked by a notification 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191121031225.GA9484%40danwin1210.me.
Re: [qubes-users] Days since last backup
On Thu, Nov 21, 2019 at 10:04:59AM -0500, Steve Coleman wrote: However, I am stuck on how to determine how many days it has actually been since the last backup. What you are looking for is this command: qvm-prefs --get $vm backup_timestamp Perfect, 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191122014408.GA10869%40danwin1210.me.
[qubes-users] AppVM stuck as disposable in menu
After creating an AppVM, I experimented with making it (the basis of) a disposable VM, but then un-did the settings and went back to using it as a regular AppVM. Unfortunately it's still showing up in the applications launcher menu as a Disposable VM, and the menu items no longer work for running the VM. If I do `qvm-run VMNAME gnome-terminal` then the VM starts and everything is fine. I've been through all the documentation related to making an AppVM into a disposable VM and the settings all *seem* to have been correctly reverted. I just can't figure out why the menu entries are still wrong. Does anyone have any ideas what could be wrong? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191124132205.GA3685%40danwin1210.me.
Re: [qubes-users] Days since last backup
On Thu, Nov 21, 2019 at 04:12:25AM +0100, tetrahedra via qubes-users wrote: The built-in Qubes backup functionality is great but it's very easy to forget to run a backup and end up going days (or weeks, or months...) without it. MacOS has a handy feature where it will remind you if it has been more than 10 days since your last backup. This would be great to have in Qubes. I've created a script and user-mode anacrontab to automatically remind the user if it's been more than N days since the last backup. Are the qubes-community-docs the best place to document this, or is there a better place for things that involve scripts? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191126042654.GA5378%40danwin1210.me.
[qubes-users] Modern laptops, Intel ME, and AEM
On Tue, Nov 26, 2019 at 01:05:08PM -0800, Lambda wrote: Lenovo's 2019 laptop is currently on sale and their CPU selection[1] includes: - i7-9750H: no vPro, No Out-of-Band Systems Management - i7-9850H: vPro, Intel ME Disabled [--] I'm aware that for AEM support I would need to have ME and TXT 1.2. But those CPUs have TPM 2.x What's the state of modern laptops when it comes to disabling ME and/or using anti-evil-maid features? The Lenovo X1 Carbon Gen 6 is "unofficially" the standard for Qubes developers, but only the (much older) X230 supports the HEADS Anti-Evil-Maid solution (which is different from Qubes AEM, and apparently better). (Coreboot is not supported on the Carbon Gen 6 as far as I know) Similarly I've read that the X230 is the last laptop where it's reasonable to disable Intel ME, but the above email suggests even much newer laptops are available without ME. For users who care about hardware security, do any modern laptops offer the capabilities of the older ones, or is "an upgrade necessarily a downgrade" in this case? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191127110801.GA7404%40danwin1210.me.
[qubes-users] Shutting down a VM when applications close
DispVMs shut down automatically when the launched application closes. Is it possible to enable this for certain applications in certain AppVMs as well? For example I may not want my "resource-heavy-apps-vm" to keep running after MemoryHungryApp closes, because that ties up half my system RAM. How would I configure "resource-heavy-apps-vm" to shutdown automatically when MemoryHungryApp closes? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191127125250.GA7681%40danwin1210.me.
Re: [qubes-users] Shutting down a VM when applications close
On Wed, Nov 27, 2019 at 08:16:28AM -0500, Steve Coleman wrote: You can try this trick when starting your app/vm: dom0> qvm-run -a AppVM "resource-heavy-app;shutdown -h now" When the application closes the next command in line is the shutdown command, and the VM will simply exit. As long as the app does not background itself by forking a new process to demonize this will likely work. If in testing that command works for you, then you can create a specialized AppVM.desktop file, and set the Exec= entry to "resource-heavy-app;shutdown -h now". Once that is done then add that custom desktop file to your template VM in /usr/share/applications and you should then be able to add the application directly to your qubes menu for that specific VM. Thanks! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191128020742.GA1253%40danwin1210.me.
[qubes-users] Making NetVMs follow their AppVMs
If I have a NetVM, called my-vpn-vm, that provides network to my-app-vm, my-vpn-vm will automatically start when I launch an application from my-app-vm. However, when my-app-vm shuts down, my-vpn-vm will stay running. Is there any way to: a) automatically shut down a NetVM when there are no more VMs connected to it? or b) automatically shut down a VM when a specific other VM is no longer running? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191128073150.GA2454%40danwin1210.me.
Re: [qubes-users] Re: Shutting down a VM when applications close
On Fri, Nov 29, 2019 at 11:03:49AM +, lik...@gmx.de wrote: On 2019-11-27 12:52, tetrahedra via qubes-users wrote: DispVMs shut down automatically when the launched application closes. Is it possible to enable this for certain applications in certain AppVMs as well? For example I may not want my "resource-heavy-apps-vm" to keep running after MemoryHungryApp closes, because that ties up half my system RAM. How would I configure "resource-heavy-apps-vm" to shutdown automatically when MemoryHungryApp closes? You could also use a feature of qubes to shutdown a VM after a certain time. You can find steps to enable it to a particular vm in this thread: https://groups.google.com/forum/#!topic/qubes-users/lyABSZGmKdM Now it also works for debian templates. Great! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191130015932.GA3362%40danwin1210.me.
Re: [qubes-users] Fedora 29 has reached EOL
On Fri, Nov 29, 2019 at 04:17:39AM -0600, Andrew David Wong wrote: Please note that no user action is required regarding the OS version in dom0. For details, please see our Note on dom0 and EOL. [6] There have been a lot of dom0 updates recently. Is this related to EOL? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191130023731.GA3570%40danwin1210.me.
[qubes-users] What's the logic behind many similar templates?
By default Qubes comes with two templates for AppVMs: a Debian template and a Fedora one. But many people seem to clone templates, so they also have an e.g "fedora-minimal" template or a "-multimedia" one or any number of other variations. Why not just have "one template to rule them all" for each distribution (Fedora and Debian)? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191130061640.GA3966%40danwin1210.me.
Re: [qubes-users] Fedora 29 has reached EOL
On Fri, Nov 29, 2019 at 11:58:03PM -0600, Andrew David Wong wrote: No, those were not related to EOL. P.S. -- Please do not write to both lists. Ok thanks. Sorry for sending to both, I hit "reply all" and didn't look at the result. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191130065248.GB3966%40danwin1210.me.
Re: [qubes-users] AppVM stuck as disposable in menu
On Mon, Nov 25, 2019 at 03:20:16AM +0100, tetrahedra via qubes-users wrote: After creating an AppVM, I experimented with making it (the basis of) a disposable VM, but then un-did the settings and went back to using it as a regular AppVM. Unfortunately it's still showing up in the applications launcher menu as a Disposable VM, and the menu items no longer work for running the VM. If I do `qvm-run VMNAME gnome-terminal` then the VM starts and everything is fine. I've been through all the documentation related to making an AppVM into a disposable VM and the settings all *seem* to have been correctly reverted. I just can't figure out why the menu entries are still wrong. Does anyone have any ideas what could be wrong? The solution turned out to be: qvm-features --unset VMNAME appmenus-dispvm -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191203051616.GA1429%40danwin1210.me.
Re: [qubes-users] Activating FDE on lid close
On Fri, Nov 01, 2019 at 07:38:53AM +0100, tetrahedra via qubes-users wrote: The original scenario is that the user shuts the laptop lid knowing that an adversary is about to take control of the machine. In this case, an evil maid attack is not really an issue... by the time the user gets the laptop back, the old infosec adage "nuke it from orbit, it's the only way to be sure" is liable to apply. It looks like someone has figured out how to encrypt the laptop on lid suspend, which is fairly close to the original goal: https://github.com/QubesOS/qubes-issues/issues/2890 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191208032843.GA1049%40danwin1210.me.
[qubes-users] sys-net keeps dying
see the corresponding issue: https://github.com/QubesOS/qubes-issues/issues/5508 The tldr is that ever since I upgraded to fedora-30, sys-net has started dying intermittently (or less intermittently, nearly every time) I put my laptop to sleep. This is really problematic. I am wondering if it would make sense to re-create sys-net from scratch. Could it be that this is something from fedora-29 that is not working well with fedora-30? There doesn't seem to be much documentation on how to do this. One post suggests you just create a new VM and call it sys-net: https://www.reddit.com/r/Qubes/comments/amvkz3/how_to_create_net_and_firewall_again_with_default/efpl5i2/ However that doesn't seem right, isn't something extra needed to get the NetworkManager wifi menu widget set up? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191208195653.GA1977%40danwin1210.me.
Re: [qubes-users] Dom0 screencapture with cron
On Thu, Nov 28, 2019 at 09:13:22AM -0800, hoff8h...@gmail.com wrote:
I'm just running through some ideas. Something every hour is a little much,
but I would like to take a screenshot of the whole window after a script is
run. Still the same question.
It's not quite capturing screenshots, but here's a quick script I use to
keep track of what I'm doing at regular intervals, logging the current
time and active window name to a log file:
#!/bin/bash
TZ='UTC-0'; export TZ
LOGFILE="time.log"
INTERVAL=300 # 5 minutes
{
while :
do
date
xdotool getwindowname $(xdotool getactivewindow)
sleep $INTERVAL
done
} | tee $LOGFILE
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/20191209110902.GA2944%40danwin1210.me.
Re: [qubes-users] Days since last backup
On Tue, Nov 26, 2019 at 05:26:54AM +0100, tetrahedra via qubes-users wrote: I've created a script and user-mode anacrontab to automatically remind the user if it's been more than N days since the last backup. Are the qubes-community-docs the best place to document this, or is there a better place for things that involve scripts? Put in a PR for qubes-community-docs, in case anyone wants to review and merge 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191209111246.GB2944%40danwin1210.me.
Re: [qubes-users] sys-net keeps dying
On Thu, Dec 05, 2019 at 03:05:42PM +, Claudia wrote: I am wondering if it would make sense to re-create sys-net from scratch. Could it be that this is something from fedora-29 that is not working well with fedora-30? Did you keep the fedora 29 template installed? If so, I think you could just change the template back to 29 for sys-net and see if that fixes it. If not, perhaps you could downgrade it, or try explicitly installing the fedora 29 template. No, I just deleted the fedora-29 template recently, not realising it might be the root of the issue :/ There doesn't seem to be much documentation on how to do this. One post suggests you just create a new VM and call it sys-net: https://www.reddit.com/r/Qubes/comments/amvkz3/how_to_create_net_and_firewall_again_with_default/efpl5i2/ However that doesn't seem right, isn't something extra needed to get the NetworkManager wifi menu widget set up? Not that I know of. As far as I know, system tray icons are just like a regular window, in that any VM can create them without any special configuration, and they're colored according to the VM. So when you start NetworkManager it should just appear in the tray. I don't know anything about that guide, but it may be worth trying. You can create a new VM called sys-net2 or whatever so you don't have to overwrite your existing sys-net. Then just create a temporary AppVM with sys-net2 as its NetVM to test it. I did create sys-net2 and NetworkManager started automatically (no configuration needed!) and connected to wifi. However, when I try to configure sys-firewall to use sys-net2 instead of sys-net for networking, I get the error: ERROR Basic tab: Failed to access 'netvm' property I have sys-net2 set up in HVM mode, with "provides network" checked in the Advanced tab, the NICs configured in Devices, etc. Other than that the only option I can think of is to debug your current sys-net and fix whatever is causing it to crash. Check /var/log/qubes, /var/log/xen, and `xl dmesg`. I did find some relevant log entries, but I'm not sure how to interpret them. I will post to the relevant Github issue about this: https://github.com/QubesOS/qubes-issues/issues/4658 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191210081042.GA4088%40danwin1210.me.
Re: [qubes-users] sys-net keeps dying
On Wed, Dec 11, 2019 at 11:46:04AM +, 'awokd' via qubes-users wrote: This should work, but make sure sys-firewall is shutdown before attempting to change. If it still isn't, try changing with qvm-prefs sys-firewall. Ok, I didn't realize sys-firewall had to be shutdown. Most of the time you can change a VM's networking without shutting it down first... in any case, once sys-firewall was off, changing networking worked fine. Unfortunately, creating a new sys-net does not appear to have fixed the issue, crashes still occur. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191212041425.GA5975%40danwin1210.me.
[qubes-users] Mike's emails
On Thu, Dec 12, 2019 at 05:23:47PM +, Mike Keehan wrote: Qubes won't help in this situation - see https://www.qubes-os.org/doc/disposablevm/#disposablevms-and-local-forensics They recommend using Tails for this type of situation. Mike. I am getting very many duplicate copies of Mike's emails, but only of emails from Mike. Is this happening to anyone else? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191213023409.GA6832%40danwin1210.me.
Re: [qubes-users] Mike's emails
On Fri, Dec 13, 2019 at 08:59:16AM +0100, David Hobach wrote: I am getting very many duplicate copies of Mike's emails, but only of emails from Mike. Is this happening to anyone else? Probably because he clicked "reply all" on one of your questions like I just did. No, when that happens (as it does with everyone who replies-all to my emails) I only get 2 messages. However I currently have 15 copies of Mike's "Qubes won't help in that situation" email...! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191213230930.GA1701%40danwin1210.me.
[qubes-users] sys-net interfaces
I haven't been able to find any documentation for what network interfaces sys-net is expected to expose internally. If I want to create my own sys-net from scratch, how does Xen/Qubes send network traffic to sys-net, to be sent onwards to my NIC? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191221153318.GA1931%40danwin1210.me.
Re: [qubes-users] sys-net interfaces
On Thu, Dec 26, 2019 at 11:47:37AM +, 'awokd' via qubes-users wrote: tetrahedra via qubes-users: I haven't been able to find any documentation for what network interfaces sys-net is expected to expose internally. If I want to create my own sys-net from scratch, how does Xen/Qubes send network traffic to sys-net, to be sent onwards to my NIC? There's a brief discussion at https://www.qubes-os.org/doc/networking/, but there may be more detailed notes in the source code for Qubes' VM networking components. Qubes uses Xen's networking, so that might be the best place to begin research. Thanks, that's very helpful. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191227061022.GA1186%40danwin1210.me.
Re: [qubes-users] sys-net interfaces
On Thu, Dec 26, 2019 at 11:47:37AM +, 'awokd' via qubes-users wrote: There's a brief discussion at https://www.qubes-os.org/doc/networking/, but there may be more detailed notes in the source code for Qubes' VM networking components. Qubes uses Xen's networking, so that might be the best place to begin research. What responsibilties does sys-net have in terms of forwarding DNS? The documentation specifies how things work for AppVMs, and it says there is no DNS server in the "network driver domain" (sys-net), but it does not say what sys-net actually has to do. Also, the docs don't appear to be entirely accurate. The documentation specifies a fairly complex set of routing tabels for the "network driver domain" (sys-net, I assume), but the actual routing table on my sys-net is fairly simple The table from the documentation: Destination Gateway Genmask Flags Metric Ref Use Iface 10.137.0.16 0.0.0.0 255.255.255.255 UH 0 0 0 vif4.0 10.137.0.7 0.0.0.0 255.255.255.255 UH 0 0 0 vif10.0 10.137.0.9 0.0.0.0 255.255.255.255 UH 0 [... many lines removed ...] 192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 The table from my sys-net: [user@sys-net ~]$ sudo ip route [user@sys-net ~]$ sudo route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default _gateway0.0.0.0 UG60000 wls7 10.137.0.5 0.0.0.0 255.255.255.255 UH32747 00 vif5.0 192.168.0.0 0.0.0.0 255.255.255.0 U 60000 wls7 It looks like the documentation is assuming sys-net has many more virtual NICs than it actually does? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191227070535.GA1464%40danwin1210.me.
[qubes-users] Troubleshooting Qubes graphical slowness
Periodically all graphics-heavy apps (Firefox, ...) in all VMs seem to slow down simultaneously. Rebooting fixes the situation. Running `sudo journalctl -f` in dom0 doesn't show anything unusual. What would you suggest as a next step towards locating the 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191227073310.GA1647%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 08:33:10AM +0100, tetrahedra via qubes-users wrote: Periodically all graphics-heavy apps (Firefox, ...) in all VMs seem to slow down simultaneously. Rebooting fixes the situation. Running `sudo journalctl -f` in dom0 doesn't show anything unusual. What would you suggest as a next step towards locating the problem? vim also appears to be affected by the slowdown. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191227080552.GA1906%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 09:05:52AM +0100, tetrahedra via qubes-users wrote: On Fri, Dec 27, 2019 at 08:33:10AM +0100, tetrahedra via qubes-users wrote: Periodically all graphics-heavy apps (Firefox, ...) in all VMs seem to slow down simultaneously. Rebooting fixes the situation. Running `sudo journalctl -f` in dom0 doesn't show anything unusual. What would you suggest as a next step towards locating the problem? vim also appears to be affected by the slowdown. Further inspection shows there's a LOT of disk I/O going on. after installing iotop in dom0, this appears to be coming from command [NN.xvda-0], presumably one of the VMs. How do I map the NN (number) to a given running VM? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191227083340.GA1952%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 08:49:02AM +, 'awokd' via qubes-users wrote: Further inspection shows there's a LOT of disk I/O going on. after installing iotop in dom0, this appears to be coming from command [NN.xvda-0], presumably one of the VMs. How do I map the NN (number) to a given running VM? Check xl top. I think you can find the offending VM with that. You might be running out of system RAM too, which would be shown at the top. xl top / xentop doesn't show any two-digit number identifying a VM. However by trial and error it looks like the extreme levels of disk I/O are a symptom rather than a cause. After shutting down all slowed-down VMs the disk I/O ended. Then when I re-started a DispVM with Firefox, the high levels of disk I/O (constant read > 50MB/sec) came back and Firefox was slow (as before). Unfortunately I need to get work done so have to reboot to "just make it go away" but I am still interested in troubleshooting ideas (for when it happens next). -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191227085716.GA2170%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 09:57:16AM +0100, tetrahedra via qubes-users wrote: Unfortunately I need to get work done so have to reboot to "just make it go away" but I am still interested in troubleshooting ideas (for when it happens next). One thing I noticed on reboot -- the initial round of stop jobs (when shutting down the system, things like unmounting LUKS volumes) all timed out. Not sure if related. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191227091041.GA1085%40danwin1210.me.
Re: [qubes-users] sys-net interfaces
On Fri, Dec 27, 2019 at 08:46:35AM +, 'awokd' via qubes-users wrote: What responsibilties does sys-net have in terms of forwarding DNS? The documentation specifies how things work for AppVMs, and it says there is no DNS server in the "network driver domain" (sys-net), but it does not say what sys-net actually has to do. It looks like the documentation is assuming sys-net has many more virtual NICs than it actually does? Did you check the Qubes source code responsible for setting these up? The qubes-devel mailing list might also be appropriate here... The documentation mentions the vif-route-qubes utility, but I can't tell if dom0 runs this on sys-net (to set up routing to serve AppVMs) or runs it on AppVMs / etc ... the documentation does not mention any other source code (which would be used to e.g set up DNS forwarding). I will ask on qubes-devel. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191228025332.GA1654%40danwin1210.me.
Re: [qubes-users] Qubes Structure
On Sun, Dec 29, 2019 at 10:56:31AM +0100, xao wrote: Hi! Sorry for the bad question structure, don't know how to write it properly. I've seen some examples of how people setup their system and the most paranoid ones create separate standalone vm for each application and firewall that allows only this application to connect to the internet. Currently, I have 4 template vms - debian 10 with all programs I use installed in it, fedora 30 minimal for netvms, and whonix templates. All my vms that I use on day to day basis are made with debian template. After seeing all those setups I feel that my system is an open garden for hackers and they can do whatever they want, and I will find it out only after I get completely hacked. So, my question is how to setup your system for maximum security? Is there any guidelines on how to do so? I understand that it may be a silly question because it mostly depends on from whom I protect myself, but let's imagine I need to protect from everyone. If you need to protect from everyone then you should turn your computer off, lock it in a vault, embed the vault in a block of solid concrete, bury the whole mess at the bottom of a mine, and post an armed guard at the door. Then you *may* be safe. Ultimately your security is not the product of some "setup" but of the degree to which you understand how your setup works and what the implications are of the choices that you make. If you understand very little, then the most paranoid of setups will get you very little in terms of security, because you will end up making choices that compromise that security -- or you will just end up wasting a great deal of time on things that don't matter. If you need security but don't understand computers, avoid using computers! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191230042414.GC1185%40danwin1210.me.
