It's the failed attempt at providing a privacy/security model that's the problem. It might be better than Snap and other alternatives if you ignore all that. They made it a big part of it though. There are also APIs tied to it. They ported Chromium to using Flatpak sandbox APIs.
Conversation
They ended up building things in a way where they end up requiring applications to target their own APIs but a lot of it is designed poorly. It leaks a ton of weird implementation details and a lot is misguided. They're doing a lot of it without looking at iOS, Android, etc.
1
I think it's pretty silly to basically work towards spending years of work re-creating the Android 4.4.x sandbox and permission model but without most applications actually using it. Also no one to force apps to do yearly migrations to a stricter sandbox / permission model.
1
The Android sandbox and permission model is a dead end, built on NSA Linux rather than namespaces.
2
It does use namespaces. They don't offer a way to do the things that it does with SELinux. SELinux is an implementation detail not expose to app developers. It could be any other LSM. It's just how the fine-grained, hard-wired policy in the OS is written. It's not for app devs.
2
1
The stuff you can do with SELinux or LSMs is not stuff that makes sense to do.
1
Then you give up on being able to filter access to kernel APIs like procfs, sysfs, debugfs, perf events, driver ioctls, etc. along with enforcing the security model between the sandboxes via static policy instead of only being something derived dynamically at runtime from code.
2
The upstream kernel has even rejected having a way to fully disable access to perf events without using an LSM. If you can do it with an LSM, they won't accept security features for it anymore. SELinux is even how you do restrictions on dynamic native code generation, etc.
1
1
Restrictions on dynamic native code generation is not a security boundary it's a walled garden market control boundary.
1
And perf events? Seccomp trivially blocks all access.
1
A problem with that is that you can't undo making the seccomp filter to do debugging/profiling without spawning the application again.
Due to the design of the system call API, you can't really do anything more than disallowing it as a whole. Can't allow a small portion of it.
Granularity of seccomp-bpf is based on system calls and integer parameters. Look at how the io_uring kernel API is set up as another example. If you don't fully disallow it, it bypasses an ever increasing amount of seccomp-bpf filtering since it's blind to what's behind pointers.
2
1
2
Show replies
That's perfectly fine. We don't need debuggers and profiling tools internal to untrusted apps. (You can still debug & profile them from outside just fine, too!)