> http://outflux.net/teach-seccomp/ Посмотрел, спасибо. Что вывел для себя:
1. В примере разрешаются вызовы read, write. Это всё здорово, однако для stdin мне нужен только read, а для stdout только write. Тем не менее, этого ограничения не вводится. В Capsicum ограничиваются операции для каждого дескриптора в отдельности.
2. Разрешение exit, какого-то exit_group... Зачем? Почему они вообще требуют разрешения?
3. Куча каких-то вложенных структур, необходимых для инициализации защиты. Почему всё так сложно сделано?
4. Почему для того, чтобы посмотреть, каких системных вызовов мне ещё не хватает, я должен цеплять какой-то мутный объектник? Почему нельзя было сделать выделенный код возврата из вызова syscall ("Not permitted in capability mode", "Capabilities insufficient" в FreeBSD Capsicum)?
5. + if (errno == EINVAL)
+ fprintf(stderr, "SECCOMP_FILTER is not available. :(\n");
Ну да, конечно же, errno == EINVAL это лучший способ проверить, доступна ли фича для использования. Сравнить с feature_present("security.capability_mode") я оставлю в качестве самостоятельного упражнения.
Неделю назад я, когда читал доклад про Capsicum на BSD Day, сказал, что пока не смотрел, насколько seccomp filter отличается от seccomp, но подозреваю, что сильно лучше не стало. Я рад, что не соврал уважаемым слушателям.
С учётом того, что разработка Capsicum поддерживается в том числе и Google и в перспективе весьма массивно будет двигаться в ядро Linux, а равно как и в OpenBSD, я позволю себе дальше не заморачиваться с seccomp filter.
