SELinux belongs in hell. Firejail is good for user softwares. AppArmor is good for system services.

[amano-kenji]

System-level MAC softwares like SELinux and AppArmor don't try to restrict user-level access which is abused by malwares.

If SELinux or AppArmor ever got in the way of desktop users, it will be a UX disaster.

SELinux is too complicated and too restrictive even for most professional admins.

AppArmor is far simpler than SELinux, but it doesn't have blacklist, so it can't restrict and allow user-level access in granular details. It also can't change network namespace, but firejail can. AppArmor is still good for system services, but only if admins have some time to fiddle with apparmor profiles. AppArmor is justifiable only for restricting a few system services running on mission-critical machines. Return on investment for writing apparmor profiles for every system software is negative.

Bubblewrap is useless due to lack of profiles and blacklists. It is best used by flatpak.

Firejail sucks for system services because it cannot restrict root and because it breaks if a service runs as a user without any home directory. But, it is great for user-level softwares.

So, we are left with firejail and apparmor. I am still skeptical of the value of apparmor beyond restricting a few system services running in the background...... I'm also skeptical of restricting firejail with apparmor. If an application escapes firejail, apparmor profile for firejail can't restrict user-level access without making firejail useless.

[rusty-snake]

So, we are left with firejail and apparmor.

systemd

SELinux is too complicated and too restrictive

audit2allow

[amano-kenji]

systemd? I don't want an init system to have sandboxing capability. I don't know how sandboxing conceptually fits in an init system. Some things better come in one program, but I don't see sandboxing making much sense in an init system.

audit2allow doesn't change the fact that SELinux is far more complex than apparmor... Even if you use audit2allow to automatically adjust SELinux profiles, you still have to write and smooth out profiles by hand....

I think SELinux comes with broken UX. UX must be much better than SELinux dumpster fire. AppArmor is barely acceptable for writing a few profiles for system services. The fact that SELinux modifies filesystem metadata makes me cringe, too. I don't want a MAC software to mess with file system.

There are even papers that say that SELinux adoption stays low due to bad UX, and AppArmor adoption also stays low despite being much simpler than SELinux.

[amano-kenji]

I also point out that I really want to try out guix with shepherd init system because guile scheme is going to be better than bash and systemd service definition files. OpenRC's bash script UX is somewhat bad, but it is tolerable.

Systemd service definition files are okay from UX standpoint, but systemd still struggles to shut down fast. It often hangs for minutes during shut down... This is the deal breaker that made me ditch systemd in the first place. OpenRC shuts down blazingly fast...

If I move to shepherd init system and guix in the future, I don't want systemd...

[amano-kenji]

For linux softwares to reach mainstream adoption, open-source developers must consider UI and UX.

AppArmor is already out of consideration for most computer users.

Firejail? Maybe... because firejail can be added selectively to each program, and popular profiles mostly just work. Firejail can at least reach command line ninjas, but it won't reach mainstream.

[topimiettinen]

Security and hardening just is not simple. Nothing can change that, no fancy UX nor trying to make complex things simple. If there are lots of fine grained hardening points, some of them may eventually break the service as the software is developed. With simple knobs, either the hardening isn't as effective, or it may also break and then there's a big knob to be turned off. Also MAC policies can be very loose or everything tightened to max torque.

Android's security model is rather tight but the apps are developed with that policy in mind and broken apps are dropped from the store. I don't think any Linux distro could enforce similar security policy for services or apps. The traditional Unix model just isn't very secure and the newer technologies (seccomp, mount namespaces etc) are breaking it all the time. Also new attack surface is made available with new kernel features like io_uring or just new system calls.

MACs can be compared to firewalls. Firewall configuration can be made simple with firewalld or UFW, but the rules certainly aren't tightest possible. It's very annoying if the firewall doesn't let the traffic to pass, so it's also easy to loosen the rules.

[curiosityseeker]

System-level MAC softwares like SELinux and AppArmor don't try to restrict user-level access which is abused by malwares.

No, this is not true. I cannot speak about SELinux (which I tried years ago on Fedora) but with AppArmor you can easily confine user-space applications. I'm using https://github.com/roddhjav/apparmor.d which contains profiles for quite a number of apps. On my system I confine, e.g., Firefox and Brave (both in combination with Firejail), Thunderbird, LibreOffice, Okular, Gwenview and some more. Mostly apps for which I repeatedly run into problems with Firejail because of failed profile transitions.

AppArmor is far simpler than SELinux, but it doesn't have blacklist, so it can't restrict and allow user-level access in granular details.

No, this isn't true, either. AppArmor has deny rules which take precedence. That said, deny rules are actually not really needed as in AppArmor everything is forbidden which is not explicitly allowed. Insofar it's similar to whitelisting in Firejail.

So, we are left with firejail and apparmor. I am still skeptical of the value of apparmor beyond restricting a few system services running in the background...... I'm also skeptical of restricting firejail with apparmor. If an application escapes firejail, apparmor profile for firejail can't restrict user-level access without making firejail useless.

No, this isn't true again - see remarks above. I don't know if Firejail itself can be properly restricted by AppArmor. But you can use both in tandem for an application: it's recommended to include <abstractions/base.d/firejail-base> to your *.local AppArmor profile and add ignore apparmor to your *.local Firejail profile to make sure that not firejail-default but the specific AppArmor profile for that application is used. If you do that there is no reason to believe that AppArmor cannot catch a request which escapes Firejail (depending on how strict the AppArmor profile is written, of course).

[topimiettinen]

At least in Fedora and in default SELinux installation, the users use unconfined user domain (unconfined_t), so they aren't very protected. It's relatively easy to change the domain to more restrictive unprivileged user (user_t).

[amano-kenji]

I'm not getting many built-in profiles from apparmor, and the built-in profiles for zgrep and syslog-ng are broken on gentoo linux.

[amano-kenji]

It seems to me that firejail is more suitable for user applications. I wouldn't use firejail along with apparmor because that's too much effort.... I don't want to become a dedicated computer admin. I'm a tinkerer..

Thus, I would use firejail for user applications and apparmor for system services.... It's simpler that way.

Plus, apparmor cannot work inside a firejail sandbox for now.

[amano-kenji]

How would you best utilize firejail and apparmor?

[curiosityseeker]

It seems to me that firejail is more suitable for user applications. I wouldn't use firejail along with apparmor because that's too much effort.... I don't want to become a dedicated computer admin. I'm a tinkerer..

Thus, I would use firejail for user applications and apparmor for system services.... It's simpler that way.

That's debatable. In those cases where Firejail prevents a profile transition it's not simpler to me. With AppArmor this is not a problem by using Px.

Plus, apparmor cannot work inside a firejail sandbox for now.

You're aware that right now 788 Firejail profiles use AppArmor? Yes, only firejail-default is used. But for high-risk applications like browsers you can use a specific tight AppArmor profile in tandem with Firejail as mentioned earlier.

[amano-kenji]

You're aware that right now 788 Firejail profiles use AppArmor?

Yes. I tweaked my firejail-default apparmor profile. I thought it was a waste of my time. firejail-default doesn't make a firejail profile tighter....

If a web browser manages to escape firejail, but not apparmor, it will still have user access because firejail-default is not responsible for restricting user access....

[curiosityseeker]

Yes. I tweaked my firejail-default apparmor profile.

May I ask what exactly did you add/modify? Since firejail-default is used by all of those 788 profiles, such changes might work for some applications but might break others.

[amano-kenji]

I just allowed more for firejail-default in /etc/apparmor.d/local/firejail-default.

I just disabled apparmor in firejail... after realizing that apparmor doesn't make firejail safer...