Arch Linux Distro Preview

Development
#1

I have been playing with Arch and some their variants (like arcolinux) since like a year, And here is what i have seen:

What arch solve:

Continues upgrades to the packages which solve debian issues:

  • Solve outdated packages which effect new features,non-security fixes
  • Solve some packages security issues were they are not listed as CVE
  • Minor to non-breakable system even when using upgraded packages to upstream level
  • Ease to switch and choose different kernels
  • Ease to push new added packages compared to debian

Arch issues:

  • Arch is based mainly on systemd, Doesnt give the option to have non-systemd from upstream similarly/easy as to debian which gave devuan and its fully functional. (There are projects who build archlinux without systemd like Atrix, But its faraway to fill all essential user needs)
  • Arch doesnt come with any easy way to install it, Its fully manual/cli installation which is not easy at all for new comers. (There is a project which give arch+calamares installation called Alci)
  • Arch doesnt support by default any architecture except 86x_64x. (And there is only unofficial ARM support, NO IBM-Power CPUs/ppc64)
  • User need to refresh keys before upgrading otherwise gonna see messages like:(safe to proceed but annoying, not happening on debian side)

archQ2
archQ2807Ă—149 150 KB

  • Multiple warnings user going to see but its not clear on why or what should be done…etc

archQ3
archQ3815Ă—181 148 KB

  • Asking questions which are not really easy to answer nor what are the consequences behind the answer going to be by just performing normal upgrade:

archQ
archQ792Ă—200 228 KB

  • Arch package manager pacman doesnt come with easy to use commands like install,remove,upgrade… instead it comes with only letters S,y,Rdd,…etc (user need to see and learn the manual of pacman in order to use it properly)

  • Arch is not free software distro by default similar to debian

Security Concerns:

  • Arch doesnt come with any MAC by default not apparmor nor selinux or any other (need to be manually activated). (Debian and Fedora comes with one)
  • Arch ignored for a long time signing their packages and handled the full trust to the third-party mirrors check here (2008) and here. To the level it considered one of the “Package Managers Without Security” according to TUF in 2008.
  • Arch still using outdated checksum md5 and sha1: (from their download page)

Checksums

File integrity checksums for the latest releases can be found below:

PGP signature
PGP fingerprint: 0x9741E8AC
WKD Lookup: gpg --auto-key-locate clear,wkd -v --locate-external-key pierre@archlinux.de
SHA1: 3f3ba996e7d8e0b15d911180682093cd8fe6b805
MD5: 8731d4beaf66c4a280d3246b807beb33
  • Lack onion mirrors (Looks like lack of interest)
  • AUR packages lack signing or any mean to trust.
  • As of today date archlinux still using iptables by default and not nftables, Ironically they note that iptables is the legacy firewall here: (Debian deprecate it by default and replaced it with nftables since more than one year)

Note: iptables is a legacy framework, nftables aims to provide a modern replacement including a compatibility layer.

Conclusion

  • Since it lack many features by default like user friendly installation and some essential packages, The work on devs who gonna fork it will be heavier than if it forked from debian.
  • Arch devs seems that the security is their last concern, Although the distro continuously upgradable and has good documentation their distro is behind the line when its compared with debian or fedora.
  • The only useful way i can see it for whonix if we do all these fixes from our side properly, If it considered easy/under the hand tasks then yeah arch might sound useful to have, otherwise difficult task.
2 Likes
#2

Quote (bold is mine)

The package managers without security (Slaktool, ports, Pacman) are not impacted because an attacker can create arbitrary packages.

Need to figure out what changed how meanwhile, maybe.

#3

In general I don’t think that in term of security they are major differences between Debian and Arch because by default they are all bad (cf Linux (In)security).

However, as a long time arch (and Whonix) user, I can provide a few additional bit of information.

Arch does come with MAC. All official kernels have support for both SElinux and AppArmor (your link is 7 years old…). However, in the arch way, it is up to the user to enable it in the kernel command line and to install and enable the user-land tools and profiles. See: AppArmor - ArchWiki
In this context, the user would be Whonix dev, not Whonix end user. Anyway, as usual with AppArmor, if you don’t have the profile, you MAC system is useless. And that is Whonix work to provide it.

This has long been fixed (your link is 14 years old…). Pacman has both packages and database signature verification support.

Nothing too complex IMO, but have a look at the Rosetta stone: pacman/Rosetta - ArchWiki

These are actually useless as all ISO are signed.

Good to mention too

2 Likes
#4

Thanks! This could use some review.

Agreed. Since gpg signature is available the other checksums are obsolete / optional.
Confusing (as evidence in this forum thread) and bad in the view of security enthusiasts users but no actual security issue.

I see the point. But effectively it boils down for all practical purposes relevant here to “has no MAC”.

What’s the practical purposes relevant here? Well, that’s the previously unspoken assumption. That’s the topic of “can/should Whonix use a better/more secure/you name it base Linux distribution”?

Related:

So the kind of MAC that we’re looking here fore is if the base operating system comes with lots of well maintained, strong MAC profiles for useful default applications in context of Whonix by default.

(What I mean by base operating system or base Linux distribution? Debian, Arch, etc.)

Interesting. I can see you digged deep into Whonix if you mention that.

Leaving this reference for others wondering what this is about here… Whonix / Kicksecure are using:
config-package-dev

Got any reference of that?
Does Arch Linux nowadays pass the TUF threat model?

1 Like
#5

The pacman man page is the source. In pacman.conf(5) — Arch manual pages see SigLevel.
For example, in my /etc/pacman.conf I have:

SigLevel           = Required DatabaseOptional
LocalFileSigLevel  = Required
RemoteFileSigLevel = Required

I could not say regarding the exact TUF threat model. Especially because in practice only the packages are signed, not the database. This is because it requires a CI with the secret keys, this is still a WIP inside arch. See [arch-dev-public] build automation discussions

This is not Arch specific, but you may have a look at my own apparmor profiles project: GitHub - roddhjav/apparmor.d: Full set of AppArmor profiles (~ 1400 profiles). I planned to test it inside Whonix, but I haven’t find time for this yet.

3 Likes
#6

From my search, Arch doesnt sign the metadata of the packages but only sign the data/package (dnf-fedora doing the same), Thats as well looks bad e.g check this discussion regarding this point:

True, But the mentality of the devs just faraway to say they are security expert or caring because compare this to whonix which uses SHA512 and Signify for their images… Arch just isnt for security related stuff.

Same answer above, I know its fixed (already mentioned that) but the mentality to let your project criticized for years for obvious critical security flaw is just stupid behavior from the developers.

#7

Arch cant be installed unless connected to the internet, This is recommended against behavior according to Debian security guide:

https://www.debian.org/doc/manuals/securing-debian-manual/ch03s03.en.html

#8

Some time you cant proceed with update/upgrade unless you refresh the distro keys: (mentioned in original post)

archlinuxkeys
archlinuxkeys795Ă—468 66.3 KB

Which take time with dozens of the errors (According to arch wiki they say these errors are ok):

archlinuxkeys2
archlinuxkeys2795Ă—466 65 KB

1 Like