The inherent fragility of seccomp()

Posted Nov 12, 2017 9:27 UTC (Sun) by roc (subscriber, #30627)
In reply to: The inherent fragility of seccomp() by wahern
Parent article: The inherent fragility of seccomp()

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.