In line with the PG's recommendations, what should be the minimum requirements for a secure Arch Linux installation?

Compared to OpenSUSE and Fedora, I believe that Arch Linux can do a better job for the average home desktop pc users, at least for me, in terms of package and application variety, package manager, update periodicity and frequency, etc.

We can learn from your suggestions and integrate them into our systems.

It was listed as a DIY distribution, primarily because of Reproducible Builds as a way to reduce the risk of supply chain based attacks, for that reason NixOS is listed also.

For desktop, the main reason we recommend Fedora, is because it’s fairly secure by default, and comes with some default policies. Of course no distribution has extensively hardened policies, although there is an aim to improve that with the ConfinedUsers SIG.

I can understand why you recommend Fedora and OpenSUSE, but some important packages that I use are not available in RPM repos. Would AppArmor, firewall, secure boot, Wayland, linux-hardened kernel, etc. for Arch be insufficient for the minimum requirements?

https://wiki.archlinux.org/title/Security

If they’re not available, you could try packaging them yourself, and then add your own COPR.

Won’t really help you much unless you write your own policies, many of them are out of date so they will need tweaking. It’s not going to be an install and forget.

A lot of security hardening things unfortunately aren’t as simple aren’t as installing software. It really does depend on what you’re trying to achieve and what your concerns are in particular.

There’s also the privsec guide which is probably slightly more up to date than arch wiki. There is also the madaidan guide, which may provide some areas to think about.

The problem with guides like this though is they get very long winded when there’s target for many distributions, some things are not possible in all cases.

4 Likes

Thanks for the links @dngray. I have an additional question. As articulated in another post I made, would it be useful to utilize fscrypt to encrypt my home directory on top of LUKS in order to encrypt my data while my laptop is on but logged off?

I was talking about using the criteria of this medium, not the criteria of that website.

And I suddenly found myself a user who went a few steps beyond being an average home user. :grin:

This also applies to the OpenSUSE you recommend and other Debian-based distributions, right?


Thanks for your comments.

I personally feel Arch is one of the worst choices for most Linux users. Not because I think Arch is a bad distro, I think it is a great distro for the right type of person, but it is a very DIY-centric distro that expects a lot more know-how, informed decision-making, active management, and discipline from the user/admin than most users are willing to give. For this reason I think Arch is a poor choice for the vast majority of security minded people, and a good choice for some people who want that level of control and are confident in their ability to properly secure their system, use it responsibly, and maintain it consistently.

