Поработал с seccomp

https://en.wikipedia.org/wiki/Seccomp
Решил пощупать какого это жить с seccomp подсистемой и насколько сложно
с ней работать. В принципе ничего сложного (если с libseccomp): просто
как-бы задаётся firewall системных вызовов и (опционально) их аргументов.
Можно одной строкой разрешать хоть делать все read(), либо read в
котором определённый аргумент равен какому-то значению -- чётко
фильтровать и файловые дескрипторы так можно например.

Но в целом очень геморройно, ибо на самом деле ты не знаешь какие вызовы
кто и как будет делать. Seccomp-ed программа будет libc-специфична. Ибо
glibc для waitpid() делает wait4() на самом деле, как и на других
вызовах выполняет не то что написано на экране. PCSC-демон... да откуда
я знаю как конкретно и как именно он работает с сокетами и логами?
Только смотреть исходный код всего этого. Вот и у меня всё свелось к
запуску, падению, смотрению в /var/log/audit.log, поиску информации об
убийстве из-за запрещённого syscall-а, поиск syscall-а по номеру чтобы
понять что надо прописать в seccomp-ed программу. А ведь ещё и
какие-нибудь крайние ситуации особые могут быть, которые всплывут в
самый неожиданный момент.

Гранулярность конечно отличная у него. Но, пишут, что обеспечить
фильтрацию по путям до файлов в нём проблематично. Не пробовал.

Capsicum (793966ed64c5a6884e7f1a3d5491a7be4b3eea5f) фильтрует действия
над файловыми дескрипторами только, которые правда могут не только файлы
представлять. Ну и ограничивает множество syscall-ов тоже. Не такой
"сильный" sandbox, но для своих синтетических задач с ним было гораздо
проще работать. pledge имеет ещё меньшую гранулярность, но с ним ещё
проще. Вот и получается дилемма: либо жутко геморройный и сложный
seccomp но с офигенной управляемостью, либо очень поверхностный pledge,
но который тривиально для большинства программ встраивать. С одной
стороны pledge круче, тем что хоть какой-то sandboxing и ограничения
предоставляет очень просто. С другой стороны seccomp круче, тем что всё
на свете можно зарезать в нём и ограничить. Для себя сделал вывод: всё
зависит от потребностей и архитектуры программы. Что-то на seccomp точно
будет не сложно переводить. Что-то на Capsicum совсем не сложно. Но если
архитектура программы совсем далека от privsep подхода, то будет тоже не
просто с ним. А pledge... лучше чем ничего, но в идеале бы что-нибудь
посерьёзнее.

Негатива от Seccomp особо нет. Кроме того, что он libc-specific будет,
как минимум. Но то что я делал на Capsicum в FreeBSD -- с seccomp-ом я
потратил во много раз больше времени, хотя получил ещё более tight
sandbox. И не потому что я поклонник FreeBSD, но Capsicum мне куда
больше понравился -- на нём хочется продолжать делать и писать privsep
программы. А Seccomp не вызывает желания возвращаться к нему. А вот
OpenBSD в целом не то чтобы расстроила, но я сильно охладел к ней.
Рассматривать как платформу для запуска своего софта я бы не стал, хотя
уважение и симпатия ко многим их подходам у меня большие.