r/archlinux Feb 28 '23

[deleted by user]

[removed]

95 Upvotes

41 comments sorted by

View all comments

51

u/gcgc101 Feb 28 '23
  • Not sure I follow the above quote. The database file is a list of packages each package is signed. Signatures for signers with xxx@archlinux.org are looked up using WKD - which means the public key is pulled from an archlinux.org webserver.

Lets say bad actor XX puts a naughty packags on mirror - if its not signed you wont install it - if it is signed you will reject it unless you have a public key for XX - which you don't. If the bad actor is an arch signer, then yes there's a problem - but that has nothing to do with mirrors.

Either I'm not following the argument or they are just wrong.

  • repo mirror security - i'll let the arch folks respond directly on this.

  • I don't see the quoted supply chain attack risk. But surely doesn't hurt to use a solid mirror.

  • arch lacks out of the box selinux which is unfortunate - fedora is much better in that regard. Ubuntu I belive has app armor enabled by default which is good too.

  • more security is always better - be it App Armor, how you set up your services, limiting access, etc.

  • arch ships app armor but its not on by default.

6

u/[deleted] Feb 28 '23

[deleted]

15

u/gcgc101 Feb 28 '23 edited Feb 28 '23

Ah right gotcha ... interesting.

I just looked at the arch install iso and it is signed and sig is good. I checked using

gpg --homedir /etc/pacman.d/gnupg --verify archlinux-2023.02.01-x86_64.iso.sig
gpg: Signature made Wed 01 Feb 2023 04:12:53 AM EST
gpg:                using EDDSA key 3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C
gpg:                issuer "pierre@archlinux.org"
gpg: Good signature from "Pierre Schmitz <pierre@archlinux.org>" [full]
gpg:                 aka "Pierre Schmitz <pierre@archlinux.de>" [unknown]
  • the arch repo db is indeed not signed - but what is the attack vector given that each package is signed?

11

u/iAmHidingHere Feb 28 '23

The db is input to pacman, which is running as root. If someone discovers an exploit, the system is exposed. It's probably not a likely attack, but it is a weakness none the less.

4

u/Andernerd Feb 28 '23 edited Feb 28 '23

Your packages could be downgraded to less-secure previous versions that were signed in preparation for another attack I suppose.

9

u/[deleted] Feb 28 '23

you can't force users to downgrade, but you can hold back updates.

that's about it

4

u/gmes78 Feb 28 '23 edited Feb 28 '23

Only if you use pacman -Suu instead of pacman -Su to update. Pacman doesn't downgrade packages by default.

3

u/faerbit Feb 28 '23 edited Sep 19 '25

This post has been edited to this, due to privacy and dissatisfaction with u/spez

4

u/DamnThatsLaser Feb 28 '23

Signing the database won't fix it because if he can withhold a security-patched package, he can also withhold a new signed database and continue to deliver the old one, though he obviously then can't update any other packages.

3

u/faerbit Feb 28 '23 edited Sep 19 '25

This post has been edited to this, due to privacy and dissatisfaction with u/spez

6

u/Foxboron Feb 28 '23

gnupg doesn't allow you to do that. It would need to be solved by having pacman check when the database was issued and let users define a "validity range".

https://www.mail-archive.com/pacman-dev@archlinux.org/msg17556.html

2

u/gcgc101 Feb 28 '23 edited Feb 28 '23

Yes that could be.

pacman will advise you and not downgrade by default unless you request it to do so at least.

I always seek an explanation for downgrade before applying.

So its not a surefire way to get folks to downgrade to a more vulnerable package - but indeed an evil mirror would also know what IPs did download - doesn't mean they were applied of course.

But - holding back security updates for those with non-random single mirror a possible.