# Rate my desktop linux security setup **URL:** https://discuss.privacyguides.net/t/rate-my-desktop-linux-security-setup/22423 **Category:** General **Tags:** software **Created:** 2024-11-14T16:40:30Z **Posts:** 35 ## Post 1 by @asanyan — 2024-11-14T16:40:30Z Over the last few months I’ve been trying to improve my security setup so I thought I’d share the measures I’m currently taking and ask for feedback. Please tell me if I’m doing something stupid or missing something. (Warning: wall of text) Security measures: - Compile the kernel, with CFI, full LTO, hardened patches (when up to date), and only the required modules (~250). - Hardened boot parameters, sysctls, (mostly) in accordance to madaidan and privsec’s guides. Misc hardening like enabling NTS, hardened mountpoints, hidepid, disabling coredumps etc. also done. Read permissions to non-root users in some top-level directories like /usr/src and /usr/lib/modules are removed. - Hardened malloc (light) is preloaded for system apps, and disabled with bwrap in firefox and gaming sandboxes for increased performance. - I use roddhjav’s apparmor profiles for securing most things on the system. As of the time of writing, I only have 17 binaries running unconfined, and these are things like the shell, the terminal emulator, systemd, crond, and other programs used for administration purposes and that need near full rights to the system. - I use bubblejail for sandboxing apps. Most apps play well in a sandbox and work flawlessly; an exception is the web browser that I use for video calls, because my webcam sucks and if it disconnects, due to how bwrap works I need to restart the sandbox to fix it. For these cases, I rely on apparmor and intgr’s ego for user separation. Apparmor still works with bubblejail too, restricting some read access to top-level directories (bubblejail allows full read access to things like /usr and /opt). I take care to allow userns for web browsers, other programs have this functionality restricted. - I have firejail installed as it restricts some simple programs that I wouldn’t bother setting up a sandbox for normally, e.g. ping, man, lynx. - As WINE still requires X to run most games in a performant way, I take care as to never run any X11 app unsandboxed, as that would allow for a sandbox escape. My terminal emulator of choice (foot) is wayland-only. - I use Hyprland as the wayland compositor. It may not be the objectively best choice, however it does implement the security context wayland protocol now. - Mullvad is my VPN provider of choice. I take care to run browser sandboxes that need to know my identity with mullvad-exclude. - As a password manager, I use pass with wtype for auto-typing functionality rather than copy and paste. - Root partition is encrypted with LUKS. TCB and security flaws with the setup: - Everything that runs as my user (wheel) without sandboxing or a restrictive MAC policy is trusted. To avoid hassle, I also have polkit rule to always return yes to wheel users, and sudo is passwordless, so wheel == root pretty much. I don’t think it’s an issue unless I allow my sandboxes to communicate with the polkit dbus (which I don’t). - Most programs still use pulseaudio which is bad, though I prefer passing pipewire or alsa (via pw-alsa) to sandboxes when possible. I unplug the microphone when not in use. X11 is also a problem but hopefully not that big of a deal as I don’t ever run X apps unsandboxed. I’d prefer having a separate X server per-app but it seems hard. - Hardware is trusted, and since I drive old hardware, I don’t bother with things like secure boot. I enable iommu but it’s kinda moot as I hardly ever unplug my USB devices. - I’m yet to setup a firewall and network isolation for sandboxes (I tried before but it breaks stuff). - I’m yet to remove SUID from binaries that don’t require it. - I sometimes compile programs from the AUR, which could compromise my system if the app is malicious. I usually prefer binary releases to avoid this problem though. - Sometimes I boot with kernel mitigations disabled to play games (very old cpu, 30% performance hit), but I take care to not open any sensitive files or apps, and reboot before engaging in normal desktop use. --- ## Post 2 by @realguyman — 2024-11-14T22:44:29Z Rather comical putting in so much effort to secure your kernel, only to skip [Secure Boot](https://en.wikipedia.org/wiki/UEFI#Secure_Boot), enabling the potential for [bootkits](https://en.wikipedia.org/wiki/Rootkit#Bootkits). Secure Boot is not just for protecting against [Evil Maid Attacks](https://en.wikipedia.org/wiki/Evil_maid_attack). It’s used to ensure your kernel hasn’t been tampered (via kernel module signing and kernel image signing) along with asserting your boot procedure hasn’t been tampered with. Given the level of customization you have opted for, I’m genuinely surprised you chose Arch over Gentoo. Be careful, what you don’t know, could bite you. I’m not going to bother rating your “secure operating system”. I will only exercise caution to everyone that sometimes (actually, a lot of the time), it’s just better to choose an operating system with sane defaults that will be good enough for most people, such as [Fedora Workstation](https://fedoraproject.org/workstation/). --- ## Post 3 by @asanyan — 2024-11-14T22:53:49Z > [@realguyman](#): > > [bootkits](https://en.wikipedia.org/wiki/Rootkit#Bootkits) AFAIK there’s no way for me to fully protect against those either way beecause I’m running hardware that is 8~10 years old. Secure boot would patch some of the holes but not all of them. > [@realguyman](#): > > Be careful, what you don’t know, could bite you Certainly. Hence the thread. --- ## Post 4 by @overdrawn98901 — 2024-11-14T23:15:15Z Just wanted to pop in and say I always super appreciate links to resources and definitions in a post. Let’s anyone deep dive in the topic without too much derailment. --- ## Post 5 by @Cyber-Typhoon — 2025-06-27T21:54:15Z > [@asanyan](#): > > I use bubblejail for sandboxing apps. Most apps play well in a sandbox and work flawlessly; an exception is the web browser that I use for video calls Hey, nice build, did you only noticed issues in video calls with the webcam using web browsers with bubblejail? I wonder if I should or not adopt bubblejail for web browser distro maintained installation. --- ## Post 6 by @anonymous363 — 2025-06-27T22:27:25Z _Grade:_ B- _Things to improve:_ implement a firewall, remove unnecessary SUID binaries, avoid kernel mitigation toggling, and enhance network isolation. --- ## Post 7 by @anonymous364 — 2025-06-27T22:35:11Z plz giv rubrick --- ## Post 8 by @anonymous363 — 2025-06-27T22:38:36Z Grade was based on kernel hardening, sandboxing effectiveness, user permissions, network isolation, and overall system configuration security. Based on the info provided. --- ## Post 9 by @anonymous364 — 2025-06-27T22:40:04Z but how, what is the break downn score? what do i do if i want an A+? --- ## Post 10 by @anonymous363 — 2025-06-27T22:41:27Z Honestly the grade itself is subjective. It has to be as it would not be possible to deep dive into OPs system to get a more objective look. > [@anonymous363](#): > > _Things to improve:_ implement a firewall, remove unnecessary SUID binaries, avoid kernel mitigation toggling, and enhance network isolation. Would improve the grade. --- ## Post 11 by @asanyan — 2025-06-28T00:30:33Z Yeah, no other issues. --- ## Post 12 by @anon63378630 — 2025-06-28T00:32:01Z > [@asanyan](#): > > Hardened malloc (light) is preloaded Why? Just use the standard variant please --- ## Post 13 by @rundfunk — 2025-06-29T19:05:52Z # — Missing 1. fapolicyd 2. TPM 2.x (The combination Secure Boot and TPM 2.x is maximum security.) 3. Secure Boot 4. ClamAV + YARA rules. 5. UEFI Bios Password 6. run0 [https://www.freedesktop.org/software/systemd/man/devel/run0.html](https://www.freedesktop.org/software/systemd/man/devel/run0.html) # — Stupid 1. No firewall. You need a whitelist firewall - control what is allowed to go out and what is allowed to go in. 2. No Secure Boot. SB is a security protocol and protects your firmwares and OS and many other things. On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled if the system boots in EFI Secure Boot mode. > **[kernel_lockdown(7) — manpages — Debian bullseye — Debian Manpages](https://manpages.debian.org/bullseye/manpages/kernel_lockdown.7.en.html)** --- ## Post 14 by @rundfunk — 2025-06-29T19:29:20Z > [@anonymous364](#): > > What do i do if i want an A+? # Nested Virtualization A VM (virtual machine) is running inside a VM. And the GUEST VM cannot communicate with the HOST VM. It is impossible to attack a hardened Nested Virtualization - this is A+ or A++. This is maximum security. HOST OS → GUEST OS VM 1 → GUEST OS VM 2 → www If GUEST OS VM 2 is temporary / disposable it is a A+++ --- ## Post 15 by @anon63378630 — 2025-06-29T19:36:28Z > [@rundfunk](#): > > It is impossible to attack a hardened Nested Virtualization - not really > [@rundfunk](#): > > HOST OS → GUEST OS VM 1 → GUEST OS VM 2 → www the second VM doesn’t actually run inside of the first VM instead the host OS and both VMs each run in a different context of the CPU additionally issues like Spectre make it possible to leak across this boundary there could be _some_ benefits of nested virtualization, BUT there is a big caveat here. basically if the paravirt drivers were exploited to escape the second VM, the first VM would be compromised, but if you’re likely running the same hypvervisor for both, it could just repeat such attack and gain host access. --- ## Post 16 by @rundfunk — 2025-06-29T20:28:21Z > [@anon63378630](#): > > Additionally issues like Spectre make it possible to leak across this boundary. [QEMU Documentation](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) > In general all of these features are included if using “Host Passthrough” or “Host Model”. > pcid, spec-ctrl, stibp, ssbd, pdpe1gb, md-clear, mds-no, taa-no, tsx-ctrl, bhi-no, gds-no, rfds-no. Not all CPU vulnerabilities are addressed, but many. --- ## Post 17 by @anonymous261 — 2025-06-29T21:08:47Z I would think anything close to an A+ would have to just be GrapheneOS desktop mode --- ## Post 18 by @rundfunk — 2025-06-29T21:19:44Z Some info for all: Privacy has a fundament in the computer world: Security. - No matter what you do a VM is the strongest isolation / protection. No sandbox can keep up. - You can remove the virtual network driver and your VM is in one second an Offline Air Gap. - With Bridged Networking you can disable HOST OS networking and allow it only for your VMs. - It’s all so easy to set up that even kids can do it. --- ## Post 19 by @anonymous261 — 2025-06-29T21:29:36Z > [@rundfunk](#): > > No matter what you do a VM is the strongest isolation / protection I’m not sure I agree, separate computers can have some security perks over VMs. Also: > [@Consider adding a virtualization overview](https://discuss.privacyguides.net/t/consider-adding-a-virtualization-overview/520/6): > > I think I agree. Honestly I’m not sure a VM-heavy workflow is the right approach for most people outside of Qubes. The host OS requires ultimate trust and thus is almost never suited for running desktop VMs in a non-Qubes environment. I think our efforts might be better spent working on a Qubes configuration guide: --- ## Post 20 by @rundfunk — 2025-06-29T21:53:38Z > [@anonymous261](#): > > I’m not sure I agree, separate computers can have some security perks over VMs. Yes, that’s right – having multiple laptops / PCs and thus splitting everything up is of course better than VMs. --- ## Post 21 by @anon63378630 — 2025-06-29T22:33:32Z > [@rundfunk](#): > > You can remove the virtual network driver and your VM is in one second an Offline Air Gap. If the host has connectivity, this is absolutely not an airgap. --- ## Post 22 by @rundfunk — 2025-06-29T22:40:21Z Yes You can disable HOST networking and create one VM with networking and one VM without networking. I show you that with a screenshot soon. So you can only live in a VM world. The HOST is unimportant. --- ## Post 23 by @anon65804091 — 2025-06-29T23:10:46Z Most important questions: **What is your threat model?** **How risky is the activity you perform on your computer?** --- ## Post 24 by @anonymous261 — 2025-06-29T23:13:08Z Some more considerations for your setup: - Bubblejail uses unpriviledged user namespaces, which can be a security concern itself. Firejail probably needs no explanation. Flatpak could be preferrable, although it isn’t perfect either. Alternatively, you can use VMs as previously discussed, which can prevent apps from sharing the same kernel. - SELinux may be more comprehensive than AppArmor - gopass is like pass but written in go. Note that they both use PGP, which isn’t ideal. If you need a CLI password manager, you may want to consider 1Password’s CLI. [Get started with 1Password CLI | 1Password Developer](https://developer.1password.com/docs/cli/get-started/) - You may want to remove sudo, su, and/or doas in favor of run0 [Lennart Poettering: "5️⃣ Here's the 5th installment of my series of po…" - Mastodon](https://mastodon.social/@pid_eins/112353324518585654) - [uutils](https://uutils.github.io/coreutils/), [systeroid](https://github.com/orhun/systeroid), and [brush](https://github.com/reubeno/brush) are memory-safe alternatives to coreutils, sysctl, and bash respectively - You may want to consider @anon63378630 's Brace - secureblue’s post-install guide and features list may be useful [Install | secureblue](https://secureblue.dev/install#post-install) - You may want to consider Homebrew rather than pacman for CLI packages. They’ve had a recent security audit and have adjusted in response to the audit. They’re also planning to add sandboxing for packages on Linux. [FAQ | secureblue](https://secureblue.dev/faq#brew) - Lastly, if and when you can get newer hardware and still want GNU/Linux, Windows Secure Core PCs (especially the less bloated ARM ones) may be useful [Windows 11 Secured-Core PCs | Microsoft](https://www.microsoft.com/en-us/windows/business/windows-11-secured-core-computers) --- ## Post 25 by @rundfunk — 2025-06-29T23:15:01Z But now I spill over to a more positive energy and summarize what was done really well. # – Very good! Awesome! Well done, exemplary. 1. Compile the kernel with Control Flow Integrity (CFI), hardened patches, minimal kernel modules. (Not sure why full LTO improves security.) 2. Better access control matrix (folder permissions), sysctl security in /etc/sysctl.conf and bwrap usage. 3. Mullvad VPN 4. Password manager, Luks2 encryption (hopefully full disk), IOMMU protection, remove SUID from binaries. Excellent, very competent. # – Missing (Part 2) - No Bluetooth mouse, keyboard, headphone etc? My headphone, mouse, keyboard always with a cable. - No Wi-Fi? I connect to the Internet by cable - i use one PCI Express x1 Quad-Port server network card (only Intel, Broadcom). Use always cable. Use only S/FTP or S/STP CAT RJ45 cable. Imagine that your bank tells you that they are deliberately using Wlan. Difference UTP - S/STP: ![1cd6b4950f1d984d6aa8dd6c2c8059cb](//forum-uploads.privacyguidesusercontent.com/original/2X/e/edd4b7c233e14fc15b9ebfb6f8dc12db23d750fa.jpeg) PC server card: ![0HY7RMMain](//forum-uploads.privacyguidesusercontent.com/original/2X/1/137f015791282f02ccbe8863b657fdf6ce338372.jpeg) ![airplane](//forum-uploads.privacyguidesusercontent.com/original/2X/3/3afbeed7551e1bf429e212d4e870454d640eaa78.png) # – Stupid (Part 2) > To avoid hassle, I also have polkit rule to always return yes to wheel users, and sudo is passwordless, so wheel == root pretty much. - Old Hardware Use always hardware that is supported. Security / privacy profs do not buy 8-10 year old hardware. Imagine that your bank tells you that they are deliberately using 10-year-old hardware. --- ## Post 26 by @any1 — 2025-06-30T16:53:09Z > [@anonymous261](#): > > They’re also planning to add sandboxing for packages on Linux Mind sharing where you got this information? --- ## Post 27 by @anonymous261 — 2025-06-30T21:23:40Z I guess they may not be planning sandboxing, but I got that info from the secureblue discord: ![1000000382](//forum-uploads.privacyguidesusercontent.com/original/2X/2/2b72f06bbd81b05ea03a0d50ed4d8ce1a1e2976c.jpeg) --- ## Post 28 by @rundfunk — 2025-07-02T01:07:57Z > [@anonymous261](#): > > - [uutils](https://uutils.github.io/coreutils/), [systeroid](https://github.com/orhun/systeroid), and [brush](https://github.com/reubeno/brush) are memory-safe alternatives to coreutils, sysctl, and bash respectively. Or Terminals written in Rust: [Alacritty](https://alacritty.org/), [WezTerm](https://wezterm.org/) Avoid using terminals written in C. With Rust you eliminate 70% of all security problems in the computer world. Or [rage](https://github.com/str4d/rage) instead of age. Or [gocryptfs](https://nuetzlich.net/gocryptfs/) instead of CryFS. --- ## Post 30 by @asanyan — 2025-07-02T20:13:34Z > [@rundfunk](#): > > Terminals written in Rust: [Alacritty](https://alacritty.org/) Alacritty uses too much RAM (about 100 MB per window vs Foot’s 15~20, adds up very fast). I’ll have a look at the other projects you mentioned. Thanks! > [@rundfunk](#): > > (Not sure why full LTO improves security.) Can only enable CFI with LTO > [@anon63378630](#): > > Why? Just use the standard variant please Good question, I think that I had _some_ issue with the standard version and switched to light. I’ll try switching back. > [@rundfunk](#): > > Use always hardware that is supported. Security / privacy profs do not buy 8-10 year old hardware. Imagine that your bank tells you that they are deliberately using 10-year-old hardware. eh, I think it’s fine from my research. Running unsupported hardware is only very bad in phones because then you’re stuck on unsupported kernels > [@anonymous261](#): > > Lastly, if and when you can get newer hardware and still want GNU/Linux, Windows Secure Core PCs (especially the less bloated ARM ones) may be useful [Windows 11 Secured-Core PCs | Microsoft](https://www.microsoft.com/en-us/windows/business/windows-11-secured-core-computers) How likely is it that these ARM devices will be stuck on unsupported software 5-10 years from now? – Thanks everyone for the suggestions, didn’t expect this thread to be this active --- ## Post 31 by @anonymous261 — 2025-07-02T21:09:47Z > [@asanyan](#): > > How likely is it that these ARM devices will be stuck on unsupported software 5-10 years from now? It doesn’t seem like ARM support for software will be dropping anytime soon, Qualcomm, Apple, and Lenovo are doing well > [@asanyan](#): > > Thanks everyone for the suggestions Thank **you** for making this post, I myself have learned a lot from this topic --- ## Post 32 by @asanyan — 2025-07-02T23:13:27Z > [@anonymous261](#): > > It doesn’t seem like ARM support for software will be dropping anytime soon, Qualcomm, Apple, and Lenovo are doing well Yeah, but ARM isn’t very standardized hence why Linux support on phones is so spotty and even then only specific kernel versions work. I wonder if a device like this would be in a similar situation. --- ## Post 33 by @rundfunk — 2025-07-04T07:25:42Z > [@asanyan](#): > > 1 - Alacritty uses too much RAM (about 100 MB per window vs Foot’s 15~20, adds up very fast). > > 2 - eh, I think it’s fine from my research. Running unsupported hardware is only very bad in phones because then you’re stuck on unsupported kernels. 1 - This answer doesn’t make sense - it’s about security. If security means something to you, you accept this disadvantage. 2 - Hardware design / firmware errors cannot be fixed with OS software or can only be fixed with great difficulty. The general industry standard is: always the latest beta (hardware + software). OK you don’t work for a company like American Express or IBM. Imagine your bank tells you: We only use unsupported hardware and software. --- ## Post 34 by @Cyber-Typhoon — 2025-07-04T11:52:32Z A couple of potential heads up and maybe some items to consider: > [@anonymous261](#): > > [uutils](https://uutils.github.io/coreutils/), [systeroid](https://github.com/orhun/systeroid), and [brush](https://github.com/reubeno/brush) are memory-safe alternatives to coreutils, sysctl, and bash respectively uutils (coreutils replacement) is promising but not fully POSIX compliant — may break scripts that assume traditional coreutils behavior. > [@rundfunk](#): > > Terminals written in Rust: [Alacritty](https://alacritty.org/), [WezTerm](https://wezterm.org/) It seems that Wezterm doesn’t receive any security update since 02/2024. –------------------------------------- Some items to consider: Not sure if was mentioned already but for intrusion detection you could maybe install [AIDE](https://wiki.archlinux.org/title/AIDE) A somewhat controversy recommendation would be to use [LKRG](https://lkrg.org/). And another one is to adopt [XDG-ninja](https://github.com/b3nj5m1n/xdg-ninja) [Rootkit detection](https://wiki.archlinux.org/title/Rkhunter) may be something to look. [Fail2ban](https://wiki.archlinux.org/title/Fail2ban) may be helpful to try to protect SSH brute-force attacks. I also didn’t see any comment about DNS Encryption, you can try [DNSCrypt](https://wiki.archlinux.org/title/Dnscrypt-proxy) --- ## Post 35 by @anonymous372 — 2025-07-09T17:07:36Z > [@anonymous261](#): > > you may want to consider 1Password’s CLI Proton Pass is planning a CLI, too > **[Proton 2025 summer roadmaps | Proton](https://proton.me/blog/proton-2025-summer-roadmaps)** > > See what new features all Proton services have in store for the next several months. We rely on your feedback for these roadmaps, so let us know what you think.