Desktop Linux Hardening (2022)
privsec.dev
privsec.dev
Since then, I’m simply “ignorant” and sane - use it, update it regularly, use official software sources (so official distros repos and Flatpaks), FDE, SecureBoot, do not run random net stuff (like scripts, “Git” etc.), try to stay as default as possible and use a VM to experiment if I really need to.
I am curious - how many of you regular desktop Linux users actually had security issues (or at least suspected something shady)?
Even if something sneaks into a distro package it's possible to convince the distro package maintainer to disable it, because the maintainer's interests are aligned with you and not upstream.
Distros already share effort implicitly because maintainers of distro X often look at what distro Y is doing for that package. Also users compare distros frequently and will tell the maintainer of distro X that the same thing works with distro Y.
2. The Audacity flatpak is maintained by a Flathub dev only because Audacity upstream has not expressed an interest in maintaining it themselves, not because of some Flathub policy to reject telemetry etc. If they wanted to maintain the flatpak themselves they would be allowed to do that, since Flathub policy is to have upstream developers maintain their flatpaks. And that would lead to the problem I mentioned.
> We also are not trying to force you to install updates before you can keep using Firefox. Firefox's update mechanism downloads updates while it is running and installs them at startup. ... In the case of Bug 1705217, the package manager updates Firefox's files on its own schedule that is outside of Firefox's control ... Firefox had no intention of forcing updates to be installed at an inconvenient time.
That's because upstream Firefox separates out downloading and applying the update.
Correct. Because you installed the update.
>That's because upstream Firefox separates out downloading and applying the update.
Correct. And that's what I'm telling you to do with your package manager as well.
Please inform me how to automatically have my distro package manager download updates and install them on the next open. Note that it's critical here that the install is perceptively instant: it means I'm never waiting for my browser to be available.
You asserted that was not the case, so I asked you to prove it. If you don't want to you don't have to, but I'll assume you admit that the distro package manager is in fact inferior.
Man, half of the cool tools want me to do this
curl cool-company.io | shcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
At least it does not require sudo (unless that's buried in the script.)
When I need to run a program from a dev I don't fully trust to behave well (e.g. the app is closed source for no particular reason, has known extensive telemetry, or has an unhealthy tendency to fuck with configuration files), I run it in a firejail, container, or reboot to windows.
For everything else I fancy the thought that everything I install being open source and looked at by multiple people including a package maintainer means that there's a significantly lower chance of easily exploitable vulnerabilities (e.g. in system config and general program behaviour), and an almost nonexistent chance of outright malicious code.
See https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a... , the bit "then auto volume decryption on your next reboot will fail". This makes sense.
I unlock encrypted partitions with a passphrase, not TPM.
Once the work described at https://lwn.net/Articles/918909/ this will change, and , and kernel updates should no longer require will (hopefully?) no longer require re-initializing the TPM.
An entirely different matter is that the default Microsoft keys allow running all other distros, with their GRUB which allows to load initrds without authentication - which would allow evil-made style attacks by replacing the whole boot chain and the kernel. So in my world, all builds of Shim and GRUB are malware, and keys that allow booting them are not allowed in the DB.
I never ever, never once had any security issue. I never had an issue with malware being installed. I never had an issue with external malicious users accessing my system - not even DDOSing my network.
In fact, I have run Windows as well since version 3.1, and DOS before that, and I've never had a virus or malware on Windows, either. Not a single compromise or glitch at all.
Once, I was a guest at a friend's house and I discovered that he had fallen victim to some sort of replicating virus on his Windows 98 system. I was able to manually eradicate it for him, without resorting to commercial anti-virus software.
A few weeks ago, I did discover that my home router had been compromised and some sort of malicious DNS service had been installed on it. So, I must confess to my first-ever home network compromise, albeit an embedded router OS I had little control over.
Replace Linux with OSX or even Windows in this statement and i wouldn't expect crazily different results from a crowd that follows the best practices you outlined.
What things do I need to worry about? I'm about to make the switch from Windows to Linux.
Is it general 'dont run things you don't trust'? keep things updated? Use good passwords?(do I need to change a setting to prevent brute forcing?)
Am I missing anything?
If you use a mainstream distro like Fedora or Ubuntu, its default configuration should be safe enough to use like Windows. Just remember that there isn't really any antivirus or Microsoft Defender to save you if you really mess up. I do offline backups of important work on all my devices, for this reason partially.
Can you explain this? What are the exploits?
Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? (Or am I trying to shove my windows ideas into linux?)
Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). This works really well for old apps (and admittedly not too bad for new ones) but is very slow and exposes a lot of bugs. On top of this, you have potential exploits in your filesystem from loosely permissioning important settings and identity files. So, the attack surface for a traditional Linux distro is relatively large.
> Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection?
Kinda! Linux software is distributed as packages, which contains a binary (the exe/jar portion), a dependency manifest and whatever static content it needs. A sandbox like Flatpak will take those packages and put it into a sandbox, to prevent hostile interprocess communication and filesystem exploits.
None of these mitigations are perfect per-se (nor are they on Mac/Windows), so use them wisely if you intend to use them at all. I have used a non-sandboxed system to run old 90s Windows games for years though, and haven't picked up any significant issues. YMMV, it is Linux after all :P
Oh gosh. I'm getting heart palpitations :P
Is this a common attack vector then? Seems like an easy way to get an overflow error, or elevate privilege's.
Sandbox comes with a heavy usability price, so they are lax by default.
For example you protect your files, but then you can't load your photos to facebook because your browser doesn't have access.
There are some tradeoffs though. Some things like screen sharing might be worse on Wayland (e.g. I can't share a single window, only whole screens) and some apps don't support Wayland at all (including for example all of the IntelliJ IDEs). The latter can be circumvented by enabling XWayland (basically an X server running side by side with the Wayland compositor to handle X11-only apps). In that case you're left with the X11 security model for apps not running natively on Wayland.
I just like to bring that up even though it's not a common use case, because that's what keeps me from using Wayland.
Not sure what you're referring to. I'm using wayland and I can open multiple desktops via gdm.
It's a pretty elegant setup, honestly, and one thing I miss when I'm on Wayland. The idea is you're at a small desktop on your University's network and you need to use some of the computing power of the big data servers they have. So you run e.g. a graphing program that does all of its computation on the big data machine but does its display on your little desktop (in this setup the big data machine is called the "client" and the tiny little desktop is called the "server" which confuses people a lot at first but makes sense when you get into the architecture).
X itself had been moving away from this for years by adding some extensions that don't work well (or at all) over the network, but there are absolutely still lab setups that use the old way because it's pretty much tailor-made for it.
The bigger security issue was that X programs could see and modify certain things about each other and about the system as a whole, so for example the program XEyes had a pair of eyes that pointed at the location of the cursor (it sounds silly but this was an accessibility thing). And a screenshot program could take a shot of the screen. And so on. Wayland got rid of all those capabilities, but there turned out to be a lot of baby in that bathwater so they're slowly adding back each of them, one at a time. In another decade a new crop of developers will no doubt say "What's all this needless cruft?! Let's start over!" and the cycle of life will continue.
Obligatory XKCD: https://xkcd.com/1200/
Or, if you are truly paranoid... just create another Unix user for sensible web browsing and log in with that account:
useradd -m webcare
passwd webcare
I always read the script and do also verify they're only using ASCII chars (and if they're not, I check which Unicode shenanigan is ongoing).
For example:
... $ file /usr/local/bin/somescript.sh
/usr/local/bin/somescript.sh: Bourne-Again shell script, ASCII text executable
I haven't encountered this. You can execute scripts intentionally in vi, and I assume you could configure it to happen automatically, but can this happen without you making some sort of effort to enable it?
What scripts present such a risk? What vi configuration is required to stop this?
Same question wrt cat.
I'm not a VIP, but I have some huge huge huge secrets that are worth at least a million dollars, maybe 10s of millions of dollars, that I need to access with a computer.
Malware means potentially losing millions or tens of millions of dollars. I'm so afraid of those secrets, I don't even access them on my windows computers unless necessary.
I'd love to be comfortable doing this, but given anyone can seemingly make a python keylogger, I'm not really comfortable using my computer(windows or linux) for this purpose. Gaming/updating my website/etc... all of that, who cares if I'm hacked, I got backups. I just havent found a great way to keep secrets that need to go online.
Nowadays, the web browser is used as a platform to run programs on and so it has a lot of access to weird things (multiple monitors, local filesystem, ...) so one has to be careful what you enable there--since you probably run a lot of Javascript written by shady people you don't know.
The Linux desktop security model has user accounts, and then files have permissions for those users (yeah, there are also user groups, whatever). That means if you have a misbehaving (or malicious) program, it can read stuff in your home directory since that's owned by the same user account--so it can read your saved passwords, delete all your photos, figure out your banking info--but hey, at least it can't remove your printer (since for the latter you need to use the root user account :P) /s .
There are mitigations against that and the easiest (and crappiest) one is containerization: just run each program in an isolated virtual-machine-like-thing and they can't access other program's data (i.e. the rest of YOUR data) in the first place.
Then there's SELinux which flips this entire thing on its head. By default, nobody can do anything (that's the first very good decision!). If a process wants to do things, there has to be a policy installed that mentions that specific thing to be allowed and when. Otherwise no go. This way of working is much safer, BUT someone has to maintain those policies! And it must not be the program's author since he could just add whatever line he wants to have to the policy--and that's obviously bad. So who does it? Usually the Linux distribution's maintainer. Or, more commonly, nobody--so there's no policy for your favorite program and so it won't work.
which can totally happen on a VM, but not a VM in-and-of-itself
https://en.wikipedia.org/wiki/OS-level_virtualization
Good to know about it. Especially once you meet decades-experienced folks (mainframe guys), they rather use the word "virtualization" in its broader sense, yet they understand the difference between containers and virtual machines.
https://www.ibm.com/cloud/blog/containers-vs-vms#:~:text=Con....
Carnegie Melon University chimes in as well:
https://insights.sei.cmu.edu/blog/virtualization-via-contain...
Amazon AWS:
is container virtualization
Well, if you rent containers, you get containers. If you rent bare-metal machines, you get bare metal machines. So I don't see how this assertion makes any sense.
The CMU article skims around the names but call containers "virtual runtime environment" instead of straight "virtualization". But by that definition everything in any modern computer is "virtualized" because it runs over Virtual Memory.
It's not easy. Just getting the mounts right is not sufficient. You also need to consider syscalls. E.g. TIOCSTI is permitted by default and allows an easy sandbox escape. See [0]CVE-2017-5226. TIOCLINUX can also allow sandbox escapes.
This can be prevented with the --new-session option, but that breaks interactive terminals, e.g. it causes ctrl-C to restore input to the parent shell while simultaneously running the child shell on the same terminal with the same inputs, which makes it unusable.
The alternative is compiling a seccomp BPF program to filter the syscalls, and loading it with the --seccomp option, but even this is non-trivial, e.g. see [1]CVE-2019-10063. This is also a case of "enumerating badness"; there's no guarantee that other syscalls are not also exploitable.
I've noticed a trend of adding N deeply intertwined features which then interact in N! different ways and no one bothers to define rigorous semantics for them. And then you have to get a PhD in Linux just to understand whether your system is vulnerable when you use POSIX message queues inside a FUSE filesystem inside an unprivileged user namespace inside chroot inside setarch running in 9 nested terminal sessions.
I think I'm starting to understand why some people swear by the BSDs.
Edit: just checked and OpenBSD has indeed removed TIOCSTI in 2017.
0% design and 100% scratch-my-itch tack on another feature.
Sandboxing a program that needs graphics performance anywhere near 10% of what the hardware is capable of is, at the moment, as we're stuck with X11 and growing gray hair waiting for Wayland to become a viable alternative, literally impossible.
Firejail does provide pre-made solutions like running nested X servers, which can sandbox graphical applications at insane resource costs, such that you might as well just run a full virtual machine.
Mount namespaces are security theater if you're giving access to X11, Pipewire, the SSH agent, the GPG agent, the dbus session bus, and god knows what else.
All you need to do is share the compositors socket and /dev/dri with the "container" and it "just works" for me!
I do not have xwayland enabled either, all of the software I use is wayland native!
So I think there is value in recommending such articles to everyone interested, as it would open them to understanding attack/leak vectors and be aware of those. The fallacy that anything that isn't Windows is safe needs to come with a caveat that blind trust with the basic security policies can lead to disaster.
Anyone can say what they want about chromeOS not being a real OS (I disagree, that's off-topic), but it was built to be secure-by-default -- at least with regard to basically everything in this article.
Even with a stock, up-to-date linux kernel (I use arch BTW), there are a ton of gotchas, such as the fact that lockdown mode disables hibernate (!)-- I needed to patch the kernel to tell it I know better (there are some good LWN articles on why they did it, it's cause there are far too many gotchas):
https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1...
Chromebook on Framework actually seems like a great value prop in this regard, but of course you have to sell your metadata to big G.
1. The laptop to sleep
2. After some time, it'll hibernate so it doesn't drain the entire battery over the weekend
3. When I fire it up on monday, whatever I was working on is still there.
It's hard to do this without hibernate (or a _really_ efficient sleep).
You actually have to configure sleep-then-hibernate on systemd for this to work right. Again, I still think chromeOS is the future of the linux desktop (again, if you don't mind Google watching over).
Sigh you people...
https://support.google.com/chromebook/answer/9145439?hl=en
It runs a VM that runs LXC on it, and by default installs a debian container you get root to. They also created a X11/wayland bridge so that graphical apps work, even 3d acceleration to some degree, as well as volume mounts from the host, and USB passthrough.
I was able to use OpenSCAD on it.
You can even install containers of your choice, e.g.: https://wiki.archlinux.org/title/Chrome_OS_devices/Crostini
You get a full linux container inside your secure Chrome OS, the main limitation being that you have to use whatever kernel their presumably signed VM uses. All this without needing to disable secure boot or booting into a "developer" mode or whatever.
Essentially, anyone with access to Google's web servers and physical access to your hardware can just unlock and decrypt your device.
The first one allows me to almost never type in my local password (and use a 7-word diceware that is impractical to bruteforce). This should prevent many local privilege escalation scenarios by things like shitty npm packages. I used a trivial password for years because it was tiresome to type in dozens of times a day. Now I just type `sudo -i` and tap the hardware key. (I already use containers and firejail to prevent them from accessing my personal files, so this only leaves zero days).
https://wiki.archlinux.org/title/Universal_2nd_Factor
The second one provides a second factor for my SSH keys that makes them completely useless without a corresponding hardware key. You need OpenSSH 8.2 or later on both sides. `ssh 1.2.3.4` and tap the key (or `ssh-add` it to the key agent — but it's less secure).
https://gist.github.com/Kranzes/be4fffba5da3799ee93134dc68a4...
https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...
Personally, I could only see the security benefit if the hardware key and the laptop are stored separately — if e.g. a three-letter agency robbed my house, they'd get both anyway. But that's entirely impractical if the HSK is used for every PAM auth, rather than just to do "special" actions (in the way that e.g. hardware crypto wallets are used.)
But someone can, in theory, break that software from multiple timezones away
(Also FYI, this is why Apple cryptographically "pairs" device fingerprint readers to their TPMs, such that you can't just replace them without having Apple "activate" the new one. It's so that bad actors who acquire your laptop can't just quickly swap out the fingerprint reader for one that always puts "good fingerprint, please unlock" on the signal line.)
Apple borrowed the cryptographic pairing system they created for security in the fingerprint reader, and reused it for the display et al, to make stealing iPhones to scrap them for parts pointless. This has massively decreased the value of these phones on the black market (all you can really extract now are the low-value bits like the speaker or charging assembly); which has in turn made iPhones the least desirable target for thieves.
Every hurdle you have to jump to take part in Apple’s self-serve repair program — the “phone Apple to activate the pairing of these parts” step, the only being able to order parts once you have a specific broken device to order them for, etc. — is the way it is precisely so that the people who scrap the stolen phones can’t participate.
FIDO keys are already here and can also be used for web authentication (which is their main use case. this is just a nice add-on).
They can also be used to conveniently unlock LUKS volumes which I completely forgot about since I'm not using LUKS:
http://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-f...
Are users expected to search for hardening guides, spend time learn all these pieces and implement them securely? Even the system administrators may not know tools such as SeLinux, let alone the end users. It takes a lot of time to learn write SeLinux or AppArmor policies.
We need an operating system that is already hardened, preconfigured with secure defaults, and can be a daily driver. It should not need the user “harden” it.
I don’t mean OpenBSD: it’s secure because it doesn’t enable much.
If you want it easy for the average joe, it's going to be measurably more insecure. If you want it secure, it's going to be barebones by virtue of intentionally having reduced attack surface. That's just how it goes. Unfortunately, I will concede that default Linux is in an awkward spot of being too insecure to be considered "secure enough", and too difficult for newbies to configure properly.
It'll look like macOS does out-of-the-box. I think everybody here who's not already on macOS hates that, judging from what people post about it. Even though you can disable most of that stuff if you need to.
Probably nigh-impossible to get such a thing working with decent UX all the way up through the GUI layer, on Linux. Too fragmented. The pieces are there, but no-one can say "THIS is how it works". I think we're stuck with the current situation, until/unless RedHat decides to create & push something for this that further cements their control over the Linux userspace (which... yeah, that actually might happen, and it'll probably be pretty bad because they seem to have really poor taste when it comes to software design, but we'll all end up stuck with it regardless). Maybe we'll see most distros shipping and enabling "systemd-security" when RH gets around to making it, and ensures that Gnome is extremely hard to package without it.
It will take some flexibility from the user, and might annoy the user with permission approvals, but that’s what is needed.
I’m surprised that there are so many similar distributions, yet a secure MacOS-like distribution doesn’t exist.
And besides, the whole community is built on user freedom and security-for-everyone can sometimes get in the way of that goal.
There are Linux distros that do this.
> It should not need the user “harden” it.
Well, the problem is that the more hardened a system is, the more of a pain in the butt the system is to use. Most people (even those who are security-minded) don't want to use a fully "hardened" system, at least as a daily driver.
That may be true for Linux, but I think macOS proves that it can be done.
(Also, MacOS is really BSD, isn't it? So there's not a million miles between that and Linux, security-wise.)
FWIW, macOS is my daily driver, and the last security-related hassle I can remember was related to installing an iSCSI kernel extension. IIRC it added 5-10 minutes to the task.
> (Also, MacOS is really BSD, isn't it? So there's not a million miles between that and Linux, security-wise.)
I wouldn't think so, but my Linux knowledge is shallow enough that I wish there were a secure-by-default Linux distribution that I could safely recommend to neophytes.
There are probably quite a few security-related hassles that you encounter every day, but you're just used to them and they don't bother you.
Which is totally fair. In practice, the most intuitive and easy-to-use systems tend to be the ones we have used for long enough that they are second-nature.
> I wish there were a secure-by-default Linux distribution that I could safely recommend to neophytes.
There very likely is such a thing, honestly. But for the average user, the most popular distros are very likely "secure enough", especially if Windows-level security is considered acceptable.
Otherwise, I'd say forget about trying to secure Linux and just go with QubesOS unless you need 3D graphics acceleration
Edit: QubesOS allows you to run at least some conventional brands of Linux out of the box, but it allows memory efficient VM isolation between them, and some other really cool features, overall making securing stuff much simpler than installing a bunch of of random tools from different parties
It also provides a better way to communicate between VMs through simple RPC commands rather than hoping USB device drivers are not malicious
In terms of maintenance, I'm pretty sure you could have only one templateVM for everything, which means you only have to update dom0 and that templateVM. So in terms of maintenance thats really not that much more I guess?
I think I might try that myself actually
If you need persistence in the root filesystem, that could mean a standalone VM or a new VM. Last I tried I had trouble with their AppVM solution on that
Accusations have been made about them and by them regarding other privacy advocates. None of that has anything to do with the quality of the post, but all sides of that drama seem to be very stubborn and immature when it comes to criticism which is a red flag in my book and takes all credibility away from them and suggestion they would make.
Quite frankly, anyone looking at that subreddit will know that it's just a bunch of incompetent and incoherent rambling from a few guys with quite literally no technical understanding. They been doing this for years now, spreading terrible privacy and security advice and spearing developers with these cheap shots when they cannot argue on the technical front.
PrivSec is not a part of either PrivacyGuides or GrapheneOS. I am currently a moderator on GrapheneOS, and have not been associated with PrivacyGuides for almost a year now.
Everything mentioned here should be attainable in any Linux distro.
Linux is like Firefox. Just like how Firefox comes with Google as the default search engine and other bad defaults. It is also the most configurable browser when it comes providing privacy to end users. Linux defaults sucks. But it is also the most configurable when it comes to security.
And anyone recommending ChromeOS or MacOS are trading off privacy for security. Especially if you are recommending ChromeOS. Motivation and agenda > technical merit. Linux provides a good balance here.
These cause a 10%-20% performance drop and I see no reason to enable them on a desktop. They can be turned off using mitigations=off on your grub command line.
Anyway, modern chips have hardware fixes, these microcode updates and kernel retpolines etc. should be less impactful if your CPU was made post-meltdown.
Converting random bits into meaningful data would seem to be the sticky point.
The most impressive was a local exploit for spectre which on certain kernel versions could leak /etc/shadow, and a similar one for windows that sometimes could leak a ntlm hash for local admin user. Both were from a commercial pentesting software company.
There’s claims of more impressive ones in academia, but no fucker in academia is sharing their code as usual.
Firejail is a setuid binary with tons of attack surface and has had a number of privescs itself[1], unlike something like the lower-level Bubblewrap tool.
I'm glad it exists, though - it's the only mature solution other than Flatpak that has proper dbus filtering, among other things.
[1]: https://www.cvedetails.com/vulnerability-list/vendor_id-1619...
Therein lies IMO the biggest problem with application security on desktop Linux. Just like selinux, apparmor and other similar security tools *someone* has to globally deny access to permissions, break things in the process and find the minimum number of permissions required for the app to function.
Many users are not going to do this and (lazy or uninterested?) developers (package maintainers?) don't want to do that work either.
Couldn’t package managers install and enforce such policies?
The article itself starts off much more focused on privacy than on security though it does have a fair bit of content on both topics.
If you have a live CD and enough spare disk space, you can create a new LUKS partition and dd / filesystem-specific-backup-restore your existing partition into it. You don't have to backup and reinstall.
If you're already using systemd-gpt-auto-generator to auto-detect the root partition, you just have to make sure the new partition has the expected UUID. Depending on your setup you might have to regenerate the initramfs though, say because it didn't already contain `/usr/bin/cryptsetup` etc.
>openSUSE uses a unique ID to count systems, which can be disabled by deleting the /var/lib/zypp/AnonymousUniqueId file.
Deleting it will not help since it'll get recreated by the next command that needs it. Empty it instead.
>Encrypted /boot [...]
>- openSUSE uses LUKS1 instead of LUKS2 for encryption.
>- GRUB supports PBKDF2 key derivation only, not Argon2 (the LUKS2 default).
Yes, the first point is because of the second point. There isn't a security difference between LUKS1 and 2 when using PBKDF2, so sticking with LUKS1 means you can't accidentally switch to non-PBKDF2 and end up with an unbootable system. But yes, switching away from grub as the next point talks about is ideal. And if you switch to UEFI boot with UKIs in /efi then you won't need a separate encrypted /boot anyway.
Interesting. Are you sure about this? The Wiki says it can be deleted and I did not see it coming back during my time with openSUSE. I can check it again later though.
It's also covered in https://forums.opensuse.org/t/zypper-uuid/135752
cryptsetup reencrypt --encrypt -q --header /some/where/file /dev/mydev
cryptsetup reencrypt --decrypt -q --header /some/where/file /dev/mydev
I haven't looked into it but it might be possible to convert a non crypted disk to a cyrpted one.
Your privacy is already secured for the most part and keeps your work and personal stuff separate.
It is what i use to ensure that Firefox is started with empty data cache/file-store but populated with bookmarks.
There's also qubsd which is a qubes like thing for Freebsd, leveraging zfs, jails and bhyve. Looks really promising, but is still in a lot of dev flux. Definitely gonna switch to it when it's solid enough though. Because it looks like a better way to set up your own custom qubes-like setup.
I like Qubes quite a lot. But there's still a lot of friction if you're doing anything not supported by default.
If I'm going to use memory that I don't have as swap, I might as well just use no swap and take the OOM if I use too much memory.
I remember having issues with system starvation if it started to make excessive use of zram but that has been pretty much levitated with the introduction of MGLRU.
Who/what are you protecting against? Without a clear answer to that, you're probably wasting your time.
And check out Bruce Schneier for intelligent advice. https://www.schneier.com/
Once you know how it is a small investment of time to compile a custom kernel with everything you don't use disabled.
On any modern machine, just disable swap. It's not useful unless you want to suspend on mobile.
https://chrisdown.name/2019/07/18/linux-memory-management-at...
https://haydenjames.io/linux-performance-almost-always-add-s...
Err, you mean every rack-mount system since around 2000s? Seriously, the commissioning overhead for virtually anything exceeds the "max out the ram" tax. Unless you're a cloud provider commissioning autonomously and operating at excessive scale seeking some particular unit cost optimization ... and even then not maxing out RAM (to some current definition of effective price:performance maxima) would be odd.
Having timely zero-effort updates from distros is far, far more valuable for security than the reduction of attack surface from custom kernel.
...at the same time I'm annoyed by the lack of quality and care in most products. Security products having pre-auth RCEs and other dumb things are really annoying.
I also recommend manually reading/checking the the BIOS EEPROM and re-installing the OS from scratch at least every 6 months. This should mostly eliminate most of the advanced threats.
You can setup an ansible script to re-install everything so it can automated.
Honestly, an immutable OS would be more ideal but it isn’t very realistic. If you are adventurous, it would also be possible to setup a system where host image gets rebuild every night and persistent data gets pulled from a git repo.