I can understand why people look for a "secure Linux setup" checklist. Checklists are comfortable. Turn on this setting, install this package, run these commands & now the machine is secure.
The problem is that the workstation still has to be used afterward.
My machine runs development tools, Git, local AI, Godot, Blender, browsers, command-line tools & temporary services. Locking everything down until none of that works would technically reduce some risk, but it would also make the workstation useless.
So I think the better question is: how do I keep a useful workstation without giving every tool more access than it actually needs?
A security system only matters if you can understand & maintain it while doing real work.
1. Start with what the machine actually does
A development workstation has a different risk profile than a kiosk or a server. Mine can contain source code, SSH keys, GitHub sessions, API tokens, local development servers & AI tools that can potentially execute commands.
That list tells me far more than the word "desktop."
This is a basic threat-modeling exercise. Threat modeling sounds formal, but the underlying idea is simple: what matters, what can reach it & what could realistically go wrong?
I am not trying to predict every possible attacker. I am trying to understand the system well enough that my controls match the way I actually use it.
2. Make updates routine instead of heroic
Outdated software can contain known vulnerabilities, but an update process that is so annoying I avoid it is not a very good control.
I want patching to be boring. Know where software comes from, update it through the correct mechanism & remove things I no longer use.
On Linux this can be more complicated than it sounds because software may come from the operating system, Flatpak, containers, language package managers, AppImages or manual installs. None of those is automatically wrong. The problem is forgetting which one owns the application.
If I cannot answer "how does this software receive updates?" that is something worth fixing.
3. Check what is listening
Attack surface is another term that sounds more complicated than it needs to be. It basically means the collection of places an attacker could potentially interact with your system.
A network service listening on an interface is one of those places.
Developer machines create these constantly. Test server. Model API. Debugger. Container port. SSH. Maybe I needed it yesterday. That does not mean I still need it today.
ss -tulpn
systemctl --type=service --state=running
systemctl --user --type=service --state=runningI am not running these commands because every listening service is dangerous. I am running them because I want to know what the machine is offering to the network.
If a service only needs the local machine, binding it to localhost can remove an unnecessary pathway without removing the service itself.
4. Your workstation may be valuable because of what it can unlock
People sometimes think, "There is nothing important on my computer." Maybe the files themselves are not particularly valuable.
But what is the computer logged into?
Email, GitHub, cloud dashboards, social accounts, password managers, development platforms & administrative systems can all turn the workstation into a collection of keys.
An attacker does not necessarily care about the machine. They may care about what the machine can reach.
That is why I treat credentials like infrastructure. Keep secrets out of source control, use strong authentication, scope tokens where possible & remove old credentials when the experiment that needed them is over.
5. The browser is probably one of the highest-value applications
It is easy to focus on the operating system & forget that the browser may already be authenticated to half of your digital life.
A malicious browser extension or stolen session can potentially bypass the need to steal a password because the browser is already authenticated.
I keep extensions limited & try not to install random one-off tools into the browser just because they are convenient. Higher-risk browsing & important administrative work do not always need to happen in the exact same context.
6. Developer tooling deserves real scrutiny
This is an area I think will become increasingly important. Modern developer tooling executes a lot of third-party code.
Package managers install dependencies. Build scripts run commands. IDE extensions can inspect large parts of a project. AI agents may read files, modify code & execute tools.
Most of this is legitimate & useful. The question is authority.
If I give a tool access to my home directory, shell, repository & credentials, I should understand what I am getting in exchange for that access.
Does this tool need the permission I am about to give it, or is the permission simply convenient?
7. Treat AI agents according to what they can do
I use AI-assisted development heavily. I do not think AI is inherently unsafe, but calling everything an "AI assistant" can hide huge differences in capability.
One assistant only sees the text I paste into a conversation. Another can read my repository. Another can modify files. Another can execute shell commands or push to GitHub.
Those are not equivalent trust decisions.
Once the AI can take actions, I treat it more like infrastructure. Scope access, use version control, review changes & keep important operations recoverable.
8. A firewall is useful, but it is not a magic shield
A host firewall can restrict unwanted network traffic, which is useful. It can also create a false sense of security if I stop thinking about the services behind it.
I want both layers to make sense. The service should bind appropriately & the firewall should enforce the network policy I actually intend.
Layered security works because one control can catch a mistake in another control. It does not mean piling random products on top of each other.
9. Recovery is part of the security model
Imagine two identical machines are compromised. One contains the only copy of months of work. The other has version-controlled projects, tested backups & a documented rebuild path.
The compromise is bad in both cases. The impact is very different.
That is why I consider backups, Git & reproducibility security controls. They reduce how much leverage a failure, ransomware event, hardware problem or bad configuration has over me.
10. Learn what normal looks like
I think one of the best security improvements is simply becoming less afraid of inspecting the system.
Look at processes. Look at logs. Look at listening ports. Look at failed services. Look at disk usage. Learn where configuration lives.
You do not need to memorize every process name. You are building familiarity.
If I know roughly what normal looks like, unusual behavior has a better chance of looking unusual.
11. Do not build security that depends on never making a mistake
Humans make mistakes. I make mistakes. Security professionals make mistakes.
A useful system expects that reality. Git lets me recover code. Backups let me recover data. Limited privileges reduce the effect of a bad command. Segmentation can limit where a compromised machine can go.
The goal is not to become perfect. The goal is to make individual mistakes less capable of becoming catastrophic.
The workstation should stay understandable
My baseline is deliberately simple: keep the machine updated, know where software comes from, minimize unnecessary exposure, protect credentials, be careful with developer tooling, maintain recovery options & inspect the system often enough that it does not become mysterious.
I would rather have a smaller set of controls I understand & consistently maintain than a pile of security software I cannot explain.
The workstation is a working system. The security model has to survive actual work.
And when something fails, document it. That failure is now part of the next version of the system.