---
title: "linux and security"
description: "a guide to linux & computer security for newbies and professionals"
author: "slonkazoid"
written_at: 2025-03-29T11:00:00Z
tags:
- draft
- linux
- security
- virtualization
---
# linux and security
here i discuss the basics and the not-so-basics of OS-level security, alongside a bit of information about
[linux](https://en.wikipedia.org/wiki/Linux)
WARNING: this is post is a messy draft of stuff i needed to get off my chest.
i'll make it into a proper series of posts once i can be arsed.
## terminology
- **linux distro**, **linux distribution**: an operating system based on the [Linux kernel](https://en.wikipedia.org/wiki/Linux_kernel)
- **kernel**: core part of the operating system responsible for talking with the hardware, managing the filesystem,
network communication, running programs, etc.
- **operating system**: collection software to operate a computer. e.g. Fedora Linux, SteamOS, macOS, Windows, FreeBSD,
iOS (Apple), IOS (Cisco), IOS (Nintendo)
- **root**: most privileged user in linux, highest level of permissions a process can have, rough
equivalent of "Administrator" in windows
the rest of the terms are explained in their respective sections.
## distribution
you can't just "install linux". linux isn't an operating system itself, but a *kernel* to build an OS on top of,
though the term is also used generically to refer to all linux distributions.
linux-based operating systems are called "linux distributions", as they quite literally *distribute linux*,
along with system components, applications, and other software to form a complete operating system (OS).
you must pick a distribution first, but don't let that intimidate you; the selection might be large, but
it is possible to switch later on.
no matter which distro you pick, you should consider enabling
as everyone in the linux community knows, there is no one distribution that is the best for everything. some
options for security and ease of use include:
### general purpose
- 
[**Fedora Linux**](https://fedoraproject.org/): a well polished daily driver distribution with extensive security
features, setting a high standard for the rest. i recommend the [Fedora Linux KDE spin](https://fedoraproject.org/spins/kde)
to newcomers, as it is a really good desktop experience overall. i daily drive Fedora KDE on my main tower.
the downside of Fedora is that it's repositories are… barren, to say the least. to install anything considered
'non-free' (this includes bullshit software patents such as FUCKING x264, and nvidia drivers), you need to add
the [RPM Fusion](https://rpmfusion.org/) repository, which is "third-party software sources not officially affiliated
with or endorsed by the Fedora Project", but only on paper. that excerpt is from
[the official Fedora docs telling you how to enable it](https://docs.fedoraproject.org/en-US/quick-docs/rpmfusion-setup/),
so, yeah… it's only wonky between major version upgrades, so i'd consider it safe to use.
- 
[**Debian**](https://www.debian.org/): it's debian. it's a rock solid base to craft your own experience in. while
it is not that secure *by default*, it has a lot of potential for further fortification. it has one of the
biggest official repositories in the linux world, though, maybe not the best. if you want maximum software compatibility,
debian is your distribution. even while being more light than Arch Linux, "A simple, lightweight distribution", it enjoys
maximum compatibility and stability. this is my go-to for servers for a reason.
- 
[**Arch Linux**](https://archlinux.org/): everyone's favorite. Arch's main quirk is that it's a DIY distro, meaning
if you want something, you go get it yourself, there is no 'default' Arch installation. there exists a TUI installer
now built into the live ISO called `archinstall`, but i highly recommend against using it. this is not for elitism or
gatekeeping reasons! if you want an installer for Arch, please consider using EndeavourOS instead. `archinstall` is
an insecure installer script with a lot of hidden state, and goes against a lot of what makes Arch Linux, Arch Linux.
one notable example is [the fact that it saves your plaintext password in a world-readable file](https://github.com/archlinux/archinstall/issues/1111).
Arch overall is not fit for a holistic desktop experience, but that doesn't mean you can't use it as a desktop distribution,
you just need to *make it* fit for that. this is both the superpower and major downside of Arch.
the [ArchWiki](https://wiki.archlinux.org/title/Main_page) is an amazing resource for not just Arch, but linux in general.
one of the selling points of Arch is the [Arch User Repository](https://aur.archlinux.org/), a massive user-curated repository
for Arch [PKGBUILD](https://wiki.archlinux.org/title/PKGBUILD)s. it's characterized by it's freedom, wide selection of
packages available, and ease of use. what most people don't tell you is that it's basically a FFA warzone of unreviewed
shell scripts, which you can imagine why it would be bad for security and stability.
- 
[**EndeavourOS**](https://endeavouros.com/): EndeavourOS is better known as "Arch with an installer" or
"Arch with a GUI", and that's mostly correct. it's a slightly more polished/curated/opinionated desktop version
of Arch Linux, with a GUI installer and other tools. if you are new to linux and looking to try arch, i recommend
trying EndeavourOS first, as your first Arch install being a DIY would mostly likely leave you disappointed in Arch.
- 💀
[**Manjaro Linux**](https://manjaro.org/): Don't use Manjaro. It's a pretty poor experience with a track record of breaking
packages- even inadvertently DDoSing the AUR. Twice. You can read more about the ~~misfortunes~~ skill issues of Manjaro on
the ~~in~~famous [Manjarno](https://manjarno.pages.dev/) post. EndeavourOS is everything Manjaro wishes to be, minus the selling
laptops part. if you are a newbie considering using Manjaro, please just use EndeavourOS instead. Not recommended.
- 
[**Ubuntu**](https://ubuntu.com/): ["Ubuntu is the Windows of Linux distributions"](https://www.google.com/search?q=ubuntu+is+the+windows+of+linux),
people say, and i can not blame them. Ubuntu in 2025 is an enterprise distribution more focused on selling to corporations
than user experience. it *used to* be a good desktop and server distribution with great software support, but it has lost
it's ways. nowadays, it's a slow, annoying ~~piece of crap~~ distribution with no sane package management. despite this,
companies seem to love it and continue supporting it. despite all this, it remains a viable desktop distribution, with extended
security updates. if configured right, it can be made to be a more user-friendly Debian. i remain ambivalent about modern Ubuntu.
### security oriented
- 
[**Alpine Linux**](https://alpinelinux.org/): Alpine is a minimal, musl-based distribution designed to be **secure** and **simple**.
compared to traditional distributions, it has a significantly reduced attack surface. with the
[minirootfs image](https://dl-cdn.alpinelinux.org/alpine/v3.21/releases/x86_64/alpine-minirootfs-3.21.3-x86_64.tar.gz)
being 3.3 MiB, you can use it on practically anything. it is also quite customizable, and has a PKGBUILD-like
system called [APKBUILD](https://wiki.alpinelinux.org/wiki/APKBUILD_Reference) for building your own packages
or easily modifying existing packages. with ongoing efforts to port systemd to it, it is becoming more realistic
to use as a desktop distribution, but it's definitely still a server OS first. i use alpine for some containers,
or when i need a small rootfs to do hijinks and tomfoolery in. easily the most auditable conventional distribution,
fit for applications with high security needs.
- 
[**Tails**](https://tails.net/): Tails is an interesting one. it's a live distribution, meaning it doesn't
*install* to a disk, but instead flashed to portable media to boot anywhere, it doesn't persist any of the
documents you open or apps you install, everything is kept in RAM and cleared when you shut down. it uses
[Tor](https://www.torproject.org/) routing for everything by default for anonimity.
i think it's worthwhile to have it on an USB somewhere just in case, especially in today's world.
- 
[**Qubes OS**](https://www.qubes-os.org/): as it says on the box: A reasonable secure operating system. Qubes OS
virtualizes *everything*, at the cost of usability, performance (no GPU acceleration!), and basically everything
else, like maximizing *one* stat in a role-playing game… it also uses Xorg.
some other "security oriented" distros are mostly memes or niche cybersecurity toolbelts.
examples include:
- [**Kali Linux**](https://www.kali.org/): penetration testing OS with lots of relevant tools preinstalled and preconfigured.
- [**BlackArch Linux**](https://blackarch.org/): a meme
these distributions are not magic. if you are intending to do cybersecurity work, you can install all of these tools
on a conventional linux distribution. they are just a bit wonkier than other software because cybersecurity people
are really bad at packaging software for some reason.
## software
this section details how to install software on linux, and the sources you should get them from.
No amount of security measures will protect you if you violate the golden rule: Don't fucking run random
stuff you find off the internet. it is still wise to try to isolate rogue or more likely vulnerable software.
the main method for getting software for linux is using *package managers*.
"package manager" is a generic term for software that let you install, upgrade, remove. or otherwise manipulate other
software, including the OS.
when used alone like in this section, "package manger" usually refers to the OS default package manager (`dnf` for fedora,
`apt` for debian, `pacman` for arch, etc.).
the operating system's package manager is the most basic (not simple!) way of installing software (unless you consider
downloading an archive to be 'installing' software), but it usually requires [root](#terminology) privileges because you are modifying
the operating system.
*repositories* are places package managers look to download packages (could be an application, or a part of the OS), and are
critical to their function. repositories provide the following information:
- list of available packages
- the actual packages
- cryptographic signatures of the information above
package managers are usually configured to pull information from multiple repositores, allowing you to choose where you get
your software from, and add your own if you want.
### software center
the software center, or the "shopping bag icon" refers to the package manager GUI of your choice. it usually has a shopping bag
icon and the generic name "Software Center" in whatever desktop environment you use. it's where you will be installing, removing,
and upgrading most of your packages and operating system. it will look something like this:
how do you get apps via the software center? well, you can type the name of the thing you want in your start menu:
…or you can click on the shopping bag icon and search it there!
uninstalling stuff is just as easy. find the app and hit 'Remove':
#### flatpak
flatpak is a package manager for linux, focused on providing a great GUI experience and security by sandboxing apps. flatpak
applications usually have strong desktop integrations, and work across a wider selection of distributions. it's official repository,
included in some (😒) distributions by default is [Flathub](https://flathub.org/). Flathub builds, curates, and provides thousands
of linux applications for you. it should be the first place you look at to get new apps.this is extremely controversial
below is the badge you'll see on projects that are on Flathub. you can click it to be redirected to the page to install the application.
flatpak has a permissions system like old Android. apps request permissions while you are installing or updating them, and you can
choose whether to continue with the installation or not. you can also override these permissions using applications like
[Flatseal](https://flathub.org/apps/com.github.tchx84.Flatseal), or through the system settings if your OS supports it.
i recommend adding the flathub and flathub-beta repositories as **user** repositories, which makes it so installations are owned by
you and in your home directory. this does make apps private to your user instead of available to everyone, though, so keep that in
mind if you have sharp storage constraints. read more about "System versus user" on the
[flatpak docs](https://docs.flatpak.org/en/latest/using-flatpak.html#system-versus-user). to do this, enter the following commands
in your terminal:
```sh
flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --user --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo
```
you should review what permissions flatpak apps request before installing them. in addition, on flathub, packages published by the
original developers will have a verified badge, so pay attention to that. "unverified" apps aren't necessarily insecure, it just
means that the person(s) packaging the app are not explicitly authorized by the original authors, and therefore the package is unofficial.
#### OS package manager
conventional linux distros come with a default package manager, through which the operating system and default applications are
installed. Fedora has `dnf`, Debian and Ubuntu have `apt`, etc. the OS package manager is also
stick to official repositories not just for malware-related reasons, but also because unofficial repositories
aren't maintained up to the same standard and can break your system. in the end, it's your choice who you trust.
i recommend using the package manager to get stuff like CLI programs and development tools such as IDEs,
[rustup](https://rustup.rs/), and such.
### other
what to do if the application you want isn't available (or outdated) in the software center?
well, you go to the project's website and follow the installation instructions. apps may not want to be included in official
repositories—or the other way around—for a plethora of reasons, therefore a lot of them choose to host their own.
### Windows applications
see [Wine](https://www.winehq.org/).
### games
Just use [Steam](https://store.steampowered.com/)
. that's it. if the game you want isn't on Steam, add it to your library.
if you want to play Epic Games or GOG games, take a look at [Heroic Games Launcher](https://heroicgameslauncher.com/)
.
for Minecraft, use [Prism Launcher](https://prismlauncher.org/)
, even on Windows. it's lightyears ahead of the official
launcher.
---
**the section below is for advanced users only; recommended to do your own research concerning these topics**
**it is filled with major footguns that unless *you know what you are doing*, you are likely to misuse**
---
## compositor
aka: "Desktop Environment" (DE), "Window Manager" (WM)
you could use something tried and true like KDE Plasma/GNOME or go with a more minimal, safer approach like
[niri](https://github.com/YaLTeR/niri). **stay away from Xorg**, it is 6000000 lines of barely functional code
with an inherently insecure protocol, requiring the reimplementation of display, input, etc. drivers for itself
(more attack surface! yay!). stick to wayland + Xwayland for X11 apps. i recommend staying clear of
[wlroots](https://gitlab.freedesktop.org/wlroots/wlroots)-based compositors because the only 2 functional ones
have major downsides:
- [**sway**](https://github.com/swaywm/sway): tons of memory corruption bugs, and no security for screen capture
- [**Hyprland**](https://github.com/hyprwm/Hyprland): untrustworthy and bigoted maintainer. consider it compromised.
my compositor of choice is KDE Plasma. it *just works* out of the box and comes with security features that are
missing in some other popular compositors. it's also the first DE i daily drove.
## luks
LUKS ("Linux Unified Key Setup", though no one cares what it means) is a method of disk encryption for linux.
you interact with it using `cryptsetup`. it supports detaching the encryption metadata from the disk itself,
providing plausible deniability without compromising security.
### defaults to keep
- argon2id
- aes-xts-512 (2 256-bit keys, same security as aes-256 for other modes)
- no discards (harms performance in exchange for plausible deniability!)
### recommended options
these options will make unlocking the partition far slower in exchange for strength against wordlist
and bruteforce attacks.
- high `--iter-time` (like 5000ms) or force params:
* `--pbkdf-force-iterations=24` (for argon2id, this is a high value)
* `--pbkdf-memory=` (16777216 for 16 GiB, 1048576 for 1 GiB, etc.)
* `--pbkdf-parallel=4` (this is the default, but it's capped by nproc)
- might want to consider dm-integrity (`--integrity` in `luksFormat`), but it will
absolutely slash write speeds. i recommend using a filesystem with checksumming instead
```sh
cryptsetup luksFormat --cipher=aes-xts-plain64 --key-size=512 \
--pbkdf=argon2id --pbkdf-force-iterations=24 \
--pbkdf-memory=8388608 --pbkdf-parallel=4 \
/dev/
```
## filesystem
i recommend btrfs with the BLAKE2b checksumming algorithm, and no compression. but
the 'no compression' part might hurt performance and waste disk space, and the confidentiality
gains are in the paranoia zone.
```sh
mkfs.btrfs /dev/mapper/ --checksum blake2
```
## kernel
use a known-good kernel. linux-hardened is a popular one but imo it cuts down on usability for
non-existent 'security' gains. SELinux is recommended.
### lockdown
this is enabled by default if you boot with Secure Boot, but you might want to change it to it's
stricter mode: `confidentiality`.
### cmdline
you should be mounting root read-only `ro` for Not Fucking Up The Filesystem reasons, among other things.
another good idea is disabling the emergency shell and other emergency options, as that can lead to the initramfs
being compromised before the system boots (you don't want that!). this is a requirement if you are planning on doing
TPM-backed LUKS, as keys are released to the initramfs, and anyone can trigger an emergency.
```
ro lockdown=confidentiality nowatchdog rd.shell=0 rd.emergency=halt
```
### initramfs
ideally, you should be using dracut to generate a signed UKI, which you verify while the system
is offline, before each boot. this is unrealistic however, and a better solution would be to
use the TPM to implement some kind of [remote attestation](https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation).
i go over this in the [dracut-sshd-tpm section](#dracut-sshd-tpm).
#### hibernation
don't do hibernation. if you must, use a swapfile in the encrypted btrfs filesystem. archwiki has a
[guide](https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Acquire_swap_file_offset) on this.
#### sshd
if you want to unlock your LUKS partition over the network, i recommend
[dracut-sshd](https://github.com/gsauthof/dracut-sshd). it's Reasonably Secure and allows you to verify
that the initramfs hasn't been tampered with when used in conjunction with dracut-sshd-tpm:
##### dracut-sshd-tpm
i made a tool to extend dracut-sshd with TPM sealed host keys, effectively providing cryptographic remote
attestation with tools everyone has access to: just an ssh client.
[source code](https://git.slonk.ing/slonk/dracut-sshd-tpm)
it works because when your ssh client first connects to a host, it remembers it's host keys' hashes in the
`~/.ssh/known_hosts` file. whenever you connect to a host, it checks against that file and warns you if the key
is not recognized, and **errors out** when it has changed between connections. if you seal the keys with the
assistance of a TPM, you can set up rules for when the keys will be released to the initramfs. the keys still
have to be stored (in encrypted form) in the initramfs, because they wont fit in the TPM, only the AES keys will.
please note that this project is unfinished and still requires a lot of manual work to actually persist keys
across rebuilds. this is not a problem for confidentiality.
## secure boot
\
## init system
for auditability, you might want to use a minimal init system, but i highly recommend against this for a
desktop system. systemd is widely used and audited, with many security advantages such as isolation of processes
via namespaces, user services, and such.
## not covered (yet?)
- [systemd-homed](https://systemd.io/HOME_DIRECTORY/)
- probably a lot more