Re: [qubes-users] Should the footer at the bottom of the mailing list be deleted?

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 10, 2022 at 01:10:36PM -0600, Eric W. Biederman wrote:
> Demi Marie Obenour  writes:
> 
> > The footer on each message is rather annoying, mostly because it breaks
> > digital signatures.  Should it be set to the empty string, or do its
> > benefits outweigh the drawbacks?
> 
> Doesn't it also break DMARC?  I remember that was a big fight 5 or so
> years ago to get all of the mailing list software to do something that
> was compatible with DMARC because all messages that came through
> mailling lists from a source that enabled DMARC to a MTA that enforced
> DMARC were bouncing.

I suspect Google Groups deals with the problem by mangling the `From:`
header where necessary.  That reminds me: Marek, should Qubes OS have
p=reject?

- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmIqg3gACgkQsoi1X/+c
IsFswRAA3X9KucHeAu7p+6TspfWScVrfyCRQ6lgcBiYG7PAoqk1My8LtogGJR2O2
BSYJPVPZCiI8/rN2XPwyeN9iihbaCUgN9IQoaSQXBQJO9z1obr7q4VErBQOEyK86
VqAKHk2VrMbJ2GTJ6mA31xAmQruPGzaYAxfMZmgA4bvs8spm36U6ANbSpxqjvz6R
QDnqQ1+nN35qcwYLyvCi4J9LojcPW26mrc12BAdqlgpZq9qfs7PzflR+EJBaH20E
gVU81VFmR7T5dnVAdVYoBgAA468T+JKqg1fGXRZr72dry5WOUxAsByGXtlkOYoPy
BAJA81N1Uto4qUGIaCcpyYXp8eK+vGhKUXYkJbE0y3NSKWzGPNFUQAce+0lBu/TQ
0riuasJtFUD/EaCpVo6vByJlIoSmjbMSQbn/z08CeUYQMOK76sFV9Ox9VmNJOozg
qy8yiPDRFSKacTQnkjsg21qg6aAC2reei3dJt3tx4cN6f63uu8x8qYoSYBxmXOQ8
tf2jJe+O1QN1JhG47HOucbjfoal96ZDxdxyY2zsSDXnLkYug5XJGW86Iw/p/aFJx
+jttydCAaaF/d3Cw7Ip8a7+m0hTC0dtdChoRXdCLKWuKB2xNgWHr6ztxOcMBzg/Z
wK6OC/FVGHRS4cAOFaIEuUhawtO+O4zFeKKv6pKvnx/cZSmYgf0=
=tOeR
-END PGP SIGNATURE-

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

Re: How to use "inline PGP"? (was: Re: [qubes-users] Should the footer at the bottom of the mailing list be deleted?)

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Mar 10, 2022 at 12:35:24PM +0100, Peter Funk wrote:
> Hello, 
> 
> Demi Marie Obenour wrote Wednesday, 09.03.2022 16:33:
> > On Wed, Mar 09, 2022 at 04:25:11PM -0500, Demi Marie Obenour wrote:
> > > The footer on each message is rather annoying, mostly because it breaks
> > > digital signatures.  Should it be set to the empty string, or do its
> > > benefits outweigh the drawbacks?
> > 
> > Looks like Google mangles the message in other ways, too.  In my case,
> > the charset is changed from us-ascii to UTF-8, and the
> > Content-Transfer-Encoding header is removed, with the `=20` at the end
> > of one line being replaced by a space.  So the only solutions are either
> > inline PGP or to switch list hosting solutions.
> 
> Where can I learn, how to use inline PGP (GPG) properly in my messages?
> I use 'mutt' as my preferred MUA.

Use ‘p’ to select the PGP menu, then select “inline format” and “sign”.



- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmIqguQACgkQsoi1X/+c
IsE4mBAAzByF24lzF5vheGsxTG65DB4XykyJgrdFRjEmO7SzfwxMDGTpiMqxq/Ly
l+oYzBDB4thUx/qv23i+67hx14WiVDHU8VQFfSh0Q1DiWEHv3WOzX7zz1GF3QE3p
Zv8ZATYaWIBlO8PonbnH3w2ZNjBUFOxsbEBBoCq6mYD7QCractKfxcpCf8XZKaFX
v+rJgVNDA8yBPpWIrZzstSY2blm9nB2EA2Ly6eiB8g0L4ID+13GXwx9HEAnTTL7G
quh9A1MnEmnJrpJBBUhrfIW7GM6qzMQtfksxRbIo3+oZUlnOfkDgsVA6JzxjZuW7
kQWHt0ZIJ77xyqPgGODUZF1IsTbOSC5kYyAkb/3l/whTDLtD/2F8nPZ8kgC0EY3z
0YG1nTQYbzOpKxcYZIQM6dZJPTbFKvLzq97HZabHhLDhvY+KF+v1AUxcSacWM3hm
jkx/VOrrJU8x6TwxomxaXY2bEueq7RB6a1XHkQfE/v/0jFqxNLt+qvisTrV2DbU2
vSFDv/6mePJV+/MKYlMjwfQfNMNRtjEMJnWlI0dGqtSJ+ZGCXZc3IF63v+6S7txA
b9ywfj/2m4tz66Y6VLqntv5SmQ+71BwIp4P3jFw30Gg5dPxhcEncp8LrMFebEI1W
L+C57TW+QpF2vaab25KMw22uFdYSzVQBryfcpNoTvIpZwqW/+cU=
=gZeP
-END PGP SIGNATURE-

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

[qubes-users] QSB-078: Linux kernel PV driver issues and LVM misconfiguration

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 078: Linux kernel
PV driver issues and LVM misconfiguration. The text of this QSB is
reproduced below. This QSB and its accompanying signatures will always
be available in the Qubes Security Pack (qubes-secpack).

View QSB-078 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 078 ]===---

  2022-03-10

   Linux kernel PV driver issues and LVM misconfiguration


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Kernel packages, versions 5.4.183-2, 5.16.13-2, 4.19.233-2
  - LVM2 packages, version 2.02.167-4

  For Qubes 4.1, in dom0:
  - Kernel packages, versions 5.10.104-2, 5.16.13-2
  - LVM2 packages, version 2.03.09-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

A system restart is required in order for the updates to take effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Dom0 kernel binaries.

By default, qube kernels are provided by dom0. However, advanced users
may instead opt to install a different kernel inside of a qube, e.g.,
from an upstream distribution like Fedora or Debian. [3] Such users
should consult that distribution's update channels for any kernel
updates that might be relevant to this bulletin.

In addition, advanced users with customized setups are advised that the
LVM patch changes the LVM's default value for "global_filter" [5]. This
means you must ensure that the device that contains the LVM with Qubes'
rootfs is allowed, or else your system will not boot.


Summary


On 2022-03-10, the Xen project published XSA-396, "Linux PV device
frontends vulnerable to attacks by backends" [4]:

| Several Linux PV device frontends are using the grant table interfaces
| for removing access rights of the backends in ways being subject to
| race conditions, resulting in potential data leaks, data corruption
| by malicious backends, and denial of service triggered by malicious
| backends:
|
| blkfront, netfront, scsifront and the gntalloc driver are testing
| whether a grant reference is still in use. If this is not the case,
| they assume that a following removal of the granted access will always
| succeed, which is not true in case the backend has mapped the granted
| page between those two operations. As a result the backend can keep
| access to the memory page of the guest no matter how the page will be
| used after the frontend I/O has finished. The xenbus driver has a
| similar problem, as it doesn't check the success of removing the
| granted access of a shared ring buffer.
| blkfront: CVE-2022-23036
| netfront: CVE-2022-23037
| scsifront: CVE-2022-23038
| gntalloc: CVE-2022-23039
| xenbus: CVE-2022-23040
|
| blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront,
| and pvcalls are using a functionality to delay freeing a grant
| reference until it is no longer in use, but the freeing of the related
| data page is not synchronized with dropping the granted access. As a
| result the backend can keep access to the memory page even after it
| has been freed and then re-used for a different purpose.
| CVE-2022-23041
|
|
| netfront will fail a BUG_ON() assertion if it fails to revoke access
| in the rx path. This will result in a Denial of Service (DoS)
| situation of the guest which can be triggered by the backend.
| CVE-2022-23042

