Что: d045feee660377eb59074eefd680d8ce98c3c66f
Когда: 2021-03-20 12:14:22+03:00
Темы: bsd c
Поработал с 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 в целом не то чтобы расстроила, но я сильно охладел к ней. Рассматривать как платформу для запуска своего софта я бы не стал, хотя уважение и симпатия ко многим их подходам у меня большие.
Сгенерирован: SGBlog 0.34.0