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

Ну вон в Андроиде сделали. И насколько я вижу поверхностно, там это просто реализовано за счёт того что каждое приложение запускается под своим пользователем, благодаря чему приложения не могут лазить друг к другу в директории. Правда это и свои неудобства добавляет. Там меня это бесит тем что я тоже не могу лазить в директории, «куда не положено».

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

Очевидно, что бы адекватные люди валили на бсд, ведь лялех почти готов для десктопа, ловить там нечего.

Ну вон в Андроиде сделали. И насколько я вижу поверхностно, там это просто реализовано за счёт того что каждое приложение запускается под своим пользователем, благодаря чему приложения не могут лазить друг к другу в директории. Правда это и свои неудобства добавляет. Там меня это бесит тем что я тоже не могу лазить в директории, «куда не положено».

Близко, но это немного не то.

Очевидно, что бы адекватные люди валили на бсд, ведь лялех почти готов для десктопа, ловить там нечего.

Ну OpenBSD для десктопа это так себе затея, если честно. Но тем не менее, хорошую идею-то почему бы не использовать?

Так вот — это реально мать его просто.

Ну так у OpenBSD простые потребности.

В то же время в лялехе уже пять разных вариантов sandbox и docker

Кстати, как там с докером в OpenBSD?

и все это добро нужно адаптировать под каждый дистр и программу.

Шо за бред...

Ну так у OpenBSD простые потребности.

Можно пример более сложных потребностей?

Кстати, как там с докером в OpenBSD?

Его там нет.

Шо за бред...

Ты мне сейчас начнешь лечить, что те же политики SeLinux не требуют адаптации при переходе от RHEL к условной Gentoo или что?

Ну так у OpenBSD простые потребности.

Можно пример более сложных потребностей?

Конечно. Всё, что не влезает в предопределенные promises.

Ты мне сейчас начнешь лечить,

Я не уверен, что смогу излечить тебя. По одной простой причине - я не вижу в твоей ауре следов чтения man seccomp.

В то же время в лялехе уже пять разных вариантов sandbox и docker, и все это добро нужно адаптировать под каждый дистр и программу

те же политики SeLinux не требуют адаптации при переходе от RHEL к условной Gentoo или что?

Я хочу сказать, что жалобы на проблемы «адаптации при переходе» в сравнении с OpenBSD звучат как-то бредово - придерживайся одной ОС, как в случае с OpenBSD, и проблем «адаптации при переходе» не будет.

И я хотел бы услышать об адаптации docker.

Конечно.

И где? :)

Я не уверен, что смогу излечить тебя. По одной простой причине - я не вижу в твоей ауре следов чтения man seccomp.

Ну ты в курсе, что seccomp периодически ломается при апдейтах glibc? Потому что glibc'шные функции частенько меняют внутренний набор сисколов? Не говоря уже о том, что фильтрация доступа к файловой системе через seccomp выглядит чуть сложнее, чем

if (unveil("/etc/passwd", "r") == -1)
    err(EXIT_FAILURE, "unveil");

Я хочу сказать, что жалобы на проблемы «адаптации при переходе» в сравнении с OpenBSD звучат как-то бредово - придерживайся одной ОС, как в случае с OpenBSD, и проблем «адаптации при переходе» не будет.

Пажжи. OpenBSD — операционная система с интеграцией всех компонентов. В Linux обычно ядро + куча разного барахла, даже libc местами отличаются. Поэтому если бы вместо SeLinux каждая программа sandbox'ила бы себя сама парочкой системных вызовов, жизнь была бы проще, не?

И я хотел бы услышать об адаптации docker.

Были какие-то идеи, но вообще я не помню, чтобы кто-то хотел этим заниматься всерьез.

[В БЗД все просто, как кирпич.]

В то же время в лялехе уже пять разных вариантов sandbox и docker, и все это добро нужно адаптировать под каждый дистр и программу. Вот почему так?

Ну дык. Потому что у бздей нет ни дробления усилий, ни ресурсов. Если в лялихе раскол сообщества выглядит как тонны флуда и соплей, драмы, Devuanы и прочий дебилизм, то в БЗД это, как понимаю, максимум один мужик, яростно чешущий бороду в преддверии тяжелого решения.

