The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Для FreeBSD развивается механизм изоляции, похожий на pledge и unveil

03.04.2022 10:26

Для FreeBSD предложена реализация механизма изоляции приложений, напоминающего развиваемые проектом OpenBSD системные вызовы pledge и unveil. Изоляция в pledge осуществляется через запрет обращения к неиспользуемым в приложении системным вызовам, а в unveil через выборочное открытие доступа только для отдельных файловых путей, с которыми может работать приложение. Для приложения формируется подобие белого списка системных вызовов и файловых путей, а все остальные вызовы и пути запрещаются.

Отличие развиваемого для FreeBSD аналога pledge и unveil сводится к предоставлению дополнительной прослойки, позволяющей изолировать приложения без внесения изменений в их код или при минимальных изменениях. Напомним, что в OpenBSD pledge и unveil нацелены на тесную интеграцию с базовым окружением и применяются через добавление специальных аннотаций в код каждого приложения. Для упрощения организации защиты фильтры позволяют обойтись без детализации на уровне отдельных системных вызовов и манипулировать классами системных вызовов (ввод/вывод, чтение файлов, запись файлов, сокеты, ioctl, sysctl, запуск процессов и т.п.). Функции ограничения доступа могут вызываться в коде приложения по мере выполнения тех или иных действий, например, доступ к сокетам и файлам может закрываться после открытия нужных файлов и установки сетевого соединения.

Автор порта pledge и unveil для FreeBSD намерен предоставить возможность изоляции произвольных приложений, для чего предложена утилита curtain, позволяющая применять к приложениям правила, определённые в отдельном файле. Предложенная конфигурация включает файл с базовыми настройками, определяющими классы системных вызовов и типовые файловые пути, специфичные для определённых применений (работа со звуком, сетевое взаимодействие, вывод в лог и т.п.), а также файл с правилами доступа конкретных приложений.

Утилита curtain может применяться для изоляции большинства немодифицированных утилит, серверных процессов, графических приложений и даже целых сеансов рабочего стола. Поддерживается совместное использование curtain с механизмами изоляции, предоставляемыми подсистемами Jail и Capsicum. Также возможна организация вложенной изоляции, когда запускаемые приложения наследуют выставленные родительскому приложению правила, дополняя их отдельными ограничениями. Некоторые операции ядра (средства отладки, POSIX/SysV IPC, PTYs) дополнительно защищаются при помощи механизма барьеров, не позволяющего обращаться к объектам ядра, созданным не текущим или родительским процессом.

Процесс может самостоятельно настроить собственную изоляцию при помощи вызова curtainctl или используя предоставляемые библиотекой libcurtain функции pledge() и unveil(), аналогичные подобным функциям из OpenBSD. Для отслеживания блокировок в процессе работы приложения предусмотрен sysctl 'security.curtain.log_level'. Доступ к протоколам X11 и Wayland включается отдельно через указание при запуске curtain опций "-X"/"-Y" и "-W", но поддержка графических приложений ещё не достаточно стабилизирована и имеет ряд нерешённых проблем (проблемы в основном проявляются при использовании X11, а поддержка Wayland реализована значительно лучше). Пользователи могут добавить дополнительные ограничения через создание локальных файлов с правилами (~/.curtain.conf). Например, для разрешения записи из Firefox только в каталог ~/Downloads/ можно добавить секцию "[firefox]" с правилом "~/Downloads/ : rw +".

