[qubes-users] Re: Discourse site stuck in read-only mode

[54th Parallel]

The problem resolved itself. I looked around and it seems like the site is 
put in read-only mode when Discourse does maintenance.

On Thursday, 4 February 2021 at 11:07:15 UTC+8 54th Parallel wrote:

> I noticed that the Discourse site is stuck in read-only mode. I tried 
> logging out, but it's not letting me, citing read-only mode. 
>
> Anyone else having the same issue?
>

-- 
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/7ae85ba3-7bed-4f87-892a-f8e215678f0cn%40googlegroups.com.

[qubes-users] Discourse site stuck in read-only mode

[54th Parallel]

I noticed that the Discourse site is stuck in read-only mode. I tried 
logging out, but it's not letting me, citing read-only mode. 

Anyone else having the same issue?

-- 
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/08fb567b-c842-4d71-8722-68e36773787an%40googlegroups.com.

[qubes-users] Re: Current state of Wireguard and Qubes

[54th Parallel]

On Wednesday, 2 December 2020 at 05:01:10 UTC+8 evado...@gmail.com wrote:

> looks like not it's at buster-backports...
>

Enable the testing repo by modifyting `/etc/apt/sources.list` in the 
TemplateVM and adding `deb https://deb.debian.org/debian testing main`.

Don't forget to set your default repo to buster so you don't pull 
everything from testing (I'll leave it to you to find out how).

-- 
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/29c65d52-fb21-4661-b4d7-6d0148715a99n%40googlegroups.com.

[qubes-users] Re: Current state of Wireguard and Qubes

[54th Parallel]

On Tuesday, 1 December 2020 at 16:44:31 UTC+8 evado...@gmail.com wrote:

> New 5.4 kernel announced support Wireguard? Can I install it and them 
> create fedora AppVM with wireguard? 
>
> Or what is the better way now to install wireguard appvm? Only the way to 
> go with Debian 10?
>
> Thanks
>

I use wireguard on Debian minimal and it works fine. You have to enable 
Debian's testing repo to install it. Kernel 5.4 supports WG natively, but 
the default 4.x kernels for R4.0 do not, so you should install 
`kernel-latest-qubes-vm` via `qubes-dom0-update` and be sure to select it 
as your WG VM's kernel.

The following guide is helpful even if you're not using Mullvad 
VPN: https://mullvad.net/en/help/wireguard-and-mullvad-vpn/

-- 
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/71739aa2-6f27-4430-971d-3806c551e23an%40googlegroups.com.

[qubes-users] Re: QSB #060: Multiple Xen issues (XSA-345, XSA-346, XSA-347)

[54th Parallel]

>
> XSA-346, XSA-457: A malicious domain with a PCI device (e.g., sys-net or
> sys-usb in the default configuration) could try to exploit this
> vulnerability in order to crash the host. 
>

Just wanted to point out that there's a very minor typo here ('XSA-457'). 
Also, since the last QSB was posted on Discourse, I was wondering if this 
should be too. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/534c619e-323c-405d-9ec0-ae27352af41dn%40googlegroups.com.

Re: [qubes-users] Grsecurity+Debian 10 has issues when PCI devices are being attached

[54th Parallel]

On Friday, 9 October 2020 at 18:07:56 UTC+8 drw...@gmail.com wrote:

> I should've been a bit more clear but yes by PVH I meant virt_mode == hvm.
>
> On Friday, October 9, 2020 at 3:18:35 AM UTC+2 Jarrah wrote:
>
>>
>> > I've been trying to get a Debian 10 sys-net running with grsecurity as 
>> a 
>> > kernel. However, i've been running into some trouble when the PCI 
>> devices 
>> > are being attached to it. libxenlight is giving me errors and the PVH 
>> VM 
>> > will never even attempt to boot. 
>>
>>
>> Just to check, are you trying to boot a PVH VM with PCI devices? That's 
>> only supported on HVM (and PV). Try changing 'virt_mode' to 'hvm' 
>>
>>
>>
Hi Jurre,

How were you able to get a grsec kernel? I though grsec is 
propietary/paid-for only now. Would love to get my hands on it if 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/92dcfe29-03f4-41d7-9902-be7934c7d3f1n%40googlegroups.com.

[qubes-users] Re: Xen ported to Rasberry Pi 4

[54th Parallel]

On Wednesday, 30 September 2020 at 14:05:20 UTC+8 sandyi...@gmail.com wrote:

> (from Slashdot) 
> https://www.theregister.com/2020/09/29/xen_on_rpi_4/ 
>

*Salivates over the prospect of ARM 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/6d224e6d-a449-44d0-aa0c-5eaf1a7e669bn%40googlegroups.com.

Re: [qubes-users] Re: Announcement: New community forum for Qubes OS users!

[54th Parallel]

On Tuesday, 15 September 2020 at 01:13:13 UTC+8 m.fernande...@gmail.com 
wrote:

> The cloud-based aspect of Chromebooks means that in those situations where 
> you don't consider you have much local on-site security, you can gain extra 
> security by keeping things in the cloud, and using cloud software. I cover 
> some of the reasons why this is the case, in the "Sandboxing and cloud 
> computing" section I wrote in the End-user Computer Security book hosted on 
> Wikibooks (which can be accessed here 
> 
> ).
>
> Otherwise, Chromebooks can have security advantages because they use an 
> open-source secure custom BIOS/UEFI known as Coreboot. Vendor-supplied OEM 
> pre-installed closed-source BIOS/UEFI firmware can pose a security 
> vulnerability--they can also be hard to replace with a custom firmware 
> (which I'm particularly finding at the moment). Some info on the security 
> aspects of custom BIOS/UEFI firmware can be found here 
> 
> .
>
> That said, I definitely have security concerns over using the cloud. 
> Keeping things on-site would probably be ideal in the case that you have 
> strong on-site security.
>

Hi Mark,

I've read your wiki entries and enjoyed them--thanks for taking the time to 
share the information. I just want to clarify that Chromebooks do have 
local storage and that this can be completely isolated from the cloud (and 
usually is). This means I can choose not to be at the mercy of the cloud 
and the condition of my internet connection. 

Also, I've been looking for evidence that Chromebooks generally have 
Coreboot installed several years ago before using Chromebooks and now after 
reading your article. I've failed to find any so far, aside from sites like 
MrChromebox that mentions older devices. I know that there are ARM 
Chromebooks, but from a business point of view I don't really see why 
Google would feel the need to replace ME with Coreboot for the wide variety 
of CPUs in their devices (though I wish it were true).

-- 
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/3579f8bf-372f-44b8-8d32-cb06cd15f498n%40googlegroups.com.

Re: [qubes-users] Re: Announcement: New community forum for Qubes OS users!

[54th Parallel]

On Wednesday, 26 August 2020 at 10:52:47 UTC+8 sv...@svensemmler.org wrote:

> Here are my thoughts: security is on a spectrum, here are two extremes: 
>
> a) 
> - - completely offline 
> - - in a locked room at a secure location 
> - - completely shielded 
> - - I never leave that room 
>
> b) 
> - - always connected to the internet 
> - - running on proprietary hardware 
> - - software is partly or completely closed 
> - - data lives "in the cloud" (aka other peoples computer) 
>
> Security is also about what I want to be secure from. 
>
> a) keeps me pretty secure except from the government of the location 
>
> b) keeps (maybe) some script kiddies away if the provider knows their 
> stuff, but any skilled criminal / company / state actor own you in no ti 
> me 
>
> ... which is why I have no understanding at all for all those 
> companies moving their stuff into office365 ... what are they thinking? 
>
> /Sven 
>