Я не уверен, что смогу излечить тебя. По одной простой причине - я не вижу в твоей ауре следов чтения man seccomp.

Ну ты в курсе, что seccomp периодически ломается при апдейтах glibc?

Не в курсе, но, в общем-то, пофиг. Если ты можешь доказать, что на seccomp невозможно сделать реализацию pledge и запихнуть ее в статическую библиотеку - you are welocome.

Пажжи. OpenBSD — операционная система с интеграцией всех компонентов

Gentoo - тоже ОС. И RHEL - тоже ОС, но другая. Когда ты пытаешься таскать политики между разными ОС, ожидай проблем. Проблем, которых у тебя не будет в случае одной ОС.

Поэтому если бы вместо SeLinux каждая программа sandbox'ила бы себя сама парочкой системных вызовов жизнь была бы проще, не?

Пажжи. Почему ты настаиваешь на sandboxing-е именно через SELinux, при том, что OpenBSD это делается через какой-то фильтр системных вызовов?

Не в курсе, но, в общем-то, пофиг. Если ты можешь доказать, что на seccomp невозможно сделать реализацию pledge и записхнуть ее в статическую библиотеку - you are welocome.

Я не говорил про невозможность :) Но реализация pledge() требует определенных усилий, и чаще всего все кладут на это болт. Это как с документацией — если писать её сложно, писать её никто не будет.

Gentoo - тоже ОС. И RHEL - тоже ОС, но другая. Когда ты пытаешься таскать политики между разными ОС, ожидай проблем. Проблем, которых у тебя не будет в случае одной ОС.

Если программа сама устанавливает политики (и заметь, никакого rocket science и BPF фильтрации — просто сделать unveil() на те файлы и директории, которые используются), то проблем не будет. Как это делает firefox, например. Его кастрированный sandboxing работает везде одинаково.

Пажжи. Плочему ты настаиваешь на sandboxing-е именно через SELinux, при том, что OpenBSD это делается через какой-то фильтр системных вызовов?

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

Не в курсе, но, в общем-то, пофиг. Если ты можешь доказать, что на seccomp невозможно сделать реализацию pledge и записхнуть ее в статическую библиотеку - you are welocome.

Я не говорил про невозможность :) Но реализация pledge() требует определенных усилий

Ясно. То есть sandoxing есть, но не как в OpenBSD, подло-то как.

Плочему ты настаиваешь на sandboxing-е именно через SELinux, при том, что OpenBSD это делается через какой-то фильтр системных вызовов?

Потому что это единственный распространенный способ sandboxing'а в Linux.

Тогда жалуйся не на то, что в Linux не могут что-то, а на то, что не могут что-то так, как ты хочешь.

Seccomp встроен в пару десятков программ и везде реализован с разной степенью упоротости.

Нерелевантно.

Ясно. То есть sandoxing есть, но не как в OpenBSD, подло-то как.

Есть способы его сделать, но они настолько сложные, что их редко кто делает, тем более делает правильно. Да.

Нерелевантно.

Ещё как релевантно. Если sandboxing' для твоей тулзы занимает несколько сот строк кода, который нужно поддерживать в рабочем состоянии между дистрибутивами, то кто вообще будет этим заниматься-то?

Думаю, мы пришли к тому, что sandboxing в Linux осилили, но он не такой, как в OpenBSD.

они настолько сложные, что их редко кто делает, тем более делает правильно. Да.

Сделай реализацию pledge и прославь свое имя в веках же.

Seccomp встроен в пару десятков программ и везде реализован с разной степенью упоротости.

Нерелевантно.

Ещё как релевантно. Если sandboxing' для твоей тулзы занимает несколько сот строк кода

Ты говорил, что seccomp в других программах упоротый. Это нерелевантно - в твоей-то так не будет.

Думаю, мы пришли к тому, что sandboxing в Linux осилили, но он не такой, как в OpenBSD.

Поэтому он в основном есть тока в RHEL в виде selinux и в браузерах в виде отключаемого через GUI seccomp (лол), да?

Сделай реализацию pledge и прославь свое имя в веках же.

Кто-то уже пытался, но пришел к выводу, что без поддержки со стороны glibc это сложновато выходит. А поцонам из glibc видимо не до того.

