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
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
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
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
Show replies