Conversation

Aug 3, 2019

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

Phil Eaton

@phil_eaton

Aug 3, 2019

> 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

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.

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.

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

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.

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.

Show replies