Ты говорил, что seccomp в других программах упоротый. Это нерелевантно - в твоей-то так не будет.

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

Ты ещё про firewall вспомни.

sandboxing это для не осиливших контейнеры ?

sandboxing это для не осиливших контейнеры ?

Ты cat в контейнере собрался запускать? Потому что основной профит простого sandboxing'а в том, чтобы не допустить вот такой вот ерунды: https://holeybeep.ninja/

Ты ещё про firewall вспомни.

Ооо да.

так sandboxing вам нужен для подозрительных приложений или для cat ?

так sandboxing вам нужен для подозрительных приложений или для cat ?

Для cat, beep и прочих dhclient с nginx. Потому что основной профит sandboxing'а в том, чтобы защитить систему от code execution. Подозрительный софт я могу и в виртуалке запустить.

Думаю, мы пришли к тому, что sandboxing в Linux осилили, но он не такой, как в OpenBSD.

Поэтому он в основном есть тока в RHEL в виде selinux и в браузерах в виде отключаемого через GUI seccomp (лол), да?

Не знаю, но думаю, что нет. В браузерах для OpenBSD есть pledge? unveil?

Сделай реализацию pledge и прославь свое имя в веках же.

Кто-то уже пытался, но пришел к выводу, что без поддержки со стороны glibc это сложновато выходит.

Детали есть?

меня скорее всего поимеют через очередную идиотскую дыру в beep или каком-нибудь dhclient.

Если ты хочешь добавить sandboxing во все приложения, запущенные у тебя на машине, это вообще другая проблема, чем «когда в Linux осилят sandboxing, в OpenBSD сделали же pledge».

Не знаю, но думаю, что нет. В браузерах для OpenBSD есть pledge? unveil?

Внезапно, да. Они это даже замержили в апстрим.

Детали есть?

Чувак писал, что слишком большой разброс сисколов между разными версими glibc и разными libc.

Если ты хочешь добавить sandboxing во все приложения, запущенные у тебя на машине, это вообще другая проблема, чем «когда в Linux осилят sandboxing, в OpenBSD сделали же pledge».

Это проблема удобства и распространенности best practices, на самом-то деле.

Поэтому он в основном есть тока в RHEL в виде selinux и в браузерах в виде отключаемого через GUI seccomp (лол), да?

Не знаю, но думаю, что нет. В браузерах для OpenBSD есть pledge? unveil?

Внезапно, да.

Уже целый месяц: https://bugzilla.mozilla.org/show_bug.cgi?id=1457092 ? Кстати, тоже выглядит отключаемым через GUI.

Чувак писал, что слишком большой разброс сисколов между разными версими glibc и разными libc.

Хм. Ну, ему виднее, но kernel ABI стабилен и лично я не вижу проблем дергать сисколл напрямую.

Это проблема удобства и распространенности best practices, на самом-то деле.

Т.е. это проблема культуры. «Почему вы, линуксоиды, такие бескультурные!!11».

Уже целый месяц: https://bugzilla.mozilla.org/show_bug.cgi?id=1457092 ? Кстати, тоже выглядит отключаемым через GUI.

Нет. pledge() не может быть откачен назад.

Хм. Ну, ему виднее, но kernel ABI стабилен и лично я не вижу проблем дергать сисколл напрямую.

Это все здорово, конечно, но когда ты дергаешь функцию glibc и получаешь abort'ом по роже — это не ок. Как-бы подразумевается, что pledge() должен позволять тебе пользоваться libc в рамках задуманного.

Т.е. это проблема культуры. «Почему вы, линуксоиды, такие бескультурные!!11».

Почему ты опять говоришь сам с собой?

Уже целый месяц: https://bugzilla.mozilla.org/show_bug.cgi?id=1457092 ? Кстати, тоже выглядит отключаемым через GUI.

Нет. pledge() не может быть откачен назад.

Да. Включать его или нет, задается через preferences.

когда ты дергаешь функцию glibc и получаешь abort'ом по роже — это не ок.

?

Т.е. это проблема культуры. «Почему вы, линуксоиды, такие бескультурные!!11».

Почему ты опять говоришь сам с собой?

Это ирония. Она не обязательна для понимания.

Вот почему так?