Well, if this is a criticism of me using Chrome OS for certain tasks, may I 
politely suggest that you take some time to read about Chrome OS as well. 
The assumption that my data lives in the cloud is not necessarily true and 
my threat model (which is basically what your post is about) is different, 
but the wider point I want to make is that people jump on Chrome OS simply 
for being an OS by Google. 

Qubes (the user in the thread) isn't wrong when he said that privacy and 
security are two sides of the same coin, but, provided you're aware of the 
potential risks (e.g. profile-building, keystroke deanonymization, and much 
more), Chrome OS is cheap and sufficient enough for this particular set of 
low-stake needs I have. That said, I bought two new laptops just for Qubes 
and have sunk months into understanding it, so I'm not shilling for Chrome 
OS here.

Security overview for the open-source Chromium OS (Gentoo-based) which 
forms the base for Chrome OS:
https://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview

-- 
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/71ae9e45-3af8-4b1f-a860-2f6a26366463n%40googlegroups.com.

Re: [qubes-users] sys-firewall based on debian-10-minimal not recognized

[54th Parallel]

On Wednesday, 26 August 2020 at 11:00:36 UTC+8 sv...@svensemmler.org wrote:

> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> On 8/22/20 10:10 AM, unman wrote: 
> > To deal with the question here, I use debian minimal templates 
> > extensively, (NOT with qubes-vm-hardening), and have never seen 
> > this issue - neither the unreliable firewall nor the warning 
> > prompts issue. I've asked fellow users who also use debian-minimal 
> > and they do no not recognise the issue. 
>
> As mentioned earlier ... I have seen it. Both with debian-10-minimal 
> and debian-10-minimal + kicksecure. However, just like before... when 
> I retraced my steps the problem went away. 
>
> I suspect that maybe one of the packages that need to be installed 
> runs a post-install script that sometimes fails (I have no proof). 
>
> Another thing that caused many issues for me (until I recognized and 
> fixed it) was that the time in my sys-net was wrong. 
>
> Sorry, got no answers... just observations. 
>
> /Sven 
>
> - -- 
> public key: https://www.svensemmler.org/0x8F541FB6.asc 
> fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6 
> -BEGIN PGP SIGNATURE- 
>
> iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl9F0CQACgkQ2m4We49U 
> H7YfYBAAjlyS/ehbhbztuYNMMqU7HLoUk3LGCwJpBoe67Nz5+DB1H3gbM7l9T1xc 
> 7opa7aRbOUa1aI88sZUuOgFhvQHbokho9X9ebbADjjTYQHhiiBXqO3pULgh+P8+g 
> jHCObPgID/OX7ceiS7hp7Cy+SiDm1ZrUQIdSFlCduZJYC44a6BauSaF5P9o+fpnq 
> FlFSbLGq1XyLQcKtr6Gl5rgYVa52UfTWzKt9+TGzIyAV/TRbLisInvI9RhkmVBvj 
> yMJYbgYsjyjKLqFMvLzeMeeJoriHzNzWz6Zqwbmw6NXkGFAqmqCSfYLyLprgnPyf 
> g8DGkGhRmp9awK77C8HfruqyfADPsdXYrHdVxBJbiSOB7CKbst3ZIBCVvVfwD0oY 
> 8DGNXAfP5hN7wWuRas6IshRArgk0ujuU0uR8EQpOMgI/qutZYY1LiA8BQ0o7RhUf 
> o3Rc4JM4lU10EQPafZOeWDQueD4v837dd5IkCuNKeidRmCvFzIHu7/SJFlOvnbWB 
> PNi23k3Hxx8x5hHDUDK72tXcEWawdiUJ6NMfmQG31N/zptBu8FGBFROn8Ww+XJRb 
> ePIfHmcsdNJFekWzDe4Fa8B2EpioL4QJ8Gcqy3rFmn7ZQ870prAOpT8WbNYk49BW 
> fgd/H8PBXB09aa0oHYc2KBGphrbXToIDlBLULCe5HeCKxtp/tj0= 
> =hvfa 
> -END PGP SIGNATURE- 
>

Hi Sven,

Thanks for returning to this thread. As per unman's request, I have 
continued the discussion at the discourse.groups forum (
https://qubes-os.discourse.group/t/debian-10-minimal-firewall-issues/146/7). 
My sys-net time has also slipped, like yours, on occasion. Sometimes it's 
12+ minutes behind. This is apparently a common issue that's due to be 
fixed  (https://github.com/QubesOS/qubes-issues/issues/4939), so if this 
was a cause of firewall issues, more people should have noticed it. 

Also, unman correctly pointed out that I misspoke when I said that my 
issues are the same as yours, as you seem to focus on the warning prompt 
that shows when attempting to edit firewall rules, while I have that 
problem plus qubes-firewall.service being unreliable. Anyways, as a 
non-technical user, I'm in the same boat as you--no answers, just 
observations. I managed to get Mirage firewall 
 running and I highly 
recommend it to you in particular since it takes a lot of uncertainty out 
of the issue while being easy to use.

-- 
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/a9379287-0b26-4a1d-9c93-8a82ef7f06bbn%40googlegroups.com.

[qubes-users] Re: Fwd: Audio not working: "snd_hda_intel: No response from codec, resetting bus"

[54th Parallel]

On Monday, 27 July 2020 at 23:52:20 UTC+8 fiftyfour...@gmail.com wrote:

>
> Hi Claudia,
>
> I'm suffering from the same problem as you, and 'dmesg | grep -i 
> snd_hda_intel' brought me to this thread. 
>
> My sound was originally working fine after I updated dom0 and domus 
> (tested via Youtube) but somewhere along the line something broke and the 
> next time I did the same thing, no sound. I did everything in my 
> non-technical power but it's dead, bub. No idea what caused it.
>
> dmesg output in short:
>
> snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
> switching to polling mode: last cmd=0xX
>
> snd_hda_intel [Audio device PCI code thing]: No response from codec, 
> resetting bus: last cmd=0xX(this line keeps repeating)
>
> snd_hda_intel [Audio device PCI code thing]: azx_get_response timeout, 
> switching to single_cmd mode: last cmd=0xX
>
> snd_hda_codec_realtek hdaudioC0D0: Unable to sync to register 0xXXX. -5
> snd_hda_codc_hdmi hdaudioC0D2: HDMI: invalid ELD buf size   (note I'm not 
> using HDMI)
>

Update for the benefit thread readers:

On Dell Inspiron 5593, updating dom0 to kernel 5.7 solved the audio problem 
(audio starts unreliably after boot--sometimes it works tens of minutes or 
hours after boot, making it hard to narrow down which actions caused it to 
start, if any did), but left hibernation and suspension inoperable.  On the 
current kernel (4.19) the problem for some reason seems to have solved 
itself. Maybe it's because I don't use audio on that machine near boot 
(unless for testing).

Oh, and this is important to those who value their hearing--keeping your 
headphones plugged into the headphone jack when booting on 4.19 leads to 
loud screeching noises resembling the death throes of autistic parrots 
suffocating on helium. The sound is apparently correlated with CPU use. Not 
sure what's going on there,  but my guess is the kernel confused the output 
with some other channel or there's some leaking somewhere.

-- 
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/27605dfc-f4be-4619-8c5e-0193f3006bd0n%40googlegroups.com.

[qubes-users] Re: Unable to installes mirage-firewall: this version of runc doesn't work on cgroups v2

[54th Parallel]

On Sunday, 23 August 2020 at 07:51:11 UTC+8 one7...@gmail.com wrote:

> Hello,
>
> I'm trying to install mirage-fw with a Fedora-32 Build-AppVM and run into 
> the following error:
>
> OCI runtime create failed: this version of runc doesn't work on cgroups 
> v2: unknown
>
[...]
>
Any ideas how to workarround this problem or if I need to use another AppVM 
> fedora-30 to build mirage
>
> 799
>

Long story short: Docker doesn't install properly on Fedora versions >30 
because they have cgroups v2. While it's possible to downgrade cgroups in 
Fedora >30, I think it's simpler to just use fedora-30 or its minimal 
version. I wasn't able to get past the Docker installation step in Fedora 
32 without knowing about the cgroup v2 issue, so I don't know how the first 
you read of it was during the building process.

-- 
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/77d3b3c1-a73e-4b26-830e-5e1766ae4f91n%40googlegroups.com.

Re: [qubes-users] sys-firewall based on debian-10-minimal not recognized

[54th Parallel]

On Saturday, 22 August 2020 at 18:57:22 UTC+8 Frank Schäckermann wrote:

> I am not sure what you mean with „behind a vpn vm“.
>
> My setup is such that I have the sys-net VM which is used as network vm in 
> sys-firewall and a few sys-vpn-xxx. sys-firewall in turn is used as network 
> vm for all app VMs that connect directly to the internet and the 
> sys-vpn-xxx VMs are used by various VMs that connect through the various 
> VPNs. There is no need for extra proxy or firewall VMs, since the 
> sys-vpn-xxx can themselves double as firewall VMs, since they are proxy VMs 
> already. Therefore any rules specified in any of the app VMs (no matter if 
> directly connected through sys-firewall or indirectly through a vpn) are 
> taken care of by the network vm they are connected to. And I have never had 
> a problem with this setup. At least none, that I am aware of.  ;-)
>

Thank you for your time, Frank.

Right now my setup is as follows:

*Internet -- sys-net (disp) -- sys-firewall-1 (disp) -- sys-vpn (disp) -- 
sys-firewall-2 (disp) -- appVMs*

I chose to separate sys-vpn and sys-firewall-2 despite knowing that sys-vpn 
can also act as a firewall. This is because I want to have another layer of 
isolation, so that a compromised sys-vpn wouldn't bring down the firewall 
that filters the contents of the VPN connection. Is this setup causing 
issues for the upstream firewalls? If so, why would it be, since the number 
of downstream firewalls are the same in both our setups.

Also don’t forget, that a proxy vm set as network vm for your sys-vpn, will 
> never see anything other than the sys-vpn connecting to your vpn provider’s 
> server. Therefore any rules specified in your sys-vpn are pretty much 
> useless.
>

The way I understand how firewalls works in Qubes is that the firewall 
executes rules for upstream VMs, so using my setup as an example, 
firewall-1 takes orders from sys-vpn, while firewall-2 takes orders from 
the appVMs. Firewall-1 is therefore important for stopping unwanted inbound 
connections from reaching sys-vpn and also acts as a final gatekeeper 
against unwanted outbound leaks. Having only one whitelist rule for the VPN 
set in sys-vpn, which itself doesn't have qubes-firewall.service started by 
default (I checked) makes it so that only the VPN connection can go past 
firewall-1 (assuming the firewall is functioning), so it's not useless.

*Tl;dr *FW-1 restricts connection to VPN only, FW-2 filters connections 
from the VPN, sys-VPN doesn't start qubes-firewall.service (at least with 
debian-10-minimal), even though it technically should. 

 

-- 
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/fbbb7d87-30d3-4176-9e3a-29f609823de9n%40googlegroups.com.

Re: [qubes-users] Re: Announcement: New community forum for Qubes OS users!

[54th Parallel]

On Saturday, 22 August 2020 at 17:37:24 UTC+8 Qubes wrote:

>
> Yes a big difference, but the two are intertwined in ways that it is 
> impossible to separate them. If you believe an operating system from 
> Google, Microsoft, Apple, or any other tech giant, provides 
> "near-absolute" security I think you have been wholly misguided. 


