Linux Security Question: Apparmor and Sandboxing

As I continue on my Linux security journey, I am trying to better understand AppArmor (I will not be using SELinux). I understand the concept behind AppArmor: restrict permissions of certain software based on path, but I am a bit confused on how to implement it.

I know that AppArmor comes with a few default profiles, but they are extremely limited in number. The Arch Wiki seems to indicate that one is supposed to create their own profiles, but that seems extremely tedious. Are there any trusted, already created sets of AppArmor profiles? I found this one, but I am unsure about whether it can be trusted.

Furthermore, it seems to be recommended to use sandboxing software such as FireJail or Bubblewrap in addition to AppArmor, and I was wondering why. How does Firejail/Bubblewrap/etc differ from AppArmor and what are the intended use cases for AppArmor vs FireJail/Bubblewrap/etc?

The appArmor repo you linked is fine to use, I have personally used it, still use it for my arch install. I also looked through quite a few profiles while using it, I recommand you do so on their repo as well and see what each profile is allowing and blocking.
Gnome seems to be fully supported but KDE Plasma is mostly supported, keep that in mind when you do compile it your DE of choice.

I have not used firejail so can’t say anything about it.
Bubblewrap is the sandboxing system used by flatpaks, you don’t need to install it or think about it, use flatpaks as normal and you should be fine.

EDIT: Forgot to mention, read through their website they have detailed instructions and few optimisation tips as well.

1 Like

Thank you for the information regarding the apparmor profiles.

I don’t actually use flatpaks (I generally stick to the official Arch Repositories and the occasional AUR package). I am still a bit confused on the differences between sandboxing software and AppArmor.

If you care about sandboxing, you should be using Flatpak. Snap on Ubuntu uses AppArmor for its sandboxing.

Just be aware that many Flatpak apps by default have permissions which allow for relatively easy sandbox escapes. To use it as a sandbox you need to know which permissions allow for known escapes or access to sensitive data, deny these and hope that the app stays functional. Also use the right update commands to not accidentally give apps more permissions during updates. Even then it’s not a particularly strong sandbox.

That’s a good project, but things break from time to time, because software on Linux usually expects to be able to access anything which the user it runs as has access to. Also profiles expect you to use apps with the respective xdg directories. For example browser profiles might only provide access to the downloads folder in your home directory. You need to be able to read logs to see when something doesn’t work whether it was caused by a Apparmor profile or not and do a quick fix. The aa-log tool can provide suggestions for a fix.

Apparmor is a mandatory access framework. It’s not a sandbox, although it can be part of a sandbox build, also in conjunction with other parts like DAC, namespaces, root-changes (chroot, pivot-root), seccomp-bpf-filters, portals and so on.

See also this comment on the difference of confinement and sandboxing systemd sandboxing · Issue #83 · roddhjav/apparmor.d · GitHub

Sandboxing and confinement on Linux are big topics which require a lot of knowledge about Linux security. It’s a deep rabbit hole and even if you manage to go deep enough to write meaningful sandboxes, you still need a lot of time to write and maintain them and be at the mercy of software devs to write their programs in a way that they stay functional in a restrictive sandbox.

Many is a huge overstatement, most Flatpaks are as sandboxed as they can be. And no you don’t need in-depth information on these permissions, just use the app as is. Updating can just be done with flatpak update or graphically, not sure what you’re on about here.

I’d like to add that we shouldn’t make these tools harder than they have to be. Flatpak isn’t made as a sandboxing tool, it is made to have a sandbox by default just like Android apps.

Look into https://www.enck.org/pubs/dunlap-sacmat22.pdf . 42% of Flatpaks had easy sandbox escapes. And tbh this study only looked into the the really trivial ones and left out other escapes, so the real number is likely higher. Also even without known escapes a good sandbox should minimize attack surface which flatpak is quite bad at.

Many guides use flags which auto-update also the permissions, making new escapes possible.

Android’s app sandbox and Flatpak are about as far away from each other in terms of security as can be. Android’s app sandbox is much stronger, doesn’t allow for easy escapes, has runtime permissions, more fine-grained permissions much less attack surface, and the Play Store forces app devs to adhere to a stricter sandbox with each new API.

Sandboxing in specific and Linux security in general are very difficult. Oversimplified solutions will just give you a good feeling without real security.

Look into https://www.enck.org/pubs/dunlap-sacmat22.pdf 1 . 42% of Flatpaks had easy sandbox escapes.

This is a really interesting study I wasn’t aware of, thanks! However, Flatpak and Flathub are both improving at an incredibly high rate, and statistics like this become irrelevant extremely quickly.

Also even without known escapes a good sandbox should minimize attack surface which flatpak is quite bad at.

It does still need a lot of work, but we’re at a way better position than just getting apps as traditional packages.

Many guides use flags which auto-update also the permissions, making new escapes possible.

Permissions should be auto-updated for now. In the future, we will have manual consent for permissions just like Android.

Android’s app sandbox and Flatpak are about as far away from each other in terms of security as can be.

I never claimed it was as good as Android, Linux is far behind in basically every aspect of app distribution. What I meant is that the idea is similar.

Oversimplified solutions will just give you a good feeling without real security.

It is not oversimplified, it’s called good UX.

AppArmor is implementation of Mandatory Access Control, which basically limits what should and shouldn’t be accessible by any given applications, hence need for profiles.

Sandboxing is isolation of a software from the system it is running on, it can be through emulation or replication of what the application expect when running, for example the folder structure, libraries it need, fonts, language packs etc.

Both Flatpak and Snaps essentially do sandboxing. We still need AppArmor or SElinux, for a layer of security on our base system.

1 Like

Thank you for the clarification. Is sandboxing important for security if I am using my distros official repositories?

Depends on your threat model and trust in your distribution. Malicious code can always get through, and security vulnerabilities will always be present.

1 Like

Linux Desktop distros lack in many security aspects. Well done sandboxing can be a strong security measure eliminating quite a few shortcomings of Linux with respect to the sandboxed application. Especially programs which handle untrusted input, do parsing or render (web) content can benefit from it. In general sandboxing is worth it from a security perspective. The question is do you have the time and knowledge to do it and which solutions do you choose?

1 Like

There is no definitive answer to this. Think about your own use case, and determine if using flatpaks or snaps makes sense to you.
I treat sandboxed application as another layer of protection, while not perfect, I will take some precaution than none.

Learn more about each, try them and you will find your answer.

1 Like