I think the main issue is the fragmented OS development model. It doesn't work for privacy and security since it blocks progress crossing project boundaries. There's a massive lack of overall work on whole system privacy and security. It cannot be achieved within the silos.
Conversation
It's also a completely unrealistic approach. It's far more realistic to make a standard sandbox and force all applications outside of the base system to target it. It's great if applications go out of their way to do finer grained sandboxing but it's an unrealistic baseline.
1
I see lots of applications using seccomp-bpf simply because they can and it's good marketing but with no real attempt at making a meaningful sandbox with it or using it to reinforce an existing sandbox. They do it because they can and due to the OS development model it's fragile.
1
The pledge approach on a traditional Linux distribution would be fragile too. The entire OS development, packaging and security model is broken.
git.savannah.gnu.org/cgit/man-db.gi
OpenBSD has a much more well-defined base system. Still a lot of ad-hoc configuration, etc. but much less.
1
1
3
Replying to
Also note this doesn't allow getrandom so it's broken with github.com/GrapheneOS/har and has to be patched and rebuilt if libc is using that as the malloc implementation. Pledge would avoid that, but I think the real issue is the base OS should be doing nearly all of this instead.
1
1
It makes much more sense to expose a very high-level API to third party applications for fine-grained sandboxing. They should be targeted at standard app sandboxes in the first place, but having each reinvent fine-grained sandboxing and generally do it wrong (like this) is silly.
1
As an example, Android provides isolatedProcess for fine-grained sandboxing, which simply the semantic layer of the Chromium sandbox:
developer.android.com/guide/topics/m
It's what Chromium uses on Android rather than namespaces. As with the main app sandbox, the OS deals with the details.
1
1
I don't think seccomp-bpf and SELinux can work for traditional Linux distributions at scale. It works for Android because all third party code targets a standard app sandbox, and the OS makes backwards incompatible privacy/security changes tied to API level for the sandbox/APIs.
1
1
Both SELinux and seccomp-bpf are way too complicated / powerful to deal with them for every application. It does work quite well when the policies are developed as part of the OS. Treble driver support code for each device also provides SELinux policy extensions it needs to work.
1
It works because there is no system administrator arbitrarily building the OS by choosing a set of packages and arbitrary configurations. SELinux isn't viable as soon as you start expecting system administrators to deal with it. It works when only the OS developers have to do it.
Fedora and RHEL barely even use SELinux. They don't have strict full system policies where nothing is unconfined like Android, and all non-base system code tightly sandboxed. They use it in a very targeted and weak way. Despite that, system administrators hate it and disable it.
1
1
Entire concept teaching system administrators to deal with it is crazy. They aren't even learning SELinux but rather how to deal with a specific approach in Fedora / RHEL. Domains, labels, booleans & overall approach are entirely distro-specific. Looks nothing like Android's use.
1
1
Show replies