Почему в лялихе все никак не могут осилить sandboxing?

Твоя программа может только читать файлы, но не писать в них.

Да... Глупость написал про cat. Он же только читает и на стандартный вывод, а пишет уже bash какой-нибудь.

Да... Глупость написал про cat. Он же только читает и на стандартный вывод, а пишет уже bash какой-нибудь.

И это тоже, да. Но тебе достаточно ограничить доступный ей набор файлов теми, что ты ей в cmdline передал. Ну и везде O_RDONLY, да.

Скорее всего потому, что это очень мало кому нужно.

Безопасная система мало кому нужна. Эм... Ну ок.

Я это все к тому, что seccomp требует изрядных усилий от разработчиков. И в нем легко облажаться.

seccomp (оригинальный) никаких усилий не требует, это механизм с семантикой вкл/выкл. А seccomp-bpf — это механизм, а ты хочешь политику, чтобы за тебя решили, как сгруппировать сисколлы. Сделай libpledge, если так хочешь.

На секунду, мы говорим об интерпретаторе байткода с правами ядра.

Во-первых, нет (см. выше). Во-вторых, не очень понимаю, что ты хочешь этим сказать.

seccomp (оригинальный) никаких усилий не требует, это механизм с семантикой вкл/выкл. seccomp-bpf — это механизм, а ты хочешь политику, чтобы за тебя решили, как сгруппировать сисколлы. Сделай libpledge, если так хочешь.

Я хочу вменяемый sandboxing, который я, как разработчик, смогу легко и просто использовать в своей программе, шоп она потом работала в любом дистрибутиве без костылей. Морда к BPF это ни разу не оно, потому что требует слишком много усилий, а поведение будет различаться в разных версиях glibc и между разными libc.

Во-первых, нет (см. выше).

Ну я бы послушал, чем интерпретатор отличается от JIT-компилятора с точки зрения безопасности, лол.

Во-вторых, не очень понимаю, что ты хочешь этим сказать.

Ну как бы штуковина, способная выполнять произвольный код, в которой регулярно находят переполнения интов и проблемы с проверкой граничных условий... я даже не знаю, что может пойти не так :)

Его там нет.

Не совсем верно → https://medium.com/@dave_voutila/docker-on-openbsd-6-1-current-c620513b8110

Там Alpine в vmd. Я-то понадеялся.

Именно так. От всей этой безопасности в 99% случаев один геморрой.

Я тут начал писать тебе ответ, но потом понял, что tailgunner выше по треду уже сказал всё, что можно было сказать. Ты хочешь взаимоисключающих параграфов.

Ну как бы штуковина, способная выполнять произвольный код, в которой регулярно находят переполнения интов и проблемы с проверкой граничных условий... я даже не знаю, что может пойти не так

У тебя trusted байткод.

Я тут начал писать тебе ответ, но потом понял, что tailgunner выше по треду уже сказал всё, что можно было сказать. Ты хочешь взаимоисключающих параграфов.

Но в OpenBSD-то сделали.

У тебя trusted байткод.

С чего это вдруг?

У тебя trusted байткод.

С чего это вдруг?

Байткод, естественно, верифицируется перед трансляцией.

Тот же подход, что и на маках. Докер всё таки до мозга костей вендор-лок на линукс.

Байткод, естественно, верифицируется перед трансляцией.

https://www.cvedetails.com/cve/CVE-2017-16995/

The check_alu_op function in kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging incorrect sign extension.

:)

Ху вотчез зе ватчмен, лол.

Ужас какой. Наверное, теперь ты никогда не станешь передавать в BPF код, полученный от пользователя.

Ху вотчез зе ватчмен, лол.

За собой следишь ты сам. Хочешь sandboxing - не передавай в ядро кривые программы.

Ужас какой. Наверное, теперь ты никогда не станешь передавать в BPF код, полученный от пользователя.

Наверное стоит подумать о том, стоит ли использовать BPF для решения задачи, с которой можно справиться и без него.

За собой следишь ты сам. Хочешь sandboxing - не передавай в ядро кривые программы.

То есть в попытке запустить безопасный cat с правами юзера мы только что дошли до момента, когда нам нужно защищаться от потенциального user-assisted code execution с правами ядра? Все, что нужно знать о безопасности в лялехе :D

Наверное стоит подумать о том, стоит ли использовать BPF для решения задачи, с которой можно справиться и без него.

Ну, подумай. Начни с оценки других средств, которые у тебя есть (в Linux, естественно).

То есть в попытке запустить безопасный cat с правами юзера мы только что дошли

«Мы» точно не доходили. Я к проектировании «безопасного cat» не участвовал.

Все, что нужно знать о безопасности в лялехе :D

Ну вот ты и сказал, что хотел. Зачем так долго ломался?

У тебя trusted байткод.

С чего это вдруг?

Я не очень понял, так от кого мы защищаемся? От того, кто будет ломать наш софт, или от авторов софта?

Я не очень понял, так от кого мы защищаемся? От того, кто будет ломать наш софт, или от авторов софта?

От случайной ошибки, которую используют против нас. Если у нас нет уверенности в нашем коде, с чего вдруг у нас есть уверенность в нашем bpf коде?

От случайной ошибки, которую используют против нас. Если у нас нет уверенности в нашем коде, с чего вдруг у нас есть уверенность в нашем bpf коде?

Пару сообщений назад ты говорил что-то про безопасность BPF-компилятора. Определись уже.

с чего вдруг у нас есть уверенность в нашем bpf коде?

С того же, с чего у нас есть уверенность в реализации pledge(). Этого кода меньше, он реже меняется, проще верифицируется, можно вынести в отдельную библиотеку, попросить сесурити-людей проаудировать...

С чем?

С моделью угрозы.

Типа JIT проанализировать проще, чем тупой код на паре десятков ифов? Сирисли?

BPF программа может быть выполнена неправильно из-за дыры. Либо ты недостаточно хорошо отфильтруешь все корнер-кейсы с кучей сисколов. Вот тебе и вся модель угрозы.

с чего вдруг у нас есть уверенность в нашем bpf коде?

Типа JIT проанализировать проще

BPF программа может быть выполнена неправильно из-за дыры. Либо ты недостаточно хорошо отфильтруешь все корнер-кейсы с кучей сисколов. Вот тебе и вся модель угрозы.

Нет, это не модель угрозы.

А?

Нет, это не модель угрозы.

Лол. Ну ладно.

Проспись, протрезвей, протри глаза... я не знаю, с чем там у тебя проблемы, это в любом случае не ко мне.

Проспись, протрезвей, протри глаза... я не знаю, с чем там у тебя проблемы.

С собеседником, лол. Если бы он умел считать до двух, то понял бы, что сложность BPF-программ и дырявость самого BPF — разные проблемы, тем не менее связанные одним общим элементом — BPF.

Правда кто-то мне говорил что в обычных линуксах это бессмысленно из-за дырявых иксов (не помню что имелось в виду).

Просто этого кого-то в детстве иксы изнасиловали.

Просто этого кого-то в детстве иксы изнасиловали.

Ты ходил к психологу?

Бесполезно. Ты хочешь надежный и удобный инструмент с целью практического использования в коде, а твои оппоненты хотят делать умное лицо с целью поразвлечься троллингом. Давать вот такие ссылки — https://github.com/torvalds/linux/blob/master/samples/seccomp/bpf-fancy.c — в качестве обоснования, что в линаксе всё збс, это ж какой жирноты надо быть?! С этими людьми нечего обсуждать.