I think you're being uncharitable about my judgments. I don't want to get 
into an argument with you, so all I'll say is that you should probably read 
up more on ChromeOS. 

-- 
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/2fe0d61d-7934-4b25-a7c4-2a588230795fn%40googlegroups.com.

Re: [qubes-users] sys-firewall based on debian-10-minimal not recognized

[54th Parallel]

On Friday, 21 August 2020 at 16:58:48 UTC+8 54th Parallel wrote:

> I'm having the same issue with disposable firewalls built on 
> debian-10-minimal, with the minimum amount of packages, on 
> brand-spanking-new installations (plural) being unreliable firewalls. They 
> sometimes function but not all the time--and this is what's scary, because 
> there's no way of knowing without manually checking all the time. The 
> warning prompts when editing firewall rules aren't useful indicators since 
> they always appear regardless of whether filtering is happening.
>
> I ran systemctl in both and found that qubes-firewall.service is not 
> running in either, despite having manually activated them. I'm not a 
> technical person, but this seems like a pretty critical issue to me 
> (unreliable firewall with no indicator)--a warning about using minimal 
> debian as templates for firewalls should be put up somewhere highly visible.
>
> This unreliability has been bugging me for a while and I've been testing 
> and testing (to the best of my abilities) before realizing that this is 
> almost certainly not a user issue, so Sven, the OP,  probably either ran 
> into the issue again, didn't know about his deactivated firewalls, or 
> didn't report the issue. 
>

After some more probing around, I think I've found the issue, and that what 
I wrote earlier contains inaccuracies. The unreliable firewall might not be 
a debian-10-minimal issue, though the warning prompt that appears whenever 
editing firewall rules in a connected VM is. 

My setup has two firewalls--one behind sys-net and another behind a VPN VM. 
Though the two firewalls are clones of one another, the sys-net firewall 
works (responds to rules set in appVMs) and the proxyVM firewall doesn't. 
This is what caused me to think that deb-10-min firewalls in general are 
unreliable--some things are connected to the net-firewall (sometimes) and 
most are connected to the VPN-firewall. This makes it look like the 
firewalls work sometimes. 

I have two laptops running Qubes with the same setup. Of the four 
firewalls, all with qubes-firewall explicitly enabled, only one actually 
has the qubes-firewall.service show up after typing 'systemctl | grep 
firewall'. Each of these firewalls were created in fresh but updated 
installations of 4.0.3 with the absolute minimum amount of packages 
(qubes-core-agent-passwordless-root (so I can configure sudo prompt), 
qubes-core-agent-networking, apparmor*) and the typical settings, along 
with qubes-vm-hardening (vm-boot-protect enabled).

Any insight into this would be greatly appreciated since this is a massive 
headache for me.

-- 
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/4ce48a47-2bec-4d61-a855-5ef83b61d1f9n%40googlegroups.com.

Re: [qubes-users] Re: Announcement: New community forum for Qubes OS users!

[54th Parallel]

On Saturday, 22 August 2020 at 01:35:05 UTC+8 Qubes wrote:

>
> If you configure Firefox and uMatrix properly you should see less of 
> these funnies creep up. Have a look at this guide, 
>
> https://12bytes.org/articles/tech/firefox/firefoxgecko-configuration-guide-for-privacy-and-performance-buffs.
>  
>
>
> If that is too much for you there is also a 'for dummies' guide, 
>
> https://12bytes.org/articles/tech/firefox/the-firefox-privacy-guide-for-dummies.
>  
>
>
> The above guides are linked full of very useful information, tips and 
> tricks, proper configuration methodology, and plain good old advice. 
>
 
I'm using Chrome, but this might come in handy for when I use Firefox. 
Thanks
 

> I find it a bit funny that you are paranoid about some unknown adversary 
> tampering with your hardware in transit but you seem to use Google 
> products a lot. 
>

There's a difference between privacy and security. Chrome OS provides 
security (near-absolute security, some might say) but obviously little 
privacy is to be expected.
 

-- 
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/b0b1c9f1-5309-470a-8c94-a9c6e16ef60cn%40googlegroups.com.

Re: [qubes-users] Re: Announcement: New community forum for Qubes OS users!

[54th Parallel]

On Friday, 21 August 2020 at 23:35:05 UTC+8 deeplow wrote:

> It's working just fine for me (also tried it in chromium version 
> 83.0.4103.116). Does it work for you in other browsers?
>

Working fine on Firefox and Tor Browser, but not Chrome 84.0.4147 on Chrome 
OS (yes, I'm a dirty Google user). I did some tinkering and I misspoke 
earlier--uMatrix was showing everything being allowed so I said it was 
disabled. It turns out actually switching off uMatrix allows the site to 
appear, even though it should theoretically not be doing anything.

This was *not* the case earlier, hence why I was (and am) so confused.  
Someone should see if they can replicate this.

-- 
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/f8f0a9a6-1285-474e-92a3-c4c5c258331en%40googlegroups.com.

[qubes-users] Re: Announcement: New community forum for Qubes OS users!

[54th Parallel]

On Friday, 21 August 2020 at 01:21:11 UTC+8 a...@qubes-os.org wrote:

> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> Dear Qubes community, 
>
> We're pleased to announce the launch of a new forum for Qubes OS users: 
>
> https://qubes-os.discourse.group 
>

Not sure if I'm the only one, but after working for me earlier (I replied 
to a question), the discourse.group link no longer works and just displays 
a blank page on Chrome with extensions disabled. Doesn't seem like VPN 
blacklisting.

-- 
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/53343e23-9386-4899-b42f-d8748b56cde9n%40googlegroups.com.

Re: [qubes-users] KDE high dom0 CPU usage

[54th Parallel]

On Thursday, 20 August 2020 at 20:08:10 UTC+8 donoban wrote:

> Maybe your problem is Opengl not being hardware accelerated. Try 
> switching to XRender under System Settings -> Display and Monitor -> 
> Compositor -> Rendering backend 
>

KDE was already uninstalled when you posted this so I can't test it out, 
but I'll give it a try next time. 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/75bec86d-5c3a-4973-b6c3-8ad4e157350fn%40googlegroups.com.

Re: [qubes-users] sys-firewall based on debian-10-minimal not recognized

[54th Parallel]

On Tuesday, 11 February 2020 at 00:56:07 UTC+8 awokd wrote:

>
> Systemctl in sys-firewall tells me qubes-firewall.service is "loaded 
> active running", if that helps. 
>
> -- 
> - don't top post 
> Mailing list etiquette: 
> - trim quoted reply to only relevant portions 
> - when possible, copy and paste text instead of screenshots 
>

I'm having the same issue with disposable firewalls built on 
debian-10-minimal, with the minimum amount of packages, on 
brand-spanking-new installations (plural) being unreliable firewalls. They 
sometimes function but not all the time--and this is what's scary, because 
there's no way of knowing without manually checking all the time. The 
warning prompts when editing firewall rules aren't useful indicators since 
they always appear regardless of whether filtering is happening.

I ran systemctl in both and found that qubes-firewall.service is not 
running in either, despite having manually activated them. I'm not a 
technical person, but this seems like a pretty critical issue to me 
(unreliable firewall with no indicator)--a warning about using minimal 
debian as templates for firewalls should be put up somewhere highly visible.

This unreliability has been bugging me for a while and I've been testing 
and testing (to the best of my abilities) before realizing that this is 
almost certainly not a user issue, so Sven, the OP,  probably either ran 
into the issue again, didn't know about his deactivated firewalls, or 
didn't report the issue. 




-- 
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/26150d2c-8801-4dbc-a825-b097b0599278n%40googlegroups.com.

[qubes-users] Re: Announcement: New community forum for Qubes OS users!

[54th Parallel]

On Friday, 21 August 2020 at 01:21:11 UTC+8 a...@qubes-os.org wrote:

> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> Dear Qubes community, 
>
> We're pleased to announce the launch of a new forum for Qubes OS users: 
>
> https://qubes-os.discourse.group 
>
> This is an official user forum where you can ask questions, get help, 
> share tips and experiences, and more! For a long time, members of our 
> community have sought a privacy-respecting forum experience with modern 
> features that traditional mailing lists do not support. The open-source 
> Discourse [1] platform fills this need for us, as it does for many other 
> open-source projects. Thanks to their generous free hosting for open 
> source projects [2], we're pleased to be able to create this space for 
> our community. 
>
>
> Why create a forum now? 
> === 
>
> Previously, the only option for a forum-like experience was to interact 
> with our mailing lists via Google Groups, but we understand all too well 
> that the privacy implications and user experience were unacceptable for 
> many members of our community, especially with the recent addition of a 
> sign-in requirement to view threads. Many of you value the lower barrier 
> to entry, organization, ease-of-use, and modern social features that 
> today's forums support. Moreover, Discourse features email integration 
> for those who still prefer the traditional mailing list format. 
>
>
> How is this different from our mailing lists? 
> = 
>
> To be clear, this is *not* a replacement for our mailing lists [3] (such 
> as qubes-users and qubes-devel), which will continue on as they are. 
> This new forum is simply an *additional* place for discussion. Certain 
> types of discussions naturally lend themselves more to mailing lists or 
> to forums, and different types of users prefer different venues. We've 
> heard from some users who find the mailing lists to be a bit 
> intimidating or who may feel that their message isn't important enough 
> to merit creating a new email that lands in thousands of inboxes. Others 
> want more selective control over topic notifications. Some users simply 
> appreciate the ability to add a "reaction" to a message instead of 
> having to add an entirely new reply. Whatever your reasons, it's up to 
> you to decide where and how you want to join the conversation. 
>
>
> Will this split the community? 
> == 
>
> Many open-source projects (such as Fedora and Debian) have both mailing 
> lists and forums (and additional discussion venues). In fact, Qubes 
> already has non-mailing-list discussion venues such as IRC [4] and 
> Reddit [5]. We believe that this additional venue will foster the 
> continued growth of community participation and improve everyone's 
> experience. In addition, we fully expect that many community members -- 
> especially the most active ones -- will choose to participate in both 
> venues. (Again, for those who still prefer interacting via email, 
> Discourse supports that too!) 
>
> - - 
>
> Special thanks to Michael Carbone for spearheading the creation of this 
> forum and to deeplow who, as our first forum administrator, has done 
> much of the legwork to help get it looking good and working well! 
>
>
> [1] https://www.discourse.org/ 
> [2] https://blog.discourse.org/2018/11/free-hosting-for-open-source-v2/ 
> [3] https://www.qubes-os.org/support/ 
> [4] https://www.qubes-os.org/support/#unofficial-chat-channels 
> [5] https://www.reddit.com/r/Qubes/ 
>
> This announcement is also available on the Qubes website: 
>
> https://www.qubes-os.org/news/2020/08/20/new-community-forum-for-qubes-os-users/
>  
>
> - -- 
> Andrew David Wong (Axon) 
> Community Manager, Qubes OS 
> https://www.qubes-os.org 
>
> -BEGIN PGP SIGNATURE- 
>
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl8+sPQACgkQ203TvDlQ 
> MDDYTxAApehnwrpqFCoadx3Cmcu2llDOYbV5CuCjQFj7aMwGg2Gq3TWuugiXFjQ1 
> z6uW+asPIEvCu4XxP5K9FfVYiSF1bqLTEGomib0npapNMM1ZbULUoSU2EoACz8OS 
> BpYxgrcX1YyN8/3qQ2N2a3yRe+c0XBD72CJQ2sPu/U+xaTRKZgW6saI5Y/jpwxb7 
> WKQR0Mc9Y2vP6GRNb5ICcCNelS9fUiBJPaGQBJX7XRyAcW1y0hvF6dBZpdG70TDF 
> DN0ddhSbYQnv0aHjNnU5ajU81PZWpr5ZqK8ObZwlU/Br8ZznNlApf2ATk73x/5up 
> eMhwGqDMebJPKaIUPUEKb1FWdObKtW9TvRxhb+yybDkI4Gtfj0fIO5SfJrJ5Ud94 
> Vyt4TJfqyI4RmCpKfv3QXM3DnjKbjD0yAThVVnphqD9s+NIVSVi7K0LWGxLcX6TS 
> vCTouzWkPCrNxMylCf8M4v3V4uUJ9b8AQA3iF/v+a2tKzPveK4+mOF590918YGYE 
> CxwlrOKzb0Ecpl/LzdcrX+jq4j+Zj+B0evLc3ZbaTp+Bfr6gihOnocL/1YjHwGPU 
> 6PSJ4lYHzZzZotPaaJ1tmZtSGIkK2d7mmJBPDCSG2gSMS0QL474ObfKjAvolQ9ph 
> ZKMhEME8YbHje+X/nyxTcgO4GAoLyuPeYuDIkjmXzD0hGYFnKYA= 
> =ngAL 
> -END PGP SIGNATURE- 
>