With that said, here is what I personally would consider a good starting point in Arch:

  1. An informed user (most important point, particularly with Arch) who has read all the introductory wiki entries as well as the maintenance and the security sections, understands the DIY-centric nature of Arch and the shortcomings of Arch.
  2. Install Arch Manually (the traditional way) so you understand how your system is configured, and know what you have and have not done.
  3. Full Disk Encryption
  4. Secure Boot
  5. Wayland + Pipewire (which limits you to either Gnome, Plasma, or a small handful of window managers)
  6. BTRFS + Snapper (this is not a security related point)
  7. Apparmor or SELinux installed, setup, AND properly configured for your system/distro
  8. If you use BTRFS, you’ll want to setup encrypted /boot as well, or some workaround.
  9. Probably lots of other small things (I’d suggest going over the security section of the wiki in depth, I think there are a lot of small things and finishing touches distro maintainers would normally consider and implement that will be left to the user in Arch.
  10. Do not use an AUR helper, at least until you teach yourself to manually read PKGBUILD files and force yourself to get in the habit of doing so before installing or updating AUR packages.

Personally I’m interested in Arch and I’ve tried a few times to manually configure Arch to the basic standard of security I get out of the box with a distro like Fedora, Ubuntu, or OpenSUSE. With a lot of research, reading, trial and error, and effort, I can get most but not all of the way there (points 4, 7, 9, and 10 are where I don’t feel confident in my competence). I am far from a new Linux User (it has been my primary operating system for 10+ years), but with my level of experience and commitment, I’d consider pre-configured distros to be the more responsible choice with respect to security and stability.

6 Likes

We do warn about that: Desktop/PC - Privacy Guides

Being a DIY distribution, you are expected to set up and maintain your system on your own. Arch has an official installer to make the installation process a little easier.

I still think best bet is to use Fedora, it has fairly good secure defaults, and far easier to package single package in RPM, than it is to learn an entire DIY distribution and it’s components.

What is also good about COPR is those packages are then built on Fedora’s infractructure, so if someone wants to use your RPM, or modify it they can simply fork your repo, use your RPM spec, and make their own package (and sync repository at points they feel comfortable with).

1 Like

I’ve honestly tried to use distributions other than Arch. I just keep breaking them. Or the software I want is not there (like Signal on Fedora). Fedora broke on me in one week. I’ve maintained an Arch install for 3 years with minimal breakage that was easily fixable because everyone had the same issue and were already posting about it in the forums.

When Fedora broke, I couldn’t even begin to fathom what went wrong. An hour or so later and I was no wiser. I’d had enough of Fedora after a week of bugs and inconveniences anyway, so I packed up and went back to Arch. Even packaging is more difficult on Fedora. I maintain a few PKGBUILDs myself, but the guidelines document for Fedora scared the hell out of me.

For me, Arch is just less work… I haven’t been able to get along with any other rolling release.

That being said, I agree with you from a security POV. I’m confident a significant amount of security apparatus is not properly setup on my Arch machines. And Archinstall errored out the last time I tried it (which was a few months ago) :slight_smile:

Sorry, I’m venting a bit. I’ve been trying to get away from Arch because I agree in principle with PG’s recommendations, but I haven’t been able to manage it…

For the record, my first Linux distribution was Ubuntu, and it stopped booting within a month.

1 Like

The criteria listed on PG’s website are extremely minimalistic. Since the security of Linux distros in their default state is not great, additional hardening is very much recommended.

Same here. I used Debian, Ubuntu, Mint, Fedora and a few others in the past on desktop and some on server. Most of them broke at some point and were terrible to fix. Arch has been at least as stable as other popular distros, maybe even more stable. I really see no reason to use a distro which freezes packages at this point on desktop (except maybe Fedora) and if Arch had a sane default setup for server, I would not hesitate to use it on a home server, either. And with EndeavourOS you get an easy to install minimalistic setup for desktop. I am inclined to try Tumbleweed to see how it compares to Arch, though.

1 Like

I gave Tumbleweed a shot and I love a lot of things about it…I don’t love the Open Build System. If it has all the packages you need, it should work for you. It was the distribution I most liked compared to Arch. It feels quite beginner-friendly too.

What do you mean by this?

As far as I am aware signal-desktop is not officially available on Arch or Fedora but is unofficially available for either distro (flatpak, snap, AUR, COPR, or from source).

edit: I just saw that signal-desktop is included in the Arch Repositories but not officially supported or recommended by Signal.

You can’t say any software is “officially” available on any distribution if it’s in the distribution’s repositories, which covers thousands of different programs, including Linux, GNOME, your web browser, and pretty much everything else. If you don’t trust your own distribution’s repositories, there’s a problem with your chain of trust.

About the only exception to this rule is source-based distributions like Gentoo, where you can actually inspect the ebuilds as they change before building them again. Of course, you need to trust the initial tarball you use to install Gentoo first.

When I was using Fedora, I stumbled across this issue. I spent over an hour reading it and trying to weigh options as to what was the right way to install Signal.

cryptomilk made this observation:

As a Fedora proven packager, I’m more trustworthy if I package Signal in Fedora than outside? […] I would argue that nodejs apps per default are not trustworthy. You should be careful how you run them. I have signal-desktop still secured with apparmor.

(I’m inclined to agree)

It seems like the COPR would be less trustworthy than the OBS version because cryptomilk is one of the people who packages other Fedora packages. That way, your web of trust does not expand any further. OBS also automatically builds from source with no human intervention. But there does not seem to be any way to update it automatically, which is a big pain.

One of the problems with Flatpak is that it doesn’t give you a diff when the Flatpak manifest changes, so you don’t get a chance to notice malicious changes. It does at least inform you if the package requires additional permissions, though.

On Arch, the same people who develop my distribution package Signal. I just installed it and I was done. No calculus. It has just worked for three years.

Signal wasn’t the only program not available in Fedora’s official repositories, but it was the one I remember having the most trouble with. I guess Audacity counts too because the official version is old and neither the Appimage/Flatpak worked properly.

1 Like

While I agree with this, the distro’s repo is still different to any random person’s repo (home projects on OBS, for example). At least, I trust openSUSE and its operations more than a random person. The distro’s repo is the official software installation method of the OS. If the distro’s repo can’t be trusted, the OS can’t be trusted/used either.

However, I would trust/use software from the dev’s official channel rather than my distro’s channel. For example, I would use Darktable from the official repo on OBS rather than the one from openSUSE Factory, as I trust the upstream packagers more than even my distro. If this is not the case, I wouldn’t use Darktable at all. The same goes for Blender, that I grab it from the Blender website, not the one from openSUSE Factory. Etc.

Well, I made that comment before seeing that signal-desktop has been added to the Arch repositories (this is why I edited my previous comment). I prefer software either from (1) my distros official repos, or (2) directly from the developer or any channel endorsed by the developer. So the Arch package would satisfy me. I definitely don’t mean to imply anyone shouldn’t trust their distros official repositories.

But it is also not quite as clear cut as you make it out to be. Contrast Firefox’s Linux recommendations with Signal’s. On their website Signal only links to or mentions their Debian/Ubuntu repo and does not recommend any other distribution channels for Linux as far as I can see. Firefox on the other hand prominently recommends installing via your distros package manager and official repositories OR via Mozilla’s official snap or flatpak packages.

2 Likes

In the case of Signal, I think if they didn’t want people to use their distribution repositories, they would mention it like they do with the APK: Signal >> Signal Android APK

Danger zone

Advanced users with special needs can download the Signal APK directly. Most users should not do this under normal circumstances.

This is a pretty clear discouragement for using the APK directly, and they only provided it as a harm reduction strategy.

The page itself is completely hidden from the website and only accessible with a link from their Github page.

I’m not sure what Signal’s official position is on non-Debian distributions. Is building from source the only recommended method? Best I can find is this method in the CONTRIBUTING.md file.

It would definitely help if there was some official guidance for Linux like there is with Android.

2 Likes

This would be hard to tell. However, I can assume from this answer on their GitHub issue:

Basically, non Debian distros seems to get zero support/interest from Signal. Maybe, this is another interesting thread regarding non-official Flatpak packaging concern:

Not using Signal is my solution. I would also oppose my family and friends from using Signal (if they should have this weird idea), because I would have a really hard time connecting with them on my laptop running openSUSE.

@xe3 Thank you for explaining your view. Can we include the linux-hardened kernel in that list?

I get it.
Video tutorials make it easier for me to learn. Unfortunately, most of the tutorial videos are “lightweight installation, installation in 2 minutes” themed.


Meanwhile, like many other Linux threads on the internet, this thread has discussed things that are unrelated to the question. :sweat_smile: