Which linux distribution offers both high performance and security?

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
  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).

1 Like

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.

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.

1 Like

Does that Brace you posted work with Fedora 40?

Also to add that Aeon doesn’t support AppImages, not sure if that is the case with Silverblue

Because AppImages suck…

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.

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

1 Like

Completely agree.

1 Like

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.

@SkewedZeppelin

Ask @SkewedZeppelin.

1 Like

True does not have any point to use appimage reason is large size with no sandboxing at all

@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;
2 Likes

Is this implying that SELinux may improve security over AppArmor?

This is very interesting as I had perceived the future was atomic desktops + flatpaks or immutables like Nix or Guix.

I read here:

“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.

1 Like

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.

@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

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.

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.

3 Likes

No.

1 Like