Strange dependencies update

[KarlinQubes]

Hi there. Apologies for repost but I tried to login & it said incorrect p/w, and I used a temp email server (using Protonmail now).

Noob question incoming but your patience & knowledge are appreciated as always!

I’m currently operating on a pwned network (certain), with likely pwned hardware. This I am aware of and as such I don’t expect my Qubes installation to be secure, but I am using it as a chance to learn about the OS for now (and love it). Attempts to attack are expected.

So I noticed my Fedora34 cloned template had an update icon by it in QM, so I clicked update, and it launched a terminal style window with these dependencies:
"
Upgrading:
gnome-control-center x86_64 40.9-1.fc34 5.5m
gnome-control-center-filesystem-noarch 11k
keepassxc x86_64 2.6.6-5.fc34 6.3m
perl-module-corelist noarch 1:5.20220220-1.fc34 83k
perl-module-corelist-tools noarch 1:5.20020220-1.fc34 18k
selinux-policy x86_64 34.26-1.fc34 63k
selinux-policy-targeted noarch 34.26-1.fc34 6.3m

Installing dependencies:
freerdp-libs x86_64 2:2.5.0-1.fc34 998k
libvncserver x86_64 0.9.13-10.fc34 300kb
libwinpr x86_64 40.2-2fc34 95k

Installing weak dependencies:
gnome-remote-desktop x86_64 40.2-2.fc34 95k

Install 4 packages
Upgrade: 7 packages
Total size: 20m
Total download size: 6.3m
"

So in this I see essentially all of it refers specifically to remote desktop capabilities, with Keepassxc thrown in there. To my untrained eye this seems obviously unusual, but I’m hoping the bright brains in here can help me interpret this.

Is this expected behaviour? If it isn’t, is there a way I can inspect the updates of this and other Template VM’s to see if some things snuck by before? If it isn’t, can you explain to me why there would be an update of this kind with such a specific group of dependencies?

Thanks so much :).

Additional context if it is potentially interesting or informative.

Just prior to this update, I had tried to install Brave Browser in the same Template VM via sudo dnf install in the terminal.

It had run “sudo dnf install brave-browser”, and it fetched some packages and installed, and at the end what I noticed is it said “Error: GPG check failed”.

I didn’t read the rest of the text and I either closed out of it or it closed automatically, but with what happened immediately after it seemed worth mentioning, although not alarming.

Also to note that the Qubes updater was running updates on this specific VM before I launched it in the Qubes Manager & it was stalled out or taking a while, with no details, so I closed it and ran it in QVM.

Sorry for the long winded question, but as a newbie it’s great to have access to you veterans, and thanks again for all the information here and elsewhere!

[adw]

@KarlinQubes

So in this I see essentially all of it refers specifically to remote desktop capabilities, with Keepassxc thrown in there. To my untrained eye this seems obviously unusual, but I’m hoping the bright brains in here can help me interpret this.

Is this expected behaviour?

IMHO, yes. Random packages get updated all the time. It sounds like you might be letting paranoia get the best of you by seeing nefarious “patterns” in the packages that were updated at the same time when, in reality, they just all happened to have updates that day. My understanding is that if a skilled attacker really wanted to pull one over on you this way, it would be trivial to feed you the malicious updates at different times (and probably in more innocuous-sounding packages).

[KarlinQubes]

Great response! Thanks.

Does this mean that operating Qubes on a hostile network that has active efforts to compromise a system will inevitably lead to update packages coming in that will compromise the security?

Are there measures beyond only connecting to a trusted networking source that I can take to mitigate this risk, or a resource I can reference for learning more about it?

I’m still yet to fully understand the implications of working on a pwned network.

Thanks for taking the time to respond, Adw.

[KarlinQubes]

Also, is there a way to audit updates that come through against known secured repo’s to ensure their source is legitimate if I am to expect this particular attack vector to be utilized?

Thanks again, Adw.

[adw]

@KarlinQubes

Does this mean that operating Qubes on a hostile network that has active efforts to compromise a system will inevitably lead to update packages coming in that will compromise the security?

No, of course not. Qubes would be fairly pointless if that were the case.

Authentic updates are always signed, and Qubes doesn’t accept updates without valid signatures.

Here’s the documentation on dom0’s secure update mechanism.

@KarlinQubes

Are there measures beyond only connecting to a trusted networking source that I can take to mitigate this risk, or a resource I can reference for learning more about it?

I’m still yet to fully understand the implications of working on a pwned network.

Qubes always assumes that the network is already compromised and hence that sys-net is untrustworthy.

@KarlinQubes

Also, is there a way to audit updates that come through against known secured repo’s to ensure their source is legitimate if I am to expect this particular attack vector to be utilized?

Yes, verifying that the signatures on packages are authentic. But there’s no need to do this manually, as the OS already does it for you.

[Sven]

Moved into ‘User Support’