Реализация включает в себя модуль ядра mac_curtain для мандатного контроля доступа (MAC, Mandatory Access Control), набор патчей для ядра FreeBSD с реализацией необходимых обработчиков и фильтров, библиотеку libcurtain для использования функций pledge и unveil в приложениях, утилиту curtain, примеры файлов конфигурации, набор тестов и патчи для некоторых программ в пространстве пользователя (например, для использования $TMPDIR с целью унификации работы с временными файлами). По возможности автор намерен свести к минимуму число изменений, для которых требуется применение патчей к ядру и приложениям.

  1. Главная ссылка к новости (https://lists.freebsd.org/arch...)
  2. OpenNews: OpenBSD развивает Pledge, новый механизм изоляции приложений
  3. OpenNews: Для ядра Linux предложена система изоляции приложений Capsicum, изначально созданная для FreeBSD
  4. OpenNews: В состав OpenBSD-Current добавлен механизм защиты RETGUARD
  5. OpenNews: Планы по усилению механизма защиты W^X в OpenBSD
  6. OpenNews: В OpenBSD предложен новый системный вызов unveil() для изоляции ФС
Лицензия: CC-BY
Наводку на новость прислал аноним
Тип: К сведению
Короткая ссылка: https://opennet.ru/56958-pledge
Ключевые слова: pledge, unveil, freebsd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:16, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Зато не apparmor/selinux, воть!
     
     
  • 2.6, Аноним (6), 11:47, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как там было в «Хоббите»... Ножи — не вилки, а скалы — не опилки.
     
     
  • 3.7, Аноним (6), 11:53, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ножи^W Орлы
     
  • 2.9, Аноним (-), 12:02, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> It can be broken up in 4 parts: 1) A [b]MAC[/b] module that implements most of the functionality.  2) The userland library, sandboxing utility, configs and tests.  3) Various kernel changes needed to support it (including new MAC handlers and extended syscall filtering).  4) Small changes/fixes to the base userland

    ...
    >> About the kernel-side parts:
    >> Most of the implementation is in a separate mac_curtain module, but it also needed some changes spread out in the kernel to support it.

    ...
    man mac
    >> HISTORY
    >>     The TrustedBSD MAC Framework first appeared in FreeBSD 5.0 (2003)

    ...

    > Зато не apparmor/selinux, воть!

    Зато очередной лапчато-опеннетный онализ на основе знакомых слов из заголовка!


     
  • 2.15, Аноним (15), 13:24, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Зато не apparmor/selinux, воть!

    Сабж надо сравнивать не с MAC, а с механизмами syscall-изоляции. В Linux это Seccomp, во фре - Capsicum.

    By the way, у лапчатых с этим уже много лет как все просто - пишешь в юнит-файл SystemCallFilter= (для системных вызовов) и InaccessiblePaths= (для файловой системы), и ты в домике.

     
     
  • 3.54, Аноним (54), 12:32, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А домик как у ниф-нифа или как у наф-нафа?
     
     
  • 4.55, Аноним (15), 16:46, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если серьезно, то фильтрация системных вызовов и фильтрация обращений к файловой системе - это только элементы в комплексной защите. Есть IPC, есть сеть, которые надо тоже ограничивать. Есть опции компилятора для затруднения атак. Ну и ресурсы надо квотировать, чтобы DoS всей системы не было.
     

  • 1.2, _kusb (ok), 11:26, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Очень глупый вопрос - но чем это отличается от chroot? Ещё вспомнил про контрольные группы, какие слова знаю - офигеть.
     
     
  • 2.4, qew (?), 11:44, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Чистый chroot не предел для взлома еще с 90-х. Зная невероятный дебилизм ядра, скорее всего до сих пор осталось дыркой. Но в его исходниках каждый день не роюсь, это к диванным экспертам.
    Представляешь ютуб в чруте? )

    chroot средствами cgroups - то же самое извращение, но поговаривают вполне можно уже даже полагаться в НЕкритичных ситуациях. Группы ресурсов вообще для другого делали, но они неплохое продолжение получили в виде докера - просто и чаще всего таки удобно.

    Для серьёзных вещей, что-то более крутое чем selinux или apparmor представить сложно. Но для школьников то докеризацию придумают и они свято верят в непогрешимость то еще чего. Больше подходит вайновое приложение или игрушку туда пихнуть или на сервере юзать. Большие как юзали SE таки будут юзать - своими, со знанием дела, с самого начала, для своих, и по взрослому.

     
     
  • 3.5, йцу (?), 11:45, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тут чрут подкреплённый хуками к ядру. Ну типа стопудовее, пластичнее может даже и безопаснее.
    Чистый чрут - это крайне примитивная конструкция.
     
  • 3.14, Легивон (?), 13:19, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Но для школьников то докеризацию придумают и они свято верят в непогрешимость то еще чего

    Не для школьников, а для senior yaml developer'ов.
    И докер это вообще не про изоляцию. Это 90% случаев про доставку.

     
     
  • 4.19, Аноним (15), 13:31, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Не для школьников, а для senior yaml developer'ов.

    До этого тридцать лет девелопили на шелле. Теперь будут сколько-то лет девелопить на ямле. Игра была равна - играли два <...> (а можно просто не подпускать к программированию людей, не знающих хотя бы одного полноценного ЯП).

    > И докер это вообще не про изоляцию. Это 90% случаев про доставку.

    Про изоляцию тоже, но не для безопасности, а для удобства. С ним можно спокойно запустить на хосте хоть пять разных веб-серверов с настройками "из коробки", и они не подерутся на 80 и 443 порты. (Более практичный пример - при обновлении программы, старый и новый экземпляр могут пересекаться по времени без конфликтов)

     
     
  • 5.28, Онаним (?), 15:45, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Конкретно доскер к изоляции вообще никакого отношения не имеет.
     
     
  • 6.31, Аноним (31), 16:18, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пацаны во дворе рассказали?
     
     
  • 7.41, Онаним (?), 21:26, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, тебе как заядлому дворовому обитателю - скорее всего виднее, да.
    А вообще доскер - это костылик конфигурации ядерной изоляции, а не сама изоляция.
     
  • 6.35, Аноним (35), 19:12, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Изначально это объявлялось именно как изоляция. Это потом, когда изоляция оказалась неизоляцией (в силу кривости реализации), оставили роль деплоя приложений. Народ так заюзал, на том и сошлись.
     
     
  • 7.42, Онаним (?), 21:27, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Изоляция - это LXC, namespaces и прочая обвязка, так-то. Доскер её только конфигурирует.
    "Объявлялся как изоляция" он для старших специалистов по yaml, видимо.
     
     
  • 8.43, Онаним (?), 22:10, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И даже про LXC я не прав, LXC такой же костылик Короче именно ядерная составляю... текст свёрнут, показать
     
     
  • 9.48, Аноним (15), 03:18, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Может, вам сторит все-таки подучить матчасть, прежде чем встревать в интеллектуа... текст свёрнут, показать
     
     
  • 10.50, Онаним (?), 07:58, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Может тебе для начала русский подучить, сторит ... текст свёрнут, показать
     
  • 5.30, Аноним (31), 16:17, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > полноценного ЯП

    Полноценность ты будешь определять, конечно же, да?

     
     
  • 6.40, anonfhjvxd (?), 21:03, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB
     
  • 4.27, Онаним (?), 15:44, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    senior yaml developer - это пять, возьму на заметку, спасибо
     
  • 4.36, Аноним (35), 19:15, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Не для школьников, а для senior yaml developer'ов.

    Сениёр ямль девелопер-это не школьник, это посетитель детского сада. Как и автор термина.

     
     
  • 5.45, Аноним (15), 03:10, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тем не менее, платят им раз в десять больше, чем senior shell developer-ам.
     
  • 3.22, Аноним (15), 13:38, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > chroot средствами cgroups - то же самое извращение, но поговаривают вполне можно уже даже полагаться в НЕкритичных ситуациях. Группы ресурсов вообще для другого делали, но они неплохое продолжение получили в виде докера - просто и чаще всего таки удобно.

    Вы путаете педали. cgroups не обеспечивают chroot, для этого есть namespaces (конкретно - mount namespace).

    > можно уже даже полагаться в НЕкритичных ситуациях

    В некритичных ситуациях хватит "нет там дыр, зуб даю".
    А в критичных всегда работает комплекс мер.

     
  • 3.39, Аноним (39), 19:54, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, больших пользователей SELinux особо нет, либо они тщательно законспир... большой текст свёрнут, показать
     
  • 2.34, мишалипут (?), 17:26, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это не аналог chroot, это аналог seccomp (ну и вторая штука аналог apparmor/selinux)
     

  • 1.3, Аноним (3), 11:37, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Capsicum'a должно быть всем достаточно.
     
  • 1.8, В.Ж. (?), 11:59, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну то есть вот это «для немодифицированных программ» рубит основную идею, лежащую в основе pledge: многим приложениям повышенные привилегии требуются только на начальном этапе работы, когда происходит инициализация. И извне этот момент не узнать, поэтому при внешнем ограничении привилегий приходится давать максимум из возможно требуемых привилегий.

    Пользу сабжа вижу только в возможности большего распространения API pledge/unveil, что в итоге может побудить большее количество разработчиков ПО обратить на него внимание... а может и не побудить.

     
     
  • 2.10, Аноним (10), 12:05, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Звучит как unshare. Там тоже можно запустить любую излишне любопытную программу в изолированном немспейсе. С точки зрения программы оно как бы и есть, но с реальной системой не пересекается.
     
     
  • 3.17, Аноним (15), 13:27, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    unshare - это тот же механизм, который лежит в основе LXC и докера. И нет, он не отменяет и не заменяет фильтрации системных вызовов. Эти два подхода работают вместе, дополняя друг друга.
     
     
  • 4.20, Аноним (10), 13:33, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Фильтрация системных вызовов в свою очередь звучит не то как apparmor, не то как yama.
     
     
  • 5.24, Аноним (15), 13:47, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не, звучит как seccomp.
    Apparmor и yama - это модули MAC, более высокий уровень абстракции. Тоже могут фильтровать системные вызовы, но там это задается косвенно, поэтому такой гибкости, как seccomp, не дает.
     
  • 2.11, qwe (??), 12:08, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В таком случае как всегда, пока в gcc не встроят не взлетит. А какие существуют способы временно давать повышение привелегий с определённым райдером мест куда можно лезть при этом, а дальше пахать как обычно?
     
     
  • 3.18, Аноним (18), 13:29, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Разбить на бинарники дать разные права вызывать разные бинари в зависимости от ситуации.  И так по нисходящей велосипедировать.  
     
     
  • 4.21, Аноним (15), 13:34, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А потом захочется
    1. Бинарники, решающие одни и те же задачи по преднастройке окружения, объединить в один универсальный
    2. ???
    3. Мужики, у нас комбайн, возможно, systemd, по коням!
     
  • 4.33, Аноним (33), 17:11, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А в винде можно в случае необходимости вызвать диалог повышения привелегий и непривилегированный процесс сделать привилегированным, в отличие от этих ваших юниксов...
     
     
  • 5.47, Аноним (15), 03:16, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А в этих ваших юниксах для того же самого уязвимости всякие ищут, да.
     
  • 2.13, Аноним (15), 13:19, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > И извне этот момент не узнать, поэтому при внешнем ограничении привилегий приходится давать максимум из возможно требуемых привилегий.

    Для этого уже давно придумали простое решение, называется privilege separation.
    Когда предварительную настройку выполняет один процесс, а основную работу другой.
    Можно пойти по unix way и написать для каждого демона свой инициализатор, можно забить и сделать init-комбайн, который и сокеты откроет, и лимиты выставит, и cgroups создаст, и namespaces настроит, не суть.

     

  • 1.12, Sadok (ok), 12:53, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Расскажите ему про jail.
     
     
  • 2.23, Аноним (-), 13:44, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Расскажите ему про jail.
    >> It can be used at the same time as jails and Capsicum (their

    restrictions are also enforced on top of it).
    ...
    >> (Автор в списке рассылок) Also, if you combine curtains with chroots you kind of get jails. It's chroot escape-proof because unveils deny access to the outer directories like any other.  Privileges are restricted.  It doesn't have all the features of jails but it's very jail-like. Just to say, the MAC framework was pretty close to being able to implement jails too.

    Видимо, прочитал на опеннете и полез смортеть. Интересно, что бы он делал без ценных советов опеннетчиков?

     

  • 1.25, Аноним (25), 13:57, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Еще одна реализация по типу capsicum заточенная на программистов, а не админов?
    Ехх, жаль что кроме jail во фришке нет других механизмов изоляции.
     
  • 1.29, Смузихлёб (?), 15:54, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Очередная смузи-поделка. Лишь доказывает теорию того, что современное айти упёрлось в потолок, а все новые "разработки" - это из разряда обновлений ради обновления.
     
     
  • 2.38, Аноним (38), 19:49, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > все новые "разработки" - это из разряда обновлений ради обновления.

    Эх, золотые слова...

     

  • 1.32, Аноним (31), 16:26, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А там глядишь и systemd на bsd портируют :)

    Лет через 10-15 можно будет в каких-то некритичных местах даже иногда использовать ради интереса. Удачи проекту, она ему очень понадобится.

     
  • 1.37, Аноним (37), 19:47, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    С этим unevil в firefox ни локальные файлы не открыть, а теперь он даже в "Загрузки" не хочет сохранять.

    Сделайте firefox снова злым!

     
  • 1.44, YetAnotherOnanym (ok), 22:52, 03/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > Поддерживается совместное использование curtain с механизмами изоляции, предоставляемыми подсистемами Jail и Capsicum

    Не, ну это как-то не по-опенсорсному.
    Надо, чтобы новая утилита дублировала функционал и конфликтовала со старыми при совместном использовании. Вот это будет по-опенсорсному.

     
     
  • 2.46, Аноним (15), 03:13, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Возможно, именно это и подразумевается. Ведь когда из-за конфликта систем что-то не работает, это более безопасно - нельзя взломать то, что не запустилось.
     
     
  • 3.53, YetAnotherOnanym (ok), 11:24, 04/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Эммм... ну... это не лишено смысла...
     

  • 1.52, Аноним (-), 10:10, 04/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    https://lists.freebsd.org/archives/freebsd-hackers/2022-March/000940.html
     
  • 1.56, Аноним (56), 01:41, 06/04/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как обычно - свое уникальное, ни с кем не совместимое?
     
     
  • 2.57, Аноним (-), 11:57, 06/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Как обычно - свое уникальное, ни с кем не совместимое?

    Расскажи поподробнее, с чем совместимы cgroups, seccomp, namespaces, apparmor ... LXC, docker, systemd?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру