Conversation

This highlights a few different problems, the fragile and unmaintainable nature of handwritten syscall policies, and the shitshow that is the Linux 64-bit time_t/y2k38 migration..

Quote Tweet

> This situation highlights a problem with seccomp() in general: it is difficult to write robust policies at that level of detail, and the resulting policies tend to be brittle in the best of times. lwn.net/SubscriberLink

1

3

8

Replying to

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.

1

1

Replying to

and

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

Replying to

and

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

Replying to

and

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

Wow.

1

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.

GitHub - GrapheneOS/hardened_malloc: Hardened allocator designed for modern systems. It has...

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

1

1

Replying to

and

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

Replying to

and

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.

developer.android.com

| Android Developers

Declares a service (a Service subclass) as one of the application's components. Unlike activities, services lack a visual user interface. They're used to implement long-running background operations...

1

1

Replying to

and

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.

9:44 PM · Aug 3, 2019Twitter Web App

Replying to

and

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

Replying to

and

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.

1

Show replies