Thanks for acting so quickly. I'll be on Discourse as 'fiftyfourthparallel'

-- 
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 

Re: [qubes-users] KDE high dom0 CPU usage

[54th Parallel]

On Thursday, 20 August 2020 at 13:25:49 UTC+8 Chris Laprise wrote:

> On 8/20/20 12:29 AM, 54th Parallel wrote: 
>
> I switch off any nvidia gpus before installation. The company is 
> anti-open source and I'm not interested in running drivers that are the 
> result of a cat-and-mouse obfuscation game. 
>
> -- 
> Chris Laprise, tas...@posteo.net 
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 
>

I tried to find ways to disable my Nvidia GPU before my first installation 
since the i7-1065G7 has a more powerful integrated one but didn't find 
anything. The BIOS doesn't have anything either. I didn't install any 
drivers but my display works fine, so am I free of Nvidia drivers?

Oh, and quick question about Qubes VM hardening: I have it installed and 
working fine on all of my VMs except one, where every time that VM boots 
up, it automatically starts an xterm window headlined with '** 
VM-BOOT-PROTECT SERVICE SHELL' . This happens on a debian-10-minimal 
sys-dispVM when VM-boot-protect (not root) is enabled and disabled. DispVM 
Template displays the same behavior with an added error line 'cat: 
/var/run/vm-boot-protect-error: No such file or directory'.  The DVM 
template has VM-boot-protect-root enabled.

Problem persists after reinstallation of hardening in template. It doesn't 
seem like a major error, but it's bugging me. I'd be grateful for any 
pointers

-- 
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/fe1b1cc7-37f0-4950-a49b-8d49bc0bd56an%40googlegroups.com.

Re: [qubes-users] KDE high dom0 CPU usage

[54th Parallel]

On Thursday, 20 August 2020 at 06:58:35 UTC+8 Chris Laprise wrote:

> Not an issue with dom0 KDE here. But I did have this problem with 
> k/ubuntu on my new AMD Ryzen Thinkpad... graphics driver was not working 
> and defaulted to a non-accelerated framebuffer mode. In this case I had 
> to upgrade the kernel to resolve it. 
>
> Check output of 'sudo lspci -nnk' and look for the section with 'VGA'. 
> If it says 'unclaimed' then your graphics driver isn't working. The 
> 'lshw' command can also be used for a different view; it will show the 
> VGA section with a line 'configuration: driver=' if 
> its working or the 'driver' part will be absent if its not working. 
>
> -- 
> Chris Laprise, tas...@posteo.net 
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 
>

lspci -nnk showed VGA working fine, but the output gave me other ideas 
(lshw not available on dom0). I modified xen.cfg so that 
i915.alpha_support=1 became i915.preliminary_hw_support=1 but that made 
things worse. I then switched to a newer kernel (5.6)  and saw a minor 
framerate improvement, but the high CPU usage remained. I removed 
iommu=no-igfx and saw a better framerate, but again, high CPU usage 
remained. 

I looked around and found that KDE and NVidia don't mix--at least for the 
older versions of KDE 
(https://www.phoronix.com/scan.php?page=news_item=NVIDIA-KDE-High-CPU-Fix). 
The KDE Plasma version of dom0 current is 5.10, but the NVidia GPU in my 
laptop (which is weaker than my iGPU's) needs 5.16. But the thing is--I 
don't remember installing an NVidia propietary driver at all. Anyways, I 
installed the recommended fix ('export __GL_MaxFramesAllowed=1' in an 
executable script in /etc/profile.d) but that didn't work as well, so I 
gave up and uninstalled KDE. 




-- 
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/9e674a51-43d4-4a5d-9e3d-e2024a784c9dn%40googlegroups.com.

[qubes-users] KDE high dom0 CPU usage

[54th Parallel]

Quick question:

I decided to try out KDE on 4.0 and was liking it until I noticed the low 
overall framerate and the high CPU usage of dom0 shown in xentop whenever 
there's motion (like dragging windows around). Since I'm using an 
i7-1065G7, power shouldn't be an issue, so I was surprised. 

Is there any way I can fix this? Has anyone here experienced this?

-- 
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/a43f10a9-7704-476f-8483-576fd9c1a80fn%40googlegroups.com.

Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?

[54th Parallel]

On Wednesday, 19 August 2020 at 00:15:08 UTC+8 Robert Spigler wrote:

> This is the real solution for the Intel problem :)
>
> https://github.com/QubesOS/qubes-issues/issues/4318
>
> I believe IBM stated they also have protections against the Rowhammer 
> attacks
>

 I'm all for having Qubes on ppc64 but I think the problem is how rare the 
hardware seems to be. With ARM, at least they're common; ppc laptops aren't 
even a thing. 

My view is that you can get ppc-PCs from places like Raptor Computing, but 
A) they almost always have to be shipped (opening it up to targeted 
interdiction) and B) there are so few places with them available that the 
risk of vendor/retailer compromise is massive. This doesn't seem likely to 
change anytime soon (or ever).

