SELinux belongs in hell. Firejail is good for user softwares. AppArmor is good for system services. #6166
Replies: 4 comments 10 replies
-
systemd
audit2allow |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
At least in Fedora and in default SELinux installation, the users use unconfined user domain ( |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
How would you best utilize firejail and apparmor? |
Beta Was this translation helpful? Give feedback.
-
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.
You're aware that right now 788 Firejail profiles use AppArmor? Yes, only |
Beta Was this translation helpful? Give feedback.
-
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.... |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions