firejail (и используемый там seccomp) на бумаге гибче, но на практике абсолютно убоги

Об проблемах с seccomp можно писать до бесконечности. Если вкратце...

Режим чёрного списка бесполезен: автор приложения запретит open() и stat(), а через пару релизов ядра выкатят какие-нибудь openat() и fstatat(), которые делают то же самое, но уже не блокируется фильтром. Упс...

Отдельные списки доступа для разных ABI. Если заранее не RTFM, можно легко оказаться в положении, когда твой sandbox обходится использованием версии того же системного вызова, но для 32-битной архитектуры. При этом у 32-битной и 64-битной архитектур могут сильно отличаться списки сисколов, — см. socket()

В теории, с seccomp можно делать очень много чего, — например разрешать доступ к отдельным путям. На практике, ­— если у системного вызова несколько вариантов (это к слову про stat, fstat, newstat, fstatat и т.д.), то придётся писать отдельные фильтры для каждого варианта. Из-за этого никто не заморачивается со сложными фильтрами.

Создание _работающего_ белого списка seccomp — практически нереальная задача, если ты не разработчик своей ОС, и не линкуешь всё приложение статически (включая libc). PAM, NSS, поддержка локалей в glibc и и даже банальная ленивая загрузка библиотек через dlopen() ставят firejail раком, — белый список быстро разрастается до 100% поддерживаемых ядром системных вызовов. Хочешь слинковать с  libpng.so? Разрешай в конфиге весь набор вызовов для работы с ФС. В новой версии glibc добавили новую фичу, требующую чтения нового файла конфига? Весь твой sandbox накрывается медным тазом с очередным апдейтом системы.

Фактически, разработчики ядра Linux свалили весь груз проблем по написанию seccomp-правил на головы прикладных программистов. В его текущем виде seccomp годится только для изоляции процесса javascript-интерпретатора (и то — с очень большим списком оговорок). По сравнению с ним, unveil() — просто мечта.