Скорее всего потому, что это очень мало кому нужно. Это действительно странные хотелки. Но если кто-то пришлёт патч, то фанаты секьюрити его примут. Почему нет?

там это просто реализовано за счёт того что каждое приложение запускается под своим пользователем

разве оно не на selinux?

Вот почему так?

Потому что Linux в корне своей идеологии очень гибкий. Если где-то какой-то функционал не нужен, его с большой вероятностью можно отключить в compile-time.

Так и случилось с песочницами. Есть seccomp, cgroups, selinux, apparmor, smack и так далее. Каждый решает задачу для которой был создан, но во всех них можно вполне реализовывать песочницу и более того не ограничиваться одним. Android, например, вполне использует первые три.

Cgroups не песочница. Namespace'ы да.

Ну, ограничить им процесс в ресурсах можно. Частмчно поставленную задачу это решает. Остальное можно решить тем же SELinux.

Ограничение ресурсов это слегка про другое. Если ты процессу не дашь fd, то он максимум только с std потоками и сможет работать :)

Я прочитал комментарий выше. Да, если нужно предотвратить RCE, то cgroups тут ни при чём. :)

Вообще это все напоминает историю с sysfs. Сперва было прикольно, а потом выяснилось, что control plane теперь состоит из syscall/ioctl/sysctl/netlink/procfs/sysfs/configfs/debugfs/efivarfs/bpf. И все это добро не только взаимодополняет друг-друга, но местами дублирует.

А разве lxc containers (или как там оно называется) это не то, что ищет тс?

разве оно не на selinux?

Оно там есть, но в каких целях используется не в курсе. Может и как дополнительная изоляция. Но обычные приложения в четвёртом андроиде помню работали каждое под своим пользователем. У меня сейчас восьмёрка и там теперь в top не видно процессов других приложений, только текущего. Поскрывали всё зачем-то.

набрал top из-под рута, похоже вы правы

Скатили тему в SJW, что за общество.

pledge

seccomp-bpf

unveil

unshare(CLONE_FS)

seccomp-bpf

Покажи, пожалуйста, пример для

pledge("stdio tmppath");

Алсо это не в bpf недавно дыру нашли?

unshare(CLONE_FS)

Разве есть возможность оставить доступ к /dev/foobar, но запретить доступ к остальным файлам?

Покажи пожалуйста пример для pledge(«stdio tmppath»);

https://github.com/torvalds/linux/blob/master/samples/seccomp/bpf-fancy.c

Алсо это не в bpf недавно дыру нашли?

Какая разница?

Разве есть возможность оставить доступ к /dev/foobar, но запретить доступ к остальным файлам?

mount --bind

https://github.com/torvalds/linux/blob/master/samples/seccomp/bpf-fancy.c

Не вижу там сисколов для манипуляций над файлами. Ты уверен, что это полный пример?

mount --bind

Разве это не требует рута?

Не вижу там сисколов для создания директорий. Ты уверен, что это полный пример?

Нет, конечно. Допиши сам.

Разве это не требует рута?

Требует. Да, не очень понятно, что с этим делать. Впрочем, можно накостылять на seccomp-bpf :)

Нет, конечно. Допиши сам.

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

Требует. Да, не очень понятно, что с этим делать. Впрочем, можно накостылять на seccomp-bpf :)

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

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

Нет. Мы говорим о JIT-компиляторе байткода с правами ядра.

Ты cat в контейнере собрался запускать?

А как ты его собрался сандбоксить? По определению может читать любой файл и писать любой файл. Можно запретить exec и fork. Но это не помешает добавить бяку в .profile.

tailgunner сколько тебе заплатили СЖВ за сокрытие правды и прикрытие их жирных жоп?

А разве lxc containers (или как там оно называется) это не то

Как я понял, он про использование для всего и вся. А в LXC ты не будешь заворачивать каждую отдельную утилиту.

А как ты его собрался сандбоксить? По определению может читать любой файл и писать любой файл. Можно запретить exec и fork. Но это не помешает добавить бяку в .profile.

Помешает:

pledge("stdio");
for (int i = 0; i < nfiles; ++i)
    unveil(files[i], "r");
unveil(NULL, NULL);

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

Много лет назад предавался аналогичным размышлениям: https://habr.com/post/113143/
Ничего не зная про pledge() и unveil().