The inherent fragility of seccomp()

Posted Nov 11, 2017 4:59 UTC (Sat) by roc (subscriber, #30627)
Parent article: The inherent fragility of seccomp()

We hit similar issues with some rr tests as well. Various rr things not related to seccomp also had to be updated to handle openat efficiently.

There isn't really a good solution here. pledge() won't scale to a broader software ecosystem. Trying to let libraries express their syscall requirements and collect those transitively would be complicated and prone to errors that over-expose the kernel. Probably a more capability-based kernel API would be better, but it's hard to get there from here.

The inherent fragility of seccomp()

Posted Nov 12, 2017 8:59 UTC (Sun) by wahern (subscriber, #37304) [Link] (2 responses)

Getting there from here is nearly as easy as a single merge: https://github.com/google/capsicum-linux

The inherent fragility of seccomp()

Posted Nov 12, 2017 9:27 UTC (Sun) by roc (subscriber, #30627) [Link] (1 responses)

Getting that merged would in itself be a monumental task.

Then you'd have to rewrite glibc and most other userspace libraries and applications to use capsicum-enabled APIs.

It could be great, but don't claim it's easy.

The inherent fragility of seccomp()

Posted Nov 13, 2017 21:42 UTC (Mon) by wahern (subscriber, #37304) [Link]

True, actually using Capsicum from applications takes considerable work unless you're starting from scratch. But getting it merged seems more like a political rather than a technical issue, as most of the technical work exists for the taking.

Getting over that political hurdle seems daunting, unfortunately. AFAIK the CLONE_FD patch (https://lwn.net/Articles/638613/), necessary for implementing Capsicum's pdfork() interface, _still_ hasn't been merged.

Regarding glibc, I'm not sure how much of an impact it would have on glibc. The particular case of open v openat is irrelevent because applications are supposed to be using openat in the Capsicum model, anyhow. The benefit of Capsicum is that it builds upon the existing, de facto file descriptors-as-capabilities model in Unix. From the perspective of libc, playing nice with Capsicum is roughly similar to refactoring to better leverage the latest evolutions of POSIX and privilege separation best practices. For example, use getrandom() instead of expecting to open /dev/urandom. And stop relying on /proc so heavily because it's not always visible. These are things glibc has to do, anyhow.