Re: [EXT] Re: [qubes-users] Update templates in parallel
On Thursday, 6 August 2020 09:03:31 UTC+8, unman wrote:The security isnt to be found at the proxy level, but at the package management level. It's there that verification is (and should be) done. Unman, speaking of verification at the package management level, would you happen to know the algorithm that's used to verify dom0 and domu packages? I've been looking for this info since I'm worried that it might be the now-deprecated SHA1 (like Github) but I haven't found anything yet. -- I'm not unman, but I just checked the repo data and it appears they use sha256 -- 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/5f2b87ac.1c69fb81.be51c.6641%40mx.google.com.
Re: [qubes-users] Re: Whonix-gw: trouble after disabling passwordless root access
On Thursday, 6 August 2020 00:37:08 UTC+8, Qubes wrote: > > What risk(s) are you mitigating by disabling passwordless root? > You should look at this the other way around--what do I stand to lose by keeping passwordless root? If I can take a low-cost step that would dramatically raise the cost for would-be attackers, wouldn't it be a prudent step to take? Besides, even Joanna herself backtracked on her claim that passwordless root is the best option (forgot where I read it, but I definitely did) -- 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/65c66143-b92a-4846-a6e9-a62f86c8e213o%40googlegroups.com.
Re: [EXT] Re: [qubes-users] Update templates in parallel
On Thursday, 6 August 2020 09:03:31 UTC+8, unman wrote: > > The security isnt to be found at the proxy level, but at the package > management level. It's there that verification is (and should be) done. > Unman, speaking of verification at the package management level, would you happen to know the algorithm that's used to verify dom0 and domu packages? I've been looking for this info since I'm worried that it might be the now-deprecated SHA1 (like Github) but I haven't found anything yet. -- 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/fe72cccb-d589-498b-ab50-ebeb7319a08do%40googlegroups.com.
Re: [qubes-users] GPT or MBR?
On Wed, Aug 05, 2020 at 09:04:41PM +0200, Qubes wrote: > On 8/5/20 8:31 PM, Stumpy wrote: > > On 2020-08-05 12:06, Stumpy wrote: > > > I have win installed on a drive with mbr, should I be able make a > > > vhd and convert that to a RAW and run it as a template in Qubes? > > > > > > If i remember correctly gpt does not play well with qubes? > > > > > > > I guess more to the point, "MBR is better" or "GPT is better" or "either > > is fine" is what I am looking for. > > Thanks! > > > Coreboot is better, look into Coreboot, https://www.coreboot.org. > > Otherwise I would rank UEFI above BIOS in terms of security. > > GPT is part of the UEFI standard, but can be used with legacy BIOS. Coreboot, UEFI, and legacy BIOS are not clearly related to partition tables, which is what MBR and GPT are. Both are fine in the context of Qubes. Stock templates are built using gpt. -- 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/20200806011323.GB456%40thirdeyesecurity.org.
Re: [EXT] Re: [qubes-users] Update templates in parallel
On Wed, Aug 05, 2020 at 05:59:05PM +0200, Qubes wrote: > On 8/5/20 1:07 AM, Ulrich Windl wrote: > > On 8/2/20 4:42 PM, Chris Laprise wrote: > > > On 8/2/20 8:32 AM, fiftyfourthparal...@gmail.com wrote: > > > > I have a ton of templates and standalones (>10), so updating > > > > them one by one serially is a pain. I found a convenient dom0 > > > > script so I thought I'd share. > > > > > > > > Basically, take this and paste it into dom0 then make it > > > > executable. There'a also a handy test function. All credit goes > > > > to Andrea Micheloni. Anyone have similarly handy > > > > modifications/scripts? > > > > > > > > https://m7i.org/tips/qubes-update-all-templates/ > > > > > > IIRC there is an option somewhere in 'qubesctl' for parallel > > > template updates. > > > > Actually instead of parallel updates (assuming limited bandwidth) I'd > > vote for a more verbose progress indicator (in the graphical update > > app): > > Currently the VMs start, update starts, and then ...long time > > nothing..., then the list of packages updated. > > > > Regards, > > Ulrich > > > > > > > > You can check out my github for some interesting stuff. The > > > 'Qubes-scripts' project has a (serial) template updater that lets > > > you select by certain criteria. It could be parallelized pretty > > > easily. > > > > > > Since you have a lot of templates+standalones, the 'findpref' tool > > > might also be of interest. It can bulk search/replace VM prefs, such > > > as changing all the VMs that are using 'sys-vpn1' to use 'sys-vpn3' > > > instead, or change VMs to use a different template. > > > > > > I also wrote 'wyng-backup', a fast LVM incremental backup tool that > > > only scans where LVM reports new activity. > > > > > > Finally, there is a VPN tool and one to enhance VM internal security. > > > > > > I vote for the local proxy to cache updates. Is that not possible? Yes, it is. A simple mechanism is to install apt-cacher-ng, and configure it to listen on port 8082, while removing or masking tinyproxy. This acts as a simple drop in replacement with benefit of caching. To use https in the repositories you need to rewrite them as "http://HTTPS///;, and the caching proxy will then connect using https. To use for Fedora you need to keep an eye on the multiplicity of Fedora repos, and update the repo definitions. Debian and debian based archives work out of the box. > > Would it not make sense if a Fedora-32 or Fedora-32-xx template downloads > for example the latest Firefox that it should be cached locally. When the > next Fedora-32 template checks for updates the system can check what the > latest version is on the repository, if it is the same as the cached version > use the cached copy. This will dramatically reduce update bandwidth > requirements and make updating quick and painless no matter the number of > templateVMs. > > There must be a fancy way of making this secure. When an update is > downloaded for the first time it is verified so we must ensure the cache's > integrity. Maybe the downloaded files can be signed by the users own key > kept in the vault AppVM. > The security isnt to be found at the proxy level, but at the package management level. It's there that verification is (and should be) done. -- 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/20200806010324.GA456%40thirdeyesecurity.org.
Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U
> You have good taste in laptops. :) Haha thank you, as do you, the T14 was second on my list, yeah I suspect there will be plenty of Qubes users on these devices they tick a lot of boxes, I've never used Qubes with >4 Cores so it'll be a nice experience. > Also worth noting is that some Ryzen 4000 power management drivers have just landed in Linux 5.8. Hmm, wonder if I should try building a 4.1 ISO with a Linux 5.8 Kernel, it's interesting because Xen is able to write to the framebuffer just fine, I think it's dom0 that isn't able to remap it so it stays at an address Xen had it configured for, it almost smells like an IOMMU/Memory Mapping issue, not necessarily GPU. There's UEFI Options for the UMA Framebuffer size of 512MB, 1GB and 2GB I've tried all variants unsuccessfully. I don't think it's a Xen issue because I tried simply moving my current laptop's NVMe, when I entered my LUKs Password (Blind) I could see LEDs on the keyboard initialize so I think 4.0.3 does indeed work fine. I don't think there's a migration path for 4.0.3 - 4.1 (Backup & Restore) yet, I don't think the Qubes team have even signed any 4.1 ISOs yet either so I'd rather 4.0.3 but I'll take anything I can get at this point. On Wednesday, August 5, 2020 at 10:18:01 PM UTC+10 Chris Laprise wrote: > On 8/5/20 7:56 AM, Chris Laprise wrote: > > On 8/5/20 6:54 AM, Dylanger Daly wrote: > >> On Wednesday, August 5, 2020 at 4:04:32 PM UTC+10 dylang...@gmail.com > >> wrote: > >> > >> When trying to install Qubes 4.0.3 or 4.1 (Test ISO) into a Ryzen > >> 4750U based laptop, I see xen output, it relinquishes vga to dom0, > >> then black. > >> > >> I managed to enabled logging, where it prints dom0's dmesg super > >> slow, line by line. > >> > >> | > >> efifb:cannot reserve video memory at 0x6000 > >> efi:EFI_MEMMAP isnotenabled > >> | > >> > >> > >> Then it crashes but it continues to come all the way to Anaconda > >> confirming it's a GPU/Memory Issue > >> > >> This seems to be related to UMA / iGPU Memory Management, unsure if > >> it's just that Kernel Support for this CPU is spotty, Fedora 32 Live > >> USB boots perfectly. > >> > >> This is 100% a Display/GPU issue has everything else comes up > >> smitten, I just don't see anything / the framebuffer isn't passed > >> from Xen to dom0. > > Another user had similar symptoms as you with a Ryzen 3200G, apparently > not resolved... > > > https://groups.google.com/d/msgid/qubes-users/75241cee-4e22-4a63-b81e-46581ede9308%40googlegroups.com > > -- > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5989e5ea-5b58-4fed-a091-e26ae09642cbn%40googlegroups.com.
Re: [qubes-users] GPT or MBR?
On 8/5/20 8:31 PM, Stumpy wrote: On 2020-08-05 12:06, Stumpy wrote: I have win installed on a drive with mbr, should I be able make a vhd and convert that to a RAW and run it as a template in Qubes? If i remember correctly gpt does not play well with qubes? I guess more to the point, "MBR is better" or "GPT is better" or "either is fine" is what I am looking for. Thanks! Coreboot is better, look into Coreboot, https://www.coreboot.org. Otherwise I would rank UEFI above BIOS in terms of 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/3529d79b-f79d-66e4-6392-80174e17fe52%40ak47.co.za.
Re: [qubes-users] GPT or MBR?
On 2020-08-05 12:06, Stumpy wrote: I have win installed on a drive with mbr, should I be able make a vhd and convert that to a RAW and run it as a template in Qubes? If i remember correctly gpt does not play well with qubes? I guess more to the point, "MBR is better" or "GPT is better" or "either is fine" is what I am looking for. 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/57f40189-077b-36e9-7056-96200032e83e%40posteo.net.
Re: [qubes-users] Re: Whonix-gw: trouble after disabling passwordless root access
On 8/5/20 6:12 PM, fiftyfourthparal...@gmail.com wrote: On Wednesday, 5 August 2020 02:29:46 UTC+8, 54th Parallel wrote: Hi all, Sorry for the recent spam--I've been spending a lot more time with Qubes and coming across issues that I haven't seen mentioned here yet. Here's another one: If you disable passwordless root access in whonix-gw, tor control panel (accessed by right clicking the sw-date tray icon) stops working entirely, and whonix-ws will cause whonix-gw to continually spam you with dom0 sudo prompts if you enabled that. Ignoring them and dragging them off to another workspace hasn't caused any issues, but it's still annoying to deal with. Has anyone else had this experience or have any suggestions? Problem seems to have gone away after using configure-sudo-prompt from tasket's qubes-vm-hardening on a fresh installation of qubes-template-whonix-gw-15 What risk(s) are you mitigating by disabling passwordless root? -- 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/e7f4c948-421e-1d38-a16a-f8047521ace3%40ak47.co.za.
[qubes-users] Re: Whonix-gw: trouble after disabling passwordless root access
On Wednesday, 5 August 2020 02:29:46 UTC+8, 54th Parallel wrote: > > Hi all, > > Sorry for the recent spam--I've been spending a lot more time with Qubes > and coming across issues that I haven't seen mentioned here yet. > > Here's another one: > > If you disable passwordless root access in whonix-gw, tor control panel > (accessed by right clicking the sw-date tray icon) stops working entirely, > and whonix-ws will cause whonix-gw to continually spam you with dom0 sudo > prompts if you enabled that. Ignoring them and dragging them off to another > workspace hasn't caused any issues, but it's still annoying to deal with. > > Has anyone else had this experience or have any suggestions? > Problem seems to have gone away after using configure-sudo-prompt from tasket's qubes-vm-hardening on a fresh installation of qubes-template-whonix-gw-15 -- 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/e7c475aa-206e-4f5c-bf09-8d6f24e344cao%40googlegroups.com.
[qubes-users] GPT or MBR?
I have win installed on a drive with mbr, should I be able make a vhd and convert that to a RAW and run it as a template in Qubes? If i remember correctly gpt does not play well with qubes? -- 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/4204f4ff-63b6-825c-ef9a-59870e433a02%40posteo.net.
Re: [EXT] Re: [qubes-users] Update templates in parallel
On 8/5/20 1:07 AM, Ulrich Windl wrote: On 8/2/20 4:42 PM, Chris Laprise wrote: On 8/2/20 8:32 AM, fiftyfourthparal...@gmail.com wrote: I have a ton of templates and standalones (>10), so updating them one by one serially is a pain. I found a convenient dom0 script so I thought I'd share. Basically, take this and paste it into dom0 then make it executable. There'a also a handy test function. All credit goes to Andrea Micheloni. Anyone have similarly handy modifications/scripts? https://m7i.org/tips/qubes-update-all-templates/ IIRC there is an option somewhere in 'qubesctl' for parallel template updates. Actually instead of parallel updates (assuming limited bandwidth) I'd vote for a more verbose progress indicator (in the graphical update app): Currently the VMs start, update starts, and then ...long time nothing..., then the list of packages updated. Regards, Ulrich You can check out my github for some interesting stuff. The 'Qubes-scripts' project has a (serial) template updater that lets you select by certain criteria. It could be parallelized pretty easily. Since you have a lot of templates+standalones, the 'findpref' tool might also be of interest. It can bulk search/replace VM prefs, such as changing all the VMs that are using 'sys-vpn1' to use 'sys-vpn3' instead, or change VMs to use a different template. I also wrote 'wyng-backup', a fast LVM incremental backup tool that only scans where LVM reports new activity. Finally, there is a VPN tool and one to enhance VM internal security. I vote for the local proxy to cache updates. Is that not possible? Would it not make sense if a Fedora-32 or Fedora-32-xx template downloads for example the latest Firefox that it should be cached locally. When the next Fedora-32 template checks for updates the system can check what the latest version is on the repository, if it is the same as the cached version use the cached copy. This will dramatically reduce update bandwidth requirements and make updating quick and painless no matter the number of templateVMs. There must be a fancy way of making this secure. When an update is downloaded for the first time it is verified so we must ensure the cache's integrity. Maybe the downloaded files can be signed by the users own key kept in the vault AppVM. -- 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/efc80a20-21a1-f26f-3f2d-2547d91814ce%40ak47.co.za.
Re: [EXT] Re: [qubes-users] Getting to the bottom of screenshots in Qubes OS
On 8/5/20 12:21 AM, Ulrich Windl wrote:
On 7/8/20 8:24 AM, haaber wrote:
On 7/8/20 2:39 AM, Manuel Amador (Rudd-O) wrote:
On 20/06/2020 10.29, Logan wrote:
Hi Everyone,
Speaking with a colleague earlier today, I heard "Qubes is great, but
the no screenshots problem makes it a 'hard' no for me".
As a Qubes user and advocate, this stung.
Yeah, it's hard.
Honestly, in my humble opinion, the secure copy and paste keyboard
shortcuts should work with image data as well, not just text data. That
way the screenshot problem is solved -- I can screenshot in one VM, copy
directly from that app (usually Firefox), and paste in another VM at
will.
A solution discussed here some months ago: in dom0 have 2 files:
1.) screenshot.sh
#!/bin/bash
qvm-copy-to-vm $(zenity --entry --title='Send to VM' --text='Destination
VM') "${BASH_ARGV[@]}"
2) and userapp.screenshot.desktop
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/home/put-your-username-here/screenshot.sh %f
Name=screeenshot.sh
Comment=Sends screenshot directly to a given AppVM
after hitting PrintScr, check "open with" and select screenshot.sh,
(will be memorised for next time). Then type the destination AppVM & its
there. No autocomplete offered, sorry.
When I tried it, "Open with" just has an empty pull-down list. Is there
any additional step to do?
Why not just use the tool suggested by Eva Dogstar, the users own
developed tool, https://github.com/evadogstar/qvm-screenshot-tool, it
works fantastic. Check it out! It solve all of your screenshot
headaches. I would definitely vote to have it baked into the next Qubes
release.
The only 'problem' that I have, maybe Eva can answer, is after using the
tool it pops up a menu asking what you want to do with the screenshot.
If I don't make any selections my logic tells me the screenshot should
not be saved anywhere, as you specifically need to select to keep it in
dom0. But not selecting anything and clicking ok still saves the
screenshot to dom0.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/1647a215-56c1-4e21-3bd1-44dba98ac984%40ak47.co.za.
Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U
On 8/5/20 7:56 AM, Chris Laprise wrote: On 8/5/20 6:54 AM, Dylanger Daly wrote: On Wednesday, August 5, 2020 at 4:04:32 PM UTC+10 dylang...@gmail.com wrote: When trying to install Qubes 4.0.3 or 4.1 (Test ISO) into a Ryzen 4750U based laptop, I see xen output, it relinquishes vga to dom0, then black. I managed to enabled logging, where it prints dom0's dmesg super slow, line by line. | efifb:cannot reserve video memory at 0x6000 efi:EFI_MEMMAP isnotenabled | Then it crashes but it continues to come all the way to Anaconda confirming it's a GPU/Memory Issue This seems to be related to UMA / iGPU Memory Management, unsure if it's just that Kernel Support for this CPU is spotty, Fedora 32 Live USB boots perfectly. This is 100% a Display/GPU issue has everything else comes up smitten, I just don't see anything / the framebuffer isn't passed from Xen to dom0. Another user had similar symptoms as you with a Ryzen 3200G, apparently not resolved... https://groups.google.com/d/msgid/qubes-users/75241cee-4e22-4a63-b81e-46581ede9308%40googlegroups.com -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/97da6d42-2548-f29d-df31-6b69105cab92%40posteo.net.
Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U
On 8/5/20 6:54 AM, Dylanger Daly wrote: The Device is a Lenovo X13 (AMD). You have good taste in laptops. :) Does anyone have any ideas? I've tried essentially all variations on the "UEFI Troubleshooting" guide I have a Thinkpad T14 with a Ryzen 4750U on its way. These new Ryzen APUs are becoming popular... its going to become a real sticking point to get them working with Qubes! A user named Claudia had a long thread about installing Qubes on a previous gen Ryzen... https://groups.google.com/d/msgid/qubes-users/ae710f3839c46261d257d7d188da32b9%40disroot.org Also worth noting is that some Ryzen 4000 power management drivers have just landed in Linux 5.8. On Wednesday, August 5, 2020 at 4:04:32 PM UTC+10 dylang...@gmail.com wrote: When trying to install Qubes 4.0.3 or 4.1 (Test ISO) into a Ryzen 4750U based laptop, I see xen output, it relinquishes vga to dom0, then black. I managed to enabled logging, where it prints dom0's dmesg super slow, line by line. | efifb:cannot reserve video memory at 0x6000 efi:EFI_MEMMAP isnotenabled | Then it crashes but it continues to come all the way to Anaconda confirming it's a GPU/Memory Issue This seems to be related to UMA / iGPU Memory Management, unsure if it's just that Kernel Support for this CPU is spotty, Fedora 32 Live USB boots perfectly. This is 100% a Display/GPU issue has everything else comes up smitten, I just don't see anything / the framebuffer isn't passed from Xen to dom0. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7d9cc7b3-6d98-7ea2-177c-db587f03fa4f%40posteo.net.
Re: [qubes-users] Can my pc be compromised and if so can I just create a new net-vm and firewall-vm and if so how when I can’t clone them ?
On 8/5/20 7:40 AM, Chris Laprise wrote: On 8/5/20 3:46 AM, anneeyr...@gmail.com wrote: Can I just delete the firewall-vm and the net-vm and create new ones afterwards and shall I just create them in the same way when creating new app-vm’s or standalone-vm’s or how shall I create them when I can’t clone them ? The possibility for sys-firewall to be compromised is pretty low, but if you wipe/replace sys-net its easy to do the same for sys-firewall 'just in case'. To do it for sys-net, here is the one-step method in dom0: sudo blkdiscard /dev/qubes_dom0/vm-sys-net-private Be careful, as 'blkdiscard' is basically a bulk erase command. There are other ways to do it, such as creating a new replacement for sys-net, but they involve multiple steps and are frankly a bit frustrating to describe and use. I should have mentioned to shut down sys-net first. Using 'qvm-kill sys-net' from the command line will do this without fuss. Then do the 'blkdiscard' step. After the 'blkdiscard' you can start the wiped sys-net with 'qvm-start sys-net'. You will need to re-enter any Wifi passwords that you were using. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a3eeab34-543f-a588-f14f-0527d74786fb%40posteo.net.
Re: [qubes-users] Can my pc be compromised and if so can I just create a new net-vm and firewall-vm and if so how when I can’t clone them ?
On 8/5/20 3:46 AM, anneeyr...@gmail.com wrote: I’m a victim of stalking. Lately my 3. new mobile in about a year 1 day after using it suddenly said that it’s new sim card was blocked. And sadly I restarted the phone although I thought the reason for this was that it had been compromised and probably should had set it back to factory settings. I was at my parents house at he time and the phone haven’t been any other place at the time. Afterwards I found a sign of a installed and deleted app on my mothers Ipad. I have read on the web that it is possible to use software like for example an Ipad app to get access to mobile phones and mobile broadband. As my new pc also only have been there and I have Qubes OS installed on it and I have been using my own mobile broadband modem together with it, I wonder if my pc also can be infected and if so could it be that only the firewall-vm and the net-vm is compromised or could it be the whole system... ? Are you confident the Qubes boot partition is safe? That is the vulnerable spot in terms of someone getting physical access to your machine. A few things can help keep boot safe: 1. Anti-evil maid 2. Heads 3. Putting an ATA lock password on your internal boot drive The third option is not considered very strong, but its still a deterrent of sorts and its easier to setup than the first two. Can I just delete the firewall-vm and the net-vm and create new ones afterwards and shall I just create them in the same way when creating new app-vm’s or standalone-vm’s or how shall I create them when I can’t clone them ? The possibility for sys-firewall to be compromised is pretty low, but if you wipe/replace sys-net its easy to do the same for sys-firewall 'just in case'. To do it for sys-net, here is the one-step method in dom0: sudo blkdiscard /dev/qubes_dom0/vm-sys-net-private Be careful, as 'blkdiscard' is basically a bulk erase command. There are other ways to do it, such as creating a new replacement for sys-net, but they involve multiple steps and are frankly a bit frustrating to describe and use. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/eb7fec04-2962-db2f-f3c2-a30047162004%40posteo.net.
[qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U
The Device is a Lenovo X13 (AMD). Does anyone have any ideas? I've tried essentially all variations on the "UEFI Troubleshooting" guide On Wednesday, August 5, 2020 at 4:04:32 PM UTC+10 dylang...@gmail.com wrote: > When trying to install Qubes 4.0.3 or 4.1 (Test ISO) into a Ryzen 4750U > based laptop, I see xen output, it relinquishes vga to dom0, then black. > > I managed to enabled logging, where it prints dom0's dmesg super slow, > line by line. > > efifb: cannot reserve video memory at 0x6000 > efi: EFI_MEMMAP is not enabled > > > Then it crashes but it continues to come all the way to Anaconda > confirming it's a GPU/Memory Issue > > This seems to be related to UMA / iGPU Memory Management, unsure if it's > just that Kernel Support for this CPU is spotty, Fedora 32 Live USB boots > perfectly. > > This is 100% a Display/GPU issue has everything else comes up smitten, I > just don't see anything / the framebuffer isn't passed from Xen to dom0. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5931ce9a-6f20-4083-bbce-e66e77b28f99n%40googlegroups.com.
[qubes-users] Can my pc be compromised and if so can I just create a new net-vm and firewall-vm and if so how when I can’t clone them ?
I’m a victim of stalking. Lately my 3. new mobile in about a year 1 day after using it suddenly said that it’s new sim card was blocked. And sadly I restarted the phone although I thought the reason for this was that it had been compromised and probably should had set it back to factory settings. I was at my parents house at he time and the phone haven’t been any other place at the time. Afterwards I found a sign of a installed and deleted app on my mothers Ipad. I have read on the web that it is possible to use software like for example an Ipad app to get access to mobile phones and mobile broadband. As my new pc also only have been there and I have Qubes OS installed on it and I have been using my own mobile broadband modem together with it, I wonder if my pc also can be infected and if so could it be that only the firewall-vm and the net-vm is compromised or could it be the whole system... ? Can I just delete the firewall-vm and the net-vm and create new ones afterwards and shall I just create them in the same way when creating new app-vm’s or standalone-vm’s or how shall I create them when I can’t clone 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/ee255413-b7a4-42f8-b226-8d324de539afo%40googlegroups.com.
[qubes-users] Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U
When trying to install Qubes 4.0.3 or 4.1 (Test ISO) into a Ryzen 4750U based laptop, I see xen output, it relinquishes vga to dom0, then black. I managed to enabled logging, where it prints dom0's dmesg super slow, line by line. efifb: cannot reserve video memory at 0x6000 efi: EFI_MEMMAP is not enabled Then it crashes but it continues to come all the way to Anaconda confirming it's a GPU/Memory Issue This seems to be related to UMA / iGPU Memory Management, unsure if it's just that Kernel Support for this CPU is spotty, Fedora 32 Live USB boots perfectly. This is 100% a Display/GPU issue has everything else comes up smitten, I just don't see anything / the framebuffer isn't passed from Xen to dom0. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/229dd210-ad9f-43b4-984b-6ad8905091f4o%40googlegroups.com.
