Arch Linux: out-of-the-box security gaps, cleaned up

Validated findings

1. No active firewall by default

   Real gap

   A plain Arch system does not come with an active firewall policy. That is not automatically dangerous if nothing is listening, but it becomes a real exposure the moment you enable a network-facing service and forget to restrict it.

   Fix: enable one firewall early. For simplicity use ufw; for native rules use nftables.

2. No mandatory access control by default

   Real gap Use AppArmor, not SELinux, for the easy path

   A basic Arch install relies on standard discretionary permissions unless you add an LSM policy layer. That means less process confinement than distributions that ship AppArmor or SELinux pre-wired.

   The original draft treated AppArmor and SELinux as equally practical fixes. That is misleading on Arch. AppArmor is supported by official kernels and can be enabled with standard packages and a service. SELinux on Arch is still an unofficial, AUR-heavy path that replaces core packages and requires more care.

   Fix: use apparmor, enable apparmor.service, and load actual profiles for the software you care about most.

3. No full-disk encryption by default

   Real gap

   A stolen laptop, removable SSD, or pulled desktop drive remains readable unless you deliberately set up LUKS during installation or migrate later. This is one of the clearest “default weak posture” items in a normal Arch install.

   Fix: use LUKS for the root filesystem. If you want convenience later, Arch documents TPM and FIDO2 unlock paths through systemd-cryptenroll.

4. No Secure Boot or signed boot chain by default

   Real gap

   Without Secure Boot, the pre-boot chain is easier to tamper with. This matters most for physical-access threats and for systems where you want more assurance that the boot manager, kernel, and initramfs were not modified.

   This also fixes a weakness in the original draft: “encrypt your disk” is incomplete advice. If your boot chain is not trusted, disk encryption alone does not fully address pre-boot tampering.

   Fix: set up Secure Boot. The strongest Arch path is a signed unified kernel image rather than signing only the kernel.

5. AUR use is a trust risk, not a distro flaw

   Common Arch foot-gun

   The original draft was right that the AUR is a serious real-world risk, but wrong to blur it into a “default install vulnerability.” A fresh Arch system does not require AUR packages. The risk appears when you expand the system with unreviewed PKGBUILDs, unofficial binary repos, or random install scripts.

   Fix: prefer official repos first, read PKGBUILDs before building, keep pacman signature verification intact, and treat curl | sh as arbitrary code execution.

6. Later service exposure is admin-controlled

   Important nuance

   The original draft implied Arch leaves you exposed because services are easy to forget. The correction is: Arch actually ships systemd presets with disable *, so most services are not auto-enabled when installed. That is a point in Arch’s favor.

   The remaining risk is operational: once you choose to enable services, Arch does not add distro-level guardrails for you. This especially matters for SSH if you install it yourself.

   Fix: periodically check systemctl list-unit-files --state=enabled, expose only what you need, and if you run SSH use key-only auth and disable password logins.

What I removed or downgraded from the original draft

• SSH as an out-of-box issue: not accurate. openssh is not part of the base meta-package, so this matters only if you install and enable it.
• Desktop app sandboxing as a base-install weakness: too broad. It becomes relevant only after you build a desktop stack and add apps. It is useful hardening, but not a core base-install vulnerability.
• “Use AppArmor or SELinux” as equal recommendations: too symmetrical. On Arch, AppArmor is the practical mainstream choice; SELinux remains officially unsupported and more invasive.
• “Arch users bypass the trust path” as a default weakness: true as a common mistake, but not an out-of-box condition. Official repositories already use package signing and trusted keys.

What Arch already gets right

• Official repositories use pacman package signing with trusted OpenPGP keys.
• The base meta-package includes archlinux-keyring.
• Arch package guidelines apply modern compiler and linker hardening such as PIE, FORTIFY, stack protector, NX, and RELRO.
• Most systemd units are not enabled automatically after package installation.

That does not make Arch “secure by default” in the hardening sense. It does mean the original draft needed balancing: the problem is mostly missing hardening choices, not weak package authenticity or auto-exposed services.

Suggested order of operations

1. Enable a firewall.
2. Set up AppArmor and load profiles you will actually use.
3. If this is a laptop or portable drive, put root on LUKS.
4. Protect the boot chain with Secure Boot and, if possible, a signed UKI.
5. Stay in official repositories unless you have reviewed the AUR package yourself.
6. If you later install SSH or other daemons, harden and audit them explicitly.

Sources

• Arch base package metadata
• ArchWiki: pacman package signing
• ArchWiki: security package guidelines
• ArchWiki: UFW
• ArchWiki: nftables
• ArchWiki mirror: AppArmor
• ArchWiki mirror: SELinux
• ArchWiki: encrypting an entire system
• ArchWiki: dm-crypt system configuration
• ArchWiki: Secure Boot
• ArchWiki: unified kernel image
• ArchWiki: AUR warning text
• ArchWiki: systemd presets
• ArchWiki: OpenSSH hardening guidance