As a separate matter, there is a misconfiguration in the Linux Volume
Manager (LVM) in dom0 that affects certain custom storage configurations
(see below). In affected systems, the LVM fails to ignore devices that
are controlled by other qubes. This exposes the LVM metadata parser in
dom0 to untrusted data, which could, hypothetically, be exploited in
combination with an another vulnerability and which may result in the
LVM becoming "confused" about which devices it should use.


Impact
---

Regarding XSA-396, due to race conditions and missing tests of return
codes in the Linux PV device frontend drivers, a malicious backend could
gain access (both read and write) to memory pages to which it should not
have such access, or it could directly trigger a denial of service (DoS)
in the qube in which it is running. A backend gaining full control over
its frontend 

[qubes-users] XSAs released on 2022-03-10

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is affected*.
Therefore, *user action is required*.


XSAs that affect the security of Qubes OS (user action required)


The following XSAs *do affect* the security of Qubes OS:

- XSA-396

Please see *QSB-078* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:




XSAs that do not affect the security of Qubes OS (no user action required)
--

The following XSAs *do not affect* the security of Qubes OS, and no user 
action is necessary:


- (None)


Related links
-

- Xen XSA list: 
- Qubes XSA tracker: 
- Qubes security pack (qubes-secpack): 


- Qubes security bulletins (QSBs): 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/03/10/xsas-released-on-2022-03-10/

--
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/700c87a4-6cba-60b9-7431-9cf9b39221be%40qubes-os.org.

Re: [EXT] [qubes-users] 4.1.0 installation failure

[Ulrich Windl]

On 2/25/22 01:01, Ulrich Windl wrote:

Hi!


So after my failed USB stick, my power supply had failed, too 8-(
When having got a new stick and a new power supply, I tried to install Qubes OS 
4.1.0 on an external disk that had some old Qubes OS 4.0 on it.
I chose a custom setup, creating partitions LUKS, PC, VG, and LVs as 
instructed. The assigning the partitions and LVs.

Installation went smoothly (mostly because of a real fast USB stick), I was 
asked to reboot.


Unfortunately (I think it's an old bug) boot failed as dracut wanted to open a 
LUKS ID that wasn't found.
My guess was that the installer had cached the old LUKS ID that was on the disk 
before I recreated the structure.
On the next attempt, I edited the GRUB command line to have the correct LUKS 
UUID. THings looked better, but after unlocking the LUKS successfully, nothing 
else seemed to happen. So I aborted it.


Examining the journal of the failed boots, I found this:
Feb 24 23:52:19 dom0 lvm[1326]:   Device open /dev/sdd1 8:49 failed errno 2
Feb 24 23:52:20 dom0 kernel:  md124: p1
Feb 24 23:52:20 dom0 lvm[1326]:   WARNING: Scan ignoring device 8:1 with no 
paths.
Feb 24 23:52:20 dom0 lvm[1326]:   WARNING: Scan ignoring device 8:17 with no 
paths.
Feb 24 23:52:20 dom0 lvm[1326]:   WARNING: Scan ignoring device 8:33 with no 
paths.
Feb 24 23:52:20 dom0 lvm[1326]:   WARNING: Scan ignoring device 8:49 with no 
paths.
Feb 24 23:52:20 dom0 dmeventd[3705]: dmeventd ready for processing.
Feb 24 23:52:20 dom0 kernel: lvm[1326]: segfault at 801 ip 777003fcfdde sp 
7ffd4db1c028 error 4 in libc-2.31.so[777003e91000+15]
Feb 24 23:52:20 dom0 kernel: Code: fd d7 c9 0f bc d1 c5 fe 7f 27 c5 fe 7f 6f 20 c5 fe 7f 
77 40 c5 fe 7f 7f 60 49 83 c0 1f 49 29 d0 48 8d 7c 17 61 e9 c2 04 00 00  fe 6f 
1e c5 fe 6f 56 20 c5 fd 74 cb c5 fd d7 d1 49 83 f8 21>
Feb 24 23:52:20 dom0 kernel: audit: type=1701 audit(1645743140.034:101): auid=4294967295 uid=0 
gid=0 ses=4294967295 pid=1326 comm="lvm" exe="/usr/sbin/lvm" sig=11 res=1
Feb 24 23:52:20 dom0 audit[1326]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1326 
comm="lvm" exe="/usr/sbin/lvm" sig=11 res=1
Feb 24 23:52:20 dom0 lvm[3705]: Monitoring thin pool qubes_dom0-pool00-tpool.
Feb 24 23:52:20 dom0 lvm[2561]:   3 logical volume(s) in volume group 
"qubes_dom0" now active
Feb 24 23:52:20 dom0 systemd[1]: Finished LVM event activation on device 253:0.



That segfault doesn't look good!


The last things that seem to happen on boot are:
Feb 24 23:52:22 dom0 systemd[1]: Finished udev Wait for Complete Device 
Initialization.
Feb 24 23:52:22 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 
msg='unit=systemd-udev-settle comm="systemd" exe="/usr/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Feb 24 23:52:22 dom0 kernel: audit: type=1130 audit(1645743142.001:103): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=systemd-udev-settle comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=>
Feb 24 23:52:22 dom0 systemd[1]: Starting Activation of DM RAID sets...
Feb 24 23:52:22 dom0 systemd[1]: dmraid-activation.service: Succeeded.
Feb 24 23:52:22 dom0 systemd[1]: Finished Activation of DM RAID sets.
Feb 24 23:52:22 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 
msg='unit=dmraid-activation comm="systemd" exe="/usr/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Feb 24 23:52:22 dom0 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 
msg='unit=dmraid-activation comm="systemd" exe="/usr/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Feb 24 23:52:22 dom0 kernel: audit: type=1130 audit(1645743142.797:104): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=dmraid-activation comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=su>
Feb 24 23:52:22 dom0 kernel: audit: type=1131 audit(1645743142.797:105): pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=dmraid-activation comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=su>



(Those MD-RAIDS are my built-in disks (two RAID1))
Eventually I tried a reboot then:


eb 25 00:01:26 dom0 systemd[1]: Received SIGINT.
Feb 25 00:01:26 dom0 systemd[1]: Removed slice system-getty.slice.
Feb 25 00:01:26 dom0 systemd[1]: Removed slice system-modprobe.slice.
Feb 25 00:01:26 dom0 systemd[1]: Stopped target Block Device Preparation for 
/dev/mapper/luks-a10e21f9-2581-47f7-819a-ec06fde599a1.
Feb 25 00:01:26 dom0 systemd[1]: Stopped target Remote Encrypted Volumes.
Feb 25 00:01:26 dom0 systemd[1]: mdmon@md125.service: Succeeded.
...
Feb 25 00:01:26 dom0 systemd[1]: Removed slice system-lvm2\x2dpvscan.slice.
Feb 25 00:01:26 dom0 systemd[1]: tmp.mount: Succeeded.
Feb 25 00:01:26 dom0 systemd[1]: Unmounted Temporary Directory (/tmp).
Feb 25 00:01:26 dom0 systemd[1]: Stopped target Swap.
Feb 25 00:01:26 dom0 systemd[1]: Deactivating swap 

[qubes-users] Q: Access files on Android mobile?

[Ulrich Windl]

Hi!

Some time ago Android stopped presenting it's disks as block devices via 
USB (so that you cannot "mount" them any more on the PC), so now it used 
PTP or MTP to transfer files.
While that works with a typical Linux file manager, I was not able to do 
that from a VM. Is that possible _without_ assigning the USB host to the VM?


Regards,
Ulrich

--
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/9c224957-a273-5cf3-6ad3-1b8ceadfbddf%40rz.uni-regensburg.de.

[qubes-users] Re: Should the footer at the bottom of the mailing list be deleted?

[Ulrich Windl]

On 3/9/22 22:25, Demi Marie Obenour wrote:

The footer on each message is rather annoying, mostly because it breaks
digital signatures.  Should it be set to the empty string, or do its
benefits outweigh the drawbacks?


I wouldn't care that much about the footer if the content is kept 
intact, but I think some mailing list software also messes up with 
multipart MIME messages. Haven't seen that here, but on mailman lists...


Regards,
Ulrich

--
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/676a4805-2c6b-0459-5bad-a262ab928329%40rz.uni-regensburg.de.

Re: [EXT] [qubes-users] Re: Qubes 4.1 qrexec issue?

[Ulrich Windl]

On 3/9/22 12:20, 'taran1s' via qubes-users wrote:


Is this mailing list still active or one needs to better go to a 
different place?




Wouldn't reading the list answer the question? ;-)

--
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/a0b8da50-cee1-6089-b650-4c93514978ce%40rz.uni-regensburg.de.

Re: [EXT] [qubes-users] blkback errors in dmesg

[Ulrich Windl]

On 2/16/22 22:06, Demi Marie Obenour wrote:

Occasionally, when my system is under heavy load, it will freeze for a
few seconds.  During this time, the pointer is still reasonably
responsive, but nothing else is.  When the freeze ends, I get these
entries in dmesg:

 Feb 16 13:37:23 dom0 kernel: xen-blkback: Scheduled work from previous 
purge is still busy, cannot purge list
 Feb 16 13:37:23 dom0 kernel: xen-blkback: Scheduled work from previous 
purge is still busy, cannot purge list

What is the meaning of these entries?  Is it a red herring?

>

My guess is that the relation of block I/O requests to block device 
speed is bad (i.e.: to much I/O for the slow disk). If the I/O is caused 
by paging (swap), you might want more RAM or trim down your VMs to use 
less RAM.


Despite of that I think there was a recent Xen change limiting block 
queues (or something like that).


Regards,
Ulrich

--
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/bfaf1279-8fb7-0cab-a70f-bb13e3988799%40rz.uni-regensburg.de.

Re: [EXT] [qubes-users] Selescting any option from the install screen just loops back

[Ulrich Windl]

On 2/16/22 03:51, Scarecrow [USMC] wrote:
Hey. I am new to Qubes, and am first trying to install it now. For 
reference, I have this https://support.hp.com/us-en/document/c07060711 
 laptop. I 
initially posted this problem on the Qubes forums, but nothing I was 
told there worked.


I have read through the documentation, and looked at the hardware lists 
for people who tried with similar hardware. I only found this 
https://www.qubes-os.org/hcl/#hewlett-packard_15s-eq2xxx_ryzen-5-5500u_amd_integrated-graphics-radeon 
 that 
was close. I tried following the error instructions this guy had, but I 
don't think we had the same problem.


Now, the actual issue is this: I used rufus to download the Qubes iso 
onto a 32GiB SD card as per the instructions from the Qubes Installation 
documentation. I disabled secure boot in my UEFI and restarted. It 
loaded onto the correct screen, with the four options of "Install Qubes 
OS 4.1.0"; "Test Media and Install Qubes OS 4.1.0"; "Troubleshoot and 
Install Qubes OS 4.1.0"; and "Save Qubes OS 4.1.0". However, when I 
select any one of them, the same thing happens. It trys to install, 
seems to be doing okay, the screen darkens for a bit, then opens up 
right back on the installation menu. I am very confused. I haven't seen 
another issue like this reported and could really use some help. Thanks 
in advance.


Could it be as simple as your PC reboots from the SD-CARD again instead 
of the OS being installed? If not, maybe provide more details.


Regards,
Ulrich



--
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/CAPeX3-u0wTSqEjUU-V84C59nr3BuDW%3DSU%2Bvrq4ve8h1U_mGvpA%40mail.gmail.com 
.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/16676395-7658-268a-7796-6307d5337592%40rz.uni-regensburg.de.

[qubes-users] XSAs released on 2022-03-08

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is affected*.
Therefore, *user action is required*.


XSAs that affect the security of Qubes OS (user action required)


The following XSAs *do affect* the security of Qubes OS:

- XSA-398

Please see *QSB-077* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:




XSAs that do not affect the security of Qubes OS (no user action required)
--

The following XSAs *do not affect* the security of Qubes OS, and no user 
action is necessary:


- (None)


Related links
-

- Xen XSA list: 
- Qubes XSA tracker: 
- Qubes security pack (qubes-secpack): 


- Qubes security bulletins (QSBs): 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/03/10/xsas-released-on-2022-03-08/

--
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/0416a551-e9f9-0010-c267-893c52a646d6%40qubes-os.org.

[qubes-users] QSB-077: Multiple speculative security issues (XSA-398)

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 077: Multiple
speculative security issues (XSA-398). The text of this QSB is
reproduced below. This QSB and its accompanying signatures will always
be available in the Qubes Security Pack (qubes-secpack).

View QSB-077 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 077 ]===---

 2022-03-09

 Multiple speculative security issues (XSA-398)


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-38

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.4-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.

Note: As of the publication date of this QSB, the Xen Project's patches
for XSA-398 are incomplete. Specifically, they do not protect systems
running on CET-capable Intel platforms (11th generation and later). This
limitation affects Qubes 4.1 but not Qubes 4.0. In light of this
situation, we have decided to push both the complete 4.0 patches and the
incomplete 4.1 patches to the security-testing repository immediately.
The Xen Project expects to make complete patches available in the near
future. We will push the complete 4.1 patches as soon as possible after
they become available to us.

Summary


On 2022-03-08, the Xen Project published XSA-398, "Multiple
speculative security issues" [3]:

| 1) Researchers at VU Amsterdam have discovered Spectre-BHB, pertaining
|to the use of Branch History between privilege levels.
|
|ARM have assigned CVE-2022-23960.  Intel have assigned CVE-2022-0001
|(Branch History Injection) and CVE-2022-0002 (Intra-mode BTI).  AMD
|have no statement at the time of writing.
|
|For more details, see:
|  https://vusec.net/projects/bhi-spectre-bhb
| 
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
| 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00598.html

|
| 2) Researchers at Open Source Security, Inc. have discovered that AMD
|CPUs may speculate beyond direct branches.
|
|AMD have assigned CVE-2021-26341.
|
|For more details, see:
| 
https://grsecurity.net/amd_branch_mispredictor_part_2_where_no_cpu_has_gone_before
| 
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1026

|
| 3) Researchers at Intel have discovered that previous Spectre-v2
|recommendations of using lfence/jmp is incomplete.
|
|AMD have assigned CVE-2021-26401.
|
|For more details, see:
| 
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1036

|


Impact
---

The Xen Project's summary above enumerates three security issues. The
first one, in practice, affects only newer Intel systems (11th
generation and later). For other systems, previous mitigations
are already sufficient. The second issue does not, in practice, affect
any configuration supported by Qubes OS. The third issue affects only
AMD systems.
On affected systems, an attacker might be able to infer the contents
of arbitrary host memory, including memory assigned to other guests.

Credits


See the original Xen Security Advisory.


References
---

[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-398.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

```

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/03/10/qsb-077/

--
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/df012b65-2e7f-9fcf-3fb6-0daf6143d71f%40qubes-os.org.

Re: [qubes-users] Should the footer at the bottom of the mailing list be deleted?

[Eric W. Biederman]

Demi Marie Obenour  writes:

> The footer on each message is rather annoying, mostly because it breaks
> digital signatures.  Should it be set to the empty string, or do its
> benefits outweigh the drawbacks?

Doesn't it also break DMARC?  I remember that was a big fight 5 or so
years ago to get all of the mailing list software to do something that
was compatible with DMARC because all messages that came through
mailling lists from a source that enabled DMARC to a MTA that enforced
DMARC were bouncing.

Eric

-- 
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/87v8wl4o9f.fsf%40email.froward.int.ebiederm.org.

How to use "inline PGP"? (was: Re: [qubes-users] Should the footer at the bottom of the mailing list be deleted?)

[Peter Funk]

Hello, 

Demi Marie Obenour wrote Wednesday, 09.03.2022 16:33:
> On Wed, Mar 09, 2022 at 04:25:11PM -0500, Demi Marie Obenour wrote:
> > The footer on each message is rather annoying, mostly because it breaks
> > digital signatures.  Should it be set to the empty string, or do its
> > benefits outweigh the drawbacks?
> 
> Looks like Google mangles the message in other ways, too.  In my case,
> the charset is changed from us-ascii to UTF-8, and the
> Content-Transfer-Encoding header is removed, with the `=20` at the end
> of one line being replaced by a space.  So the only solutions are either
> inline PGP or to switch list hosting solutions.

Where can I learn, how to use inline PGP (GPG) properly in my messages?
I use 'mutt' as my preferred MUA.

Best regards, Peter Funk
-- 
Peter Funk ✉:Oldenburger Str.86, 2 Ganderkesee, Germany; :+49-179-640-8878 
homeoffice ☎:+49-4222-950270
office ✉: ArtCom GmbH, Haferwende 2, D-28357 Bremen, Germany; ☎:+49-421-20419-0

-- 
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/YinifIFO9rwL2%2BK3%40arbeit.


signature.asc
Description: PGP signature