But I'm probably missing something, since someone who is almost certainly 
more knowledgeable than I am (I'm not technical) found it worth paying a 
2btc bounty for

-- 
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/c219bb0d-389d-4468-9f97-02c595230692n%40googlegroups.com.

Re: [EXT] Re: [qubes-users] Google requiring login to access qubes-users

[54th Parallel]

Andrew wrote:
>We're actually working on an announcement about this right now. Stay
tuned!

I see you're very much on top of things. Looking forward to it!

On Tuesday, 18 August 2020 at 21:14:07 UTC+8 awokd wrote:

>
> I imagine China's policy requiring real ID to use the Internet has 
> Google salivating all over itself. 
>
> -- 
> - don't top post 
> Mailing list etiquette: 
> - trim quoted reply to only relevant portions 
> - when possible, copy and paste text instead of screenshots 
>

If only Google actually had access to that market. For that reason, I'm far 
more wary of Apple, since they seem eager to not offend the authorities so 
their lucrative market access there isn't jepoardized. 

Case in point: virtually all the major tech firms have suspended the 
processing of requests by the Hong Kong government, Google being the 
latest--even Microsoft. Apple is now the two trillion ton elephant in the 
room (question: would a two trillion ton object the size of an elephant 
collapse into a black hole?). Who knows what backdoor deals (pun completely 
intended) it has with the Chinese government?

But then maybe Google has other channels to purchase and make use of 
real-ID linked data from China. That, and Apple doesn't have a sprawling 
web presence.

/rant



-- 
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/47a0c4c3-658b-40e2-97ca-079a8e377304n%40googlegroups.com.

Re: [qubes-users] Unable to create set templates as disposable vm templates

[54th Parallel]

On Monday, 17 August 2020 at 05:11:16 UTC+8 Ari wrote:

> find templates that fit best with your vm and that u know well, dont look 
> for templates on the black market and have low ratings
>

Am I missing something, or is there a sketchy unofficial source for 
templates with ratings somewhere?


-- 
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/ff04de33-4827-4b09-afd5-d37e34bd61aan%40googlegroups.com.

Re: [EXT] Re: [qubes-users] Google requiring login to access qubes-users

[54th Parallel]

On Monday, 17 August 2020 at 08:38:20 UTC+8 Chris Laprise wrote:

> The mail-archive site doesn't come up prominently in searches and I even 
> forgot it existed, but thanks for the reminder. 
>
> The list remains in peoples' minds as being a "Google group" so they are 
> likely to gravitate toward Google to read its contents. So what we have 
> is a pressure tactic from Google to trace more user activity across the 
> web – user logs into Google to read some list messages, and Google links 
> their recent and future browsing history to the users' identity. 
>
> This doesn't affect list subscribers much, as we can read messages in 
> our email clients. But Google knows the many 'casual' list users who are 
> not subscribed are not 'casual' users of the entire web, and they are 
> likely to sign in just to get at a handful of messages that could solve 
> their problem. 
>
> -- 
> Chris Laprise, tas...@posteo.net 
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 
>

As someone who has had an open tab on the Google Groups page for a long 
time, I want to add that activity has dropped *dramatically* since Google 
started mandating logins. Like, it has fallen off a cliff and now the place 
has a ghost town vibe to it. 

With the changes in Google Group's interface, I'm tempted to abandon this 
place entirely and shift to mail, but for the sake of having more 
participants, it'd be nice to have the forum/mailing list somewhere less 
restrictive.

-- 
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/4418f031-e05f-42c9-b8dc-f7e4e2857d17n%40googlegroups.com.

Re: [qubes-users] Qubes dom0-update-guard script

[54th Parallel]

While working on the script, I realized that a much simpler way of 
achieving the goal of verifying that repomd hasn't been tampered with is to 
just verify that the repomd.xml used for updating matches the onion version 
(itself cross-checked against multiple HTTPS copies) before the update, 
instead of comparing a list of installed packages against a parsed list of 
available packages. This means I won't have to write something to parse 
that list and makes the script much more compact. 

Unfortunately, this seems to mean tinkering with qubes-dom0-update itself 
and mandating the use of sys-whonix as the dom0 update VM instead of 
writing a separate script to be run after the fact.

On Friday, 14 August 2020 at 22:38:33 UTC+8 54th Parallel wrote:

> On Friday, 14 August 2020 at 19:24:11 UTC+8 disrupt_the_flow wrote:
>
>> I am so confused. Please explain what you want to do, but no like in a 
>> pseudo-script method.
>>
>
> The thread above contains all the pertinent information--if you're using 
> Google Groups, try 'expanding all' and reading through 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/4d86b885-d756-480b-b43f-b3e95ca9547dn%40googlegroups.com.

Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?

[54th Parallel]

On Sunday, 16 August 2020 at 01:14:08 UTC+8 Chris Laprise wrote:

> I'm not going to get into details now, but the short story is Intel 
> haven't addressed all the sidechannel vulnerabilities, and the long and 
> varied trend of Intel vulns points to a fundamentally flawed 
> implementation... too many cheap shortcuts were taken. 
>
> Even worse is that Intel are now retiring their patch process for some 
> CPUs that are still popular with Qubes users, for example Ivy Bridge (I 
> expect Haswell to not be far behind if it hasn't already been ghosted). 
> To do this with a CPU that is 7 years old (when they announced it) is 
> very disappointing. 
>
> IIRC for a relatively recent generation (I think it was Skylake!) they 
> said the expected mitigation was for You + Me to replace their junk with 
> newer hardware. No refund, no exchange program... just "We're the Big 
> Gorilla and you give us more of your money now". 


There's a lot of schadenfreude out there as Intel flounders with its 
delayed transistor nodes, frequent security failings, the very public 
dumping by Apple, and personnel issues. I think it's a good thing, since 
the company has basically become the Boeing of the processor industry (even 
before Boeing, since Spectre and Meltdown pre-dated the 737-MAX)--they're 
both venerable industry pioneers that have been consumed by corruption 
borne from complacency and needed good kicks in the pants. Whether the 
kicks will actually lead to substantial change remains to be seen, since 
they're too big to fail. 

AMD may be winning the PR race, but Intel is still very much virtually the 
sole supplier of laptop CPUs where I live--you'd have to actively dig 
around to find AMD laptops, and those you find are usually old and/or 
underpowered.

I'd love an ARM Qubes. My dream PC would be a top-end ARM Macbook Pro with 
Qubes running on it (since this is a fantasy, it'd have all the MBP's 
security features, like the T2 chip, functioning).
 

> Yes, rowhammer and its offshoots. Unfortunately, the changes in DDR4 
> that were supposed to increase resistance were eventually discovered to 
> be cheap shortcuts themselves and have actually made the situation worse. 
>

Ever get the feeling that the goal of truly secure computing is a sisyphean 
task? There's probably a mathematical formula out there proving that things 
above a certain degree of complexity cannot be guaranteed to be absolutely 
secure. 

-- 
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/61a11cb0-3148-4bbd-8810-316103b53d8cn%40googlegroups.com.

Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?

[54th Parallel]

On Saturday, 15 August 2020 at 14:39:32 UTC+8 a...@qubes-os.org wrote:

>
> Then don't use it! :) 
>
 
With the new look that makes it so much harder to use (top posting is 
default now) and replying to multiple people in a single post is a pain, so 
I just might give Thunderbird or Mutt a try. I'd say I'm de-Googling,  but 
I'm typing this from ChromeOS, so there's that.



-- 
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/a345e2a7-ff09-4692-ab76-dd35352d47e9n%40googlegroups.com.

Re: [qubes-users] Qubes dom0-update-guard script

[54th Parallel]

On Friday, 14 August 2020 at 19:24:11 UTC+8 disrupt_the_flow wrote:

> I am so confused. Please explain what you want to do, but no like in a 
> pseudo-script method.
>

The thread above contains all the pertinent information--if you're using 
Google Groups, try 'expanding all' and reading through 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/fcd6bd80-5962-4502-8ce6-4bd9eb8536fen%40googlegroups.com.

Re: [qubes-users] Qubes dom0-update-guard script

[54th Parallel]

How does this look?

*Outline of qubes-dom0-update-guard*

*Usage: Use in conjunction with manual dom0 update*
*sudo qubes-dom0-update -y && qubes-dom0-update-guard*


Prompt 1: "Please enter the name of a clean VM with access to Tor (e.g. 
anon-whonix): "
Check if entered name is a VM
If false, alert and prompt again
If true, proceed
Check if VM has Tor access
If Tor inaccessible, alert and prompt again
If Tor accessible, enter input into variable 'VM1' and proceed

Prompt 2: "Please enter the name of a clean, Debian-based disposable VM 
template with no assigned NetVM: "
Check if enter name is a VM
If false, alert and prompt again
If true, proceed
Check if VM is a disposable VM template (via qvm-prefs)
If false, alert and prompt again
If true, proceed
Check if VM is based on Debian (via qvm-prefs)
If false, alert and prompt again
If true, proceed
Check if VM has no NetVM assigned (via qvm-prefs)
If false, alert and prompt again
If true, enter input into variable 'VM1' and proceed

Start VM1
Retreive repodata from Onion and HTTPS mirrors
Alert if less than 3 mirrors accessible
Maybe halt process or give choice to continue?
Maybe instead alert if low proportion (predefined) of mirrors 
available
Since that might indicate trouble
Move repodata files to VM2 (starts VM2)

In VM2
Cross-check Onion and HTTPS repodata
If any are different, alert, list differences, 
If all match, proceed

Write output of dom0 'rpm -qa' or 'yum list installed' to a file, 
overwriting old version
Copy into VM2 (same folder as repodata)

In VM2, parse and re-write cross-checked Onion repodata into same format as 
'rpm -qa' or 'yum list installed' output
Include newest version of each package only
Cross-check output against dom0 output using same method for repodata
If one or more differences, alert (loudly) and list differences, 
then 
If both match, notify and 


I think the part that will pose the biggest challenge to my almost 
non-existence programming skills is the last part, where I have to write a 
program that will parse and repackage Onion repodata into a list of most 
recent packages. The rest seems workable, especially since I'm using Chris' 
qubes4-multi-update as reference for the script, which will be in Python.
On Monday, 10 August 2020 at 21:13:46 UTC+8 fiftyfour...@gmail.com wrote:

> On Monday, 10 August 2020 18:39:53 UTC+8, Andrew David Wong wrote:
>>
>> The QSB formats are actually pretty standardized already, though our 
>> expectation has been that they'd be read by humans rather than 
>> programmatically. We use a template [1] for the overall structure, and 
>> in particular, the "Patching" section always follows this format: 
>>
>
> Chris, Andrew,
>
> I'm grateful for your pointers. As a newcomer to programming, I don't 
> think I'm ready to integrate bulletin parsing and PGP verification into my 
> script. As of right now I'm trying to figure out whether I should use bash, 
> sh, or Python to write the script and using Chris' qubes-scripts and 
> qubes-vm-hardening as reference on how I should proceed. Maybe I'll get 
> around to integrating PGP verification into the process, but for now I want 
> to focus on the basics.
>
> Besides, don't the bulletins cover only a tiny (though critical) portion 
> of the updates dom0 receives? The PGP verification will provide a strong 
> additional layer of assurances, but I think cross-checking 'rpm -qa' 
> against the onion repodata, which itself has been cross-checked with at 
> least three other HTTPS repodata, should suffice for now, given my 
> abilities.
>
> Oh, and if someone more proficient at programming than I am (probably > 
> 90% of the people here) would like to write the script, then by all 
> means--I'll take my time and will likely come up with something substandard 
> and in need of multiple major revisions. I can still practice even though 
> someone else has written it, so please don't think of this little project 
> as 'mine' or anything--I'd hate to get in the way of others improving 
> Qubes' 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/2b0d3b92-7c9b-4595-860f-18bf4561f57dn%40googlegroups.com.

Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?

[54th Parallel]

> Since the lions' share of Qubes installs are Intel based, I think a
> side-channel attack would be the most likely way to breach a Qubes
> system. 

I thought Spectre and Meltdown have been dealt with by shutting off 
hyperthreading and updating microcode? Also, the latest CPUs have Spectre 
mitigation built-in, though this only deals with the earlier variants of 
the attacks if I remember correctly.


> DDR4 memory offers a big attack surface as well

Does this refer to the RowHammer (HammerRow?) attack?


> OTOH, a state actor wishing to attack a Qubes system might have better
luck with the RPM MITM against Fedora that we discussed in another thread.

Pretty much my biggest concern right now, though I'm procrastinating on 
writing the damn script


Relevant to the thread:
https://arstechnica.com/information-technology/2020/08/nsa-and-fbi-warn-that-new-linux-malware-threatens-national-security/


P.S. I'm not liking this new Google Groups look
On Friday, 14 August 2020 at 00:06:42 UTC+8 Chris Laprise wrote:

> On 8/13/20 10:59 AM, fiftyfour...@gmail.com wrote:
> > If you were tasked with remotely hacking into a default but updated 
> > Qubes OS system (installation configuration of 4.0.3, but with updated 
> > templates and dom0), how would you do it? What would you attack?  The 
> > precise objective (e.g. retrieve a PGP key from a vault, read a text 
> > document, achieve persistence, modify the system) is open--I just want 
> > to see how people might generally approach this question so I might 
> > better plug potential holes.
> > 
> > Sorry for the extremely broad question--please think of this as 
> > something like a 'red team' exercise.
>
> Since the lions' share of Qubes installs are Intel based, I think a 
> side-channel attack would be the most likely way to breach a Qubes 
> system. But also its not just Intel CPUs that are weak here; DDR4 memory 
> offers a big attack surface as well. Such attacks can be carried out 
> with javascript from websites.
>
> OTOH, a state actor wishing to attack a Qubes system might have better 
> luck with the RPM MITM against Fedora that we discussed in another thread.
>
> -- 
> 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/495b0cac-fbee-4a45-93a6-2e56c4ef44a4n%40googlegroups.com.