# Which linux distribution offers both high performance and security? **URL:** https://discuss.privacyguides.net/t/which-linux-distribution-offers-both-high-performance-and-security/18672 **Category:** General **Created:** 2024-06-02T09:24:20Z **Posts:** 47 ## Post 1 by @anon45588987 — 2024-06-02T09:24:20Z I’m considering switching from Windows to Linux. Due to work reasons (python/java programming), Linux actually has better compatibility for me. i tested but the performance of QubesOS is not that good. I hope it would be better to have a linux distribution that is secure and performant enough, guys do u have any recommendations? --- ## Post 2 by @anon48875053 — 2024-06-02T09:25:29Z If you’re okay with an immutable distribution, then I would highly recommend trying [openSUSE Aeon](https://aeondesktop.github.io/), and if you want a traditional distribution, then try Fedora with @anon63378630’s [brace](https://github.com/divestedcg/Brace). --- ## Post 3 by @anon45588987 — 2024-06-02T09:28:24Z thx, i’ll try it --- ## Post 4 by @brivacy — 2024-06-02T10:14:11Z For home use i recommend that what @anon48875053 recommend opensuse aeon which is just a opensuse micro os 2nd would be fedora silverblue. Not the traditional distro still if you want you can try ultramarine os which is just fedora with all free and non free repos. which you will ultimately do. Also you can tru ublue os. --- ## Post 5 by @anon48875053 — 2024-06-02T10:18:15Z > [@brivacy](#): > > For home use i recommend that what @anon48875053 recommend opensuse aeon which is just a opensuse micro os MicroOS is a server distribution and is made for servers, Aeon is a desktop distribution and is made for desktop use. --- ## Post 6 by @brivacy — 2024-06-02T10:20:37Z > [@anon48875053](#): > > MicroOS Microos is also have desktop if you try to install you will find dektop option like kde and gnome is there. Just install it and you have dektop. Edit > **[Your first start in openSUSE MicroOS - Quickstart guide for beginners [Tutorial]](https://www.youtube.com/watch?si=Kf5GP2DFz-a0LI9n&v=E8LBQV1jjwk&feature=youtu.be)** > > Today I'm gonna show you how to do your first steps in openSUSE MicroOS to get a smooth start.If you want to support this video, please rate this video, and ... --- ## Post 7 by @anon48875053 — 2024-06-02T10:21:39Z This is an outdated video, and he is using an outdated ISO. Aeon has it’s own image which can be downloaded here: [https://aeondesktop.github.io/](https://aeondesktop.github.io/) --- ## Post 8 by @brivacy — 2024-06-02T10:23:41Z Yes i know but this is the same thing. --- ## Post 9 by @anon48875053 — 2024-06-02T10:25:09Z No, Aeon has its own separate image and its own installer called tik, which you can find here: [GitHub - sysrich/tik: Tailored Installation Kit](https://github.com/sysrich/tik) --- ## Post 10 by @sha123 — 2024-06-02T10:29:08Z > [@anon45588987](#): > > I hope it would be better to have a linux distribution that is secure and performant enough, guys do u have any recommendations? Performance-wise they are all fine, as long as you don’t do some HPC stuff. Would look for a distro which is supported by the tools you need and a Wayland-based desktop environment with which you feel comfortable, e.g. KDE. Security-wise they are all more or less not great by default. Would stay away from forks of forks (e.g. no Linux Mint). Some distros are better than others in terms of security, but the question is how much it matters, if you only use it for work and programming. How proficient are you with using Linux? --- ## Post 11 by @anon73250778 — 2024-06-02T12:08:41Z > [@anon45588987](#): > > QubesOS is not that good. Qubes is overkill for a daily driver of the general public --- ## Post 12 by @anon48875053 — 2024-06-02T12:13:30Z It’s not really overkill, it’s just bad in terms of resource usage, UX, gaming, etc. That’s why the general public shouldn’t use it. --- ## Post 13 by @anon46412288 — 2024-06-02T12:16:28Z I think performance is mostly the same across most distributions if they use unmodified, upstream kernels from Android. Security is what really differentiates between the various distros. Some distros ship with a set of security policies called SELinux to improve security by limiting the reach of certain privileged processes. On some distros like Arch Linux, you need to set that up youself. As @anon48875053 mentioned, openSUSE Aeon and Fedora Linux are great options. However, if you are brand new to Linux I would suggest not using brace for the meanwhile since you need some technical knowhow in order to diagnose any potential issues that can arise with the hardening. --- ## Post 14 by @lepras — 2024-06-02T12:22:52Z > [@anon48875053](#): > > Aeon has it’s own image which can be downloaded here: [https://aeondesktop.github.io/](https://aeondesktop.github.io/) I am afraid to ask this question, but whats so special about opensuse again? --- ## Post 15 by @anon48875053 — 2024-06-02T12:33:48Z > **[Why you should be running the MicroOS Desktop](https://www.youtube.com/watch?v=lKYLF1tA4Ik)** > > The MicroOS Desktop started as a hairbrained, poorly thought out, "lets see what happens" concept at an openSUSE Conference not so long ago.It's since become... Note: MicroOS Desktop was renamed to Aeon. --- ## Post 16 by @brivacy — 2024-06-02T13:05:27Z > [@anon48875053](#): > > MicroOS Desktop was renamed to Aeon. I told you. > [@brivacy](#): > > opensuse aeon which is just a opensuse micro os Look. --- ## Post 17 by @anon48875053 — 2024-06-02T13:33:58Z MicroOS is a server OS. MicroOS Desktop was a dekstop OS that had two variants, GNOME and KDE. Then both GNOME and KDE versions turned from MicroOS Desktop into openSUSE Aeon and openSUSE Kalpa. Then the developer of Aeon created his own installer and started shipping Aeon images. So no, Aeon isn’t just MicroOS. --- ## Post 18 by @brivacy — 2024-06-02T15:51:45Z What are the key differences between this and silverblue? --- ## Post 19 by @lepras — 2024-06-02T17:45:45Z > [@brivacy](#): > > silverblue Secureblue\* --- ## Post 20 by @Regime6045 — 2024-06-03T14:55:23Z | | Fedora Atomic (Silverblue/Kinoite) | OpenSUSE MicroOS (Aeon/Kalpa) | | --- | --- | --- | | Release schedule | Every 6 months | Rolling | | Recommended app installation | Flatpak, AppImage, Toolbox | Flatpak, Distrobox | | Can install RPMs? | Yes (`rpm-ostree`) | Yes (`transactional-update`) | | Can change base system? | No | Yes (`transactional-update`) | | Prevents configuration drift? | Yes | Only if you don’t touch `transactional-update` | | Desktop environments | Gnome, KDE, others | Gnome, KDE (alpha) | Fedora Silverblue/Kinoite: you have a base image that can’t be changed (“immutable”) and you install apps mainly as Flatpaks or in containers (via the preinstalled `toolbox` package), but you also have the option to “layer” RPMs on top of your base image. Some won’t work, e.g. if the RPM wants to install kernel modules. It follows the same release schedule as Fedora, with a new release every 6 months and only minor updates in between. If an update goes wrong, you can revert to the previous base image of your system. You can also switch between images (e.g. Gnome to KDE) easily and without messing up your system. OpenSUSE Aeon/Kalpa: Instead of having the base system as an immutable image on which you can layer RPM packages on top, it uses btrfs snapshots and whenever an update or change to the system happens this will be done in the new (future) snapshot. After a reboot you’ll be in the new snapshot but if anything goes wrong you can revert to the previous snapshot. Unlike Fedora, it’s not possible to “layer” an RPM (so that it remains cleanly separated from the default system) but you have more flexibility as you can basically make any changes you want to the new snapshot using `transactional-update`, whether that’s installing an RPM or changing any system config files. Installing kernel modules and low-level drivers is also possible. However, the more you tinker the more you’re on your own, because you risk having a “configuration drift” (drifting away from the default install). Other differences are that it uses `distrobox` instead of `toolbox` (distrobox is much better imo) and that the base system is a rolling release (using OpenSUSE Tumbleweed packages) so you are continuously updating to the newest packages. --- ## Post 21 by @anon48875053 — 2024-06-03T14:59:17Z On Aeon: It is important to remember that it is STRONGLY recommended to install software in the following order of preference: 1. Flatpaks from your software center of choice or [Flathub](https://flathub.org/home) 2. RPM’s in a user distrobox _distrobox-enter_ 3. RPM’s in a root distrobox _distrobox-enter -r_ 4. RPM’s via transactional-update – for drivers, kernel modules, strictly what you need for your host operating system to work. **To reiterate: EVERYTHING should be done via flatpaks or be installed in a Distrobox if a package is not available as a flatpak. Using transactional-update is strictly what you need for your host operating system to work (exotic drivers, specialized vpn services).** --- ## Post 22 by @Cyber-Typhoon — 2024-06-03T15:44:06Z > [@anon48875053](#): > > openSUSE Aeon and openSUSE Kalpa. Hey, isn’t Aeon still classified as release candidate distro from OpenSuse and Kalpa in Alpha stage? Just thought that it may worth giving this a heads up to the OP. --- ## Post 23 by @anon48875053 — 2024-06-03T15:51:59Z Aeon is in RC2 stage and will be released I think will be released soon. It works very well for me and other folks that are using it, so I don’t think it matters that it’s in RC2 stage. --- ## Post 24 by @HushedWave — 2024-06-03T16:14:00Z Does that Brace you posted work with Fedora 40? --- ## Post 25 by @crossroads — 2024-06-03T16:26:27Z Also to add that Aeon doesn’t support AppImages, not sure if that is the case with Silverblue --- ## Post 26 by @anon48875053 — 2024-06-03T16:27:44Z Because AppImages suck… --- ## Post 27 by @Regime6045 — 2024-06-03T16:30:32Z They work on Fedora Silverblue/Kinoite and OpenSUSE Tumbleweed, but indeed not on OpenSUSE Aeon/Kalpa. Which I personally find quite annoying because sometimes apps are only officially available as an Appimage. --- ## Post 28 by @crossroads — 2024-06-03T16:43:28Z Main Aeon responsible (Richard Brown) doesn’t like AppImages. Or more precisely he thinks that is not a good way for program distribution, and flatpaks are way to go. I don’t know it would work via distrobox (e.g. Ubuntu), as I’m not sure if fuse has to be installed on host system, or only container --- ## Post 29 by @anon48875053 — 2024-06-03T16:44:06Z > [@crossroads](#): > > flatpaks are way to go. Completely agree. --- ## Post 30 by @curious78 — 2024-06-03T17:15:15Z > [@HushedWave](#): > > Does that Brace you posted work with Fedora 40? And does Brace work with the Atomic Fedoras like Silverblue and transactional Aeon? When I looked at the site for Brace yesterday when reading this thread I thought the Brace changes probably could not be applied to an atomic image. In reading this thread RE Aeon, I am suspecting that Brace can likely be applied properly there but you would then start to have config drift as mentioned. @anon63378630 --- ## Post 31 by @anon48875053 — 2024-06-03T17:16:31Z Ask @anon63378630. --- ## Post 32 by @brivacy — 2024-06-03T17:47:49Z True does not have any point to use appimage reason is large size with no sandboxing at all --- ## Post 33 by @anon63378630 — 2024-06-03T18:00:13Z @curious78 some of the general changes of Brace should work under Silverblue, and it used to have explicit support for it too I stopped because I didn’t (and still don’t) see the value of Silverblue in its current state over traditional variants. Like they aren’t (yet) doing eg. seamless A/B updates or strict dm-verity enforcement. Going further, fapolicyd can be used to trivially help with ensuring integrity of executables on traditional variants but isn’t compatible with flatpak installed software. For anyone who wants to try this: ``` dnf install fapolicyd; sed -i 's/integrity = none/integrity = sha256/g' /etc/fapolicyd/fapolicyd.conf; systemctl enable fapolicyd --now; ``` --- ## Post 34 by @Cyber-Typhoon — 2024-06-03T18:19:35Z > [@anon46412288](#): > > Security is what really differentiates between the various distros. > > Some distros ship with a set of security policies called SELinux to improve security by limiting the reach of certain privileged processes. Is this implying that SELinux may improve security over AppArmor? --- ## Post 35 by @curious78 — 2024-06-03T19:00:04Z > [@anon63378630](#): > > I stopped because I didn’t (and still don’t) see the value of Silverblue in its current state over traditional variants. This is very interesting as I had perceived the future was atomic desktops + flatpaks or immutables like Nix or Guix. I read [here](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/assembly_blocking-and-allowing-applications-using-fapolicyd_security-hardening): “The fapolicyd framework trusts files contained in the RPM database. You can mark additional files as trusted by adding the corresponding entries to the `/etc/fapolicyd/fapolicyd.trust` plain-text file or the `/etc/fapolicyd/trust.d/` directory, which supports separating a list of trusted files into more files.” If I understand fapolicyd correctly, I could freshly install traditional Fedora (non-atomic) and then mark the fresh install as trusted? Thereafter, it would be best to prioritize rpms rather than flatpaks, correct? Is there anything lost here by not having flatpaks and their sandbox? I read someplace that flatpak sandbox is weak in some instances maybe due to improper or inconsistent application (?). What is your take on Aeon? How well does/could Brace and fapolicyd work with Aeon? Edit: added the sentence after the initial quote. --- ## Post 36 by @anon48875053 — 2024-06-03T19:04:01Z > [@curious78](#): > > How well does/could Brace and fapolicyd work with Aeon? Brace supports Tumbleweed but not MicroOS or Aeon. At least according to the supported distro list in the repository. As for fapolicyd, Aeon recommends using flatpaks and fapolicyd isn’t compatible with them and you shouldn’t install RPM packages on the base system. You either install them as flatpaks or in a distrobox. --- ## Post 37 by @anon63378630 — 2024-06-03T19:11:23Z @curious78 fapolicyd already trusts all installed rpm files by default you don’t have to do anything to maintain it if you download something or something downloads itself outside of the package manager, it cannot be executed unless you first add it manually to the trust database additionally with integrity enabled, it verifies the hash, path, and size ensuring what you execute is what you expect if you use third-party rpm repos they may not include the additional necessary hashes in their rpms. rpmfusion and divested-rpm repos both do include the necessary metadata for packages that don’t support it you can switch to the weak size integrity mode or you can manually trust the rpm’s executables you can still use flatpaks on an fapolicyd enabled system, they just won’t actually be checked at all tl;dr most users can install fapolicyd as noted above and never have to do anything to maintain it as long as you stick to package manager installed packages --- ## Post 38 by @sha123 — 2024-06-04T12:18:25Z > [@anon63378630](#): > > you can still use flatpaks on an fapolicyd enabled system, they just won’t actually be checked at all Why won’t they be checked? Sounds like an easy bypass. Most scripts also bypass the default configuration and also everything which can disable the fapolicyd daemon, for example something running as root. Unfortunately it does not nearly have the strong guarantees of WDAC on Windows, especially signed WDAC, because Linux lacks VBS. --- ## Post 39 by @sha123 — 2024-06-04T12:21:14Z > [@Cyber-Typhoon](#): > > Is this implying that SELinux may improve security over AppArmor? Only slightly and mainly for some daemons which are important in a server environment. In general in both systems, the default policies are quite lax and weak for desktop usage. Since it is easier to write policies with Apparmor, Apparmor can be more secure in practice, _if_ you make use of it. --- ## Post 40 by @anon46412288 — 2024-06-04T12:51:34Z No. --- ## Post 41 by @sha123 — 2024-06-04T13:01:59Z > [@anon46412288](#): > > Some distros ship with a set of security policies called SELinux to improve security by limiting the reach of certain privileged processes. The kernel LSM is called SELinux, not the set of security policies. --- ## Post 42 by @Cyber-Typhoon — 2024-06-05T01:26:30Z > [@sha123](#): > > the default policies are quite lax and weak for desktop usage. Since it is easier to write policies with Apparmor Could you maybe give some application profile examples that worth applying/writing Apparmor policies to secure it? --- ## Post 43 by @sha123 — 2024-06-05T07:58:26Z > **[GitHub - roddhjav/apparmor.d: Full set of AppArmor policies](https://github.com/roddhjav/apparmor.d)** > > Full set of AppArmor policies You need to be able to debug profiles, if you run them in enforcement mode and there are problems. From my experience, at least on EndeavourOS, there definitely will be problems. It’s usually not difficult to do, but is a bit cumbersome and a constant effort. --- ## Post 44 by @jonah — 2024-06-06T02:49:24Z > [@curious78](#): > > SkewedZeppelin: > > > I stopped because I didn’t (and still don’t) see the value of Silverblue in its current state over traditional variants. > > This is very interesting as I had perceived the future was atomic desktops + flatpaks or immutables like Nix or Guix. I can’t speak for @SkewedZeppelin but _I’d imagine_ “in its current state” is doing a lot of heavy lifting in this sentence here. I personally believe they are the _future_ of desktops, but we’ve been complaining about many missing features (incl. privacy and security related ones) for a long time, which are still needed to make the potential advantages realized. FMPOV the advantage of distros like Silverblue is that it provides a better base system for these features to be _eventually_ added to, a lot of the things I’d like to see come to Linux would be much more challenging to implement on traditional distros. Until the missing features are actually built though, the difference is probably insignificant for most people. That being said, I personally still think Silverblue has a system stability advantage over traditional distros even today, and I know people who frequently rebase on different desktop environments, which would be much more annoying to do on traditional distros. Also, I think it is useful for people to start learning how they work sooner rather than later. --- ## Post 45 by @anon21666177 — 2024-06-06T06:30:59Z Wouldn’t the upcoming version of OpenSUSE Aeon offer more stability? --- ## Post 46 by @username0990 — 2024-06-07T05:29:07Z I find the argument that immutable distributions are more secure questionable, but I think the best thing they do is to make system upgrades less problematic. What is the [lynis](https://software.opensuse.org/package/lynis) score of Aeon/Kalpa/MicroOS? Tumbleweed has a score of more than 80 points. For some users this score doesn’t really matter, I don’t think it’s everything in terms of security, but it’s still something that can be measured. --- ## Post 47 by @anon43985288 — 2024-06-07T13:09:48Z Immutable distros should solve many practical & theoretical security problems chief among them malware gaining persistence through the core parts of your system and possibly even reproducible builds in the future (or verifiable builds at the very least). This when combined with tools such Full Disk Encryption, Secureboot and hardware keys/TPM increase upon the security foundation. I would personally look into these tools as a measure of the strength of a system’s security over lynis which will give you warnings for outdated security concerns based on ancient cves. On that note, since Aeon has automatic updates that don’t need any user interaction, that alone places it way ahead of most general purpose distros in terms of security.