The OpenNET Project / Index page

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



"Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Второй уровень иерархии тем в форуме реализован через вкладку "Показ ключевых тем".
. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD" +/
Сообщение от Дон Ягон (ok), 20-Фев-20, 17:55 
> Перестанут работать, только если не будет способа снять для них запрет. В PaX этот способ есть. Выбор между режимами явного включения и явного отключения запретов (механизмов защиты), softmode - тоже есть.

Ну то есть ещё раз: если для некоторых приложений не ОТКЛЮЧИТЬ pax-защиты, они работать не будут.
С pledge также не получится отозвать у этих приложений prot_exec (приложения сломаются по всё тем же причинам), зато можно отозвать у приложения какие-то другие права или даже ограничить его доступ к fs при помощи unveil.
Пример - да всё тот же хромиум. В случае pax ты получаешь обычный хромиум, в случае OpenBSD - запертый в ~/Downloads браузер.

>> следить за тем, чтобы приложения [не] были сломаны _необходимо_.
> Тирада о банальностях. paxctld и paxmark ранее в Hardened Gentoo созданы именно для этого, но тебя снова не устраивает.

Как кого-то это говно может устраивать?

Даже отбрасывая рассуждения о потенциальной дырявости всех этих волшебных приложений, и, главное, адекватности их конфигурации, можно же просто немного подумать головой: paxctl перелючает защиты для отдельного бинарника, pledge же можно более гибко разместить в коде программы (например, после инициализации и до main loop, чтобы например, во время инициализации разрешать условный dlopen(), а после - нет) и выдавать отдельные разрешения для каждого процесса.

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

>> OpenBSD не нарушает стандарт, а дополняет его.
> Ты или притворяешься, или действительно не понял, что я сказал? OpenBSD не предоставляет пользователям выбора: нарушать стандарт по умолчанию (или по явному волеизвявлению а ля softmode в PaX), но усилить безопасность, или не нарушать стандарт, но в ущерб безопасности.

Если ты умеешь писать код, то выбор есть (в любой ОС). А предлагать пользователю решать самому - абсурд, бОльшая часть выберет работающие приложения, а не безопасность. Какой смысл в защите, которая всё равно выключается или никогда не включается? Чтобы потом на нытьё "а чо миня фсьо равно паламали" - ну вы же сами всё отключили, мы-то тут причём?
Optional security - это то, что принципиально не делают в OpenBSD. Местный подход к обеспечению безопасности - security by default - все интегрированные в ОС механизмы защиты включены и работают по-умолчанию, отключить их нельзя. Контрпример с wxneeded - едва ли не единственный, и его наличием никто не гордится.

> В OpenBSD всё решили за пользователя: только следование стандарту, только в ущерб безопасности.

Решили, но не в ущерб безопасности. Хром на ведре с PAX-патчами не становится безопаснее, потому что для него PAX всё равно выключается.

> Выбор оставили только разработчикам, то есть, себе любимым - тот самый pledge.

Нет, не себе любимым, а всем.

> Ты даже не понял, о чём речь, потому что не знаешь, что SELinux позволяет устанавлливать запрет, аналогичный PAX_MPROTECT, и выбор у пользователя есть, хотя бы и в такой форме.

Вообще-то знаю, я даже написал про это в сообщении, на которое ты отвечаешь: "Ну да, "W^X part two" оно тоже умеет, но это скорее посмеяться".

> Даже в линуксе. А в OpenBSD - выбора нет. Если тебе этот выбор не нужен - это твоё и только твоё дело.

Повтори мантру про выбор ещё, чо.
Если ты прям мамой готов поклясться, что тебе нужен строгий W^X для безопасносте приложения и только этого не хватает для счастья - сделай патч, это 1-2 строки кода примерно будет. Если ограничиваться только отзывом prot_exec.
Наружная крутилка для внутренней логики работы программы - это абсурд и иллюзия безопасности.

>> бывает, наверное. В любом случае, в случае с pledge, _пользователю_ не придётся ничего настраивать.
> Не только не придётся, но и возможности нет. Кроме хаков с LD_PRELOAD и аналогичных.

Не делай, пожалуйста так (хак с LD_PRELOAD). Ты совсем не понял суть pledge, если хочешь делать так.
W^X part 1 зафоршен общесистемно (плюс paxctl'еобразный костыль с wxneeded), отозвать prot_exec можно только через вызов pledge и это by design, возможность настройки этого пользователем не сделана намеренно. В крайнем случае, возможность _отключить_ pledge в отладочных целях может быть реализована в самом коде программы.

>> это история больше не про "защиту браузера", а про разграничение доступа
> Ознакомься и не позорься: https://akkadia.org/drepper/selinux-mem.html

Да в курсе я, в курсе. Это смешно, конечно.
Там уже перестали при каждом чихе рекомендовать делать setenforce=0?

В целом же, я про другое. Использовать selinux для включения W^X для отдельно взятого приложения, конечно же, можно, только очень неудобно. И вообще, огораживать приложения им, ИМХО, неудобно. До сих пор это нормально не доведено до ума.
Удобно ли им (селинуксом) огораживать доступы пользователей в зависимости от их класса доступа и прочий RBAC я не знаю, не имел такого опыта, но сравнимых альтернатив в любом случае особенно нет, чего нельзя сказать про W^X. AppArmor и т.п. - немного другое всё же.

> Двойные стандарты как они есть: бремя модификации исходников, сборки и распространения пакетов - тебя не смущает. А "сломанные приложения" и "неправильные" paxctl(d) - смущают. Whitelisting - плохо, blacklisting - хорошо. Цирковое училище оканчивал?

Не смущает, потому что ПО будет работать также, как во всех прочих ОС, в которых W^X part 2 также не зафоршен по умолчанию, т.е. примерно во всех. Т.е. будет не хуже.
Бремя модификации исходников, по задумке, ложится на разработчика или на мэйнтейнера. Пользователю  про это думать не нужно, разве что по личной инициативе. И pledge, повторюсь, задуман ради бОльшего, нежели отзыв prot_exec.

>>> прикручивать pledge через инъекцию библиотеки посредством LD_PRELOAD
> Действительно, смешно. Это ведь единственный способ усилить защиту памяти аналогично PAX_MPROTECT/SELinux без затрат на пересборку/распространение, который оставлен пользователям OpenBSD её разработчиками.

Это принципиально неверный способ использования pledge. Его предполагается вызывать после того, как приложение закончило инициализацию, подгрузило все модули и перед тем, как оно перешло в main loop. Так как предлагаешь ты, ничего нормально работать не будет.

>>> это нелепость и действительно неудобно.
>> Неудобно и, главное, небезопасно, ставить ручками флаги paxctl'ем или запускать костыледемон
> Ну-ка, ну-ка, чем небезопасно?

Тем, что это лишний запущеный демон, читающий конфиг, написанный условным человеком. Настраивающий защиту памяти.
Человеку нужно разбираться в особенностях работы каждой отдельно взятой программы или выставлять более пермиссивные разрешения (= "отключить, чтобы работало").
Мне, конечно, следовало написать "потенциально небезопасно".

>> paxd.
> paxctld. Сразу видно знатока.

Знатоком сортов говен не являюсь. Так или иначе, paxd тоже был: https://github.com/thestinger/paxd-archive

>> pledge() предполагает, что будет использоваться автором программы, а не пользователем;
> Вот именно. Защищённая система, где включать защиты можно только разработчикам. ;)

Нет. Они или есть и включены изначально, или их просто нет. Опциональная безопасность = не безопасность. История "успеха" setenforce 0, то есть, простите, selinux, тому пример.

>> Не  нужно пытаться делать из openbsd pax
> При всём желании не получится. Не доросли.

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

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD, opennews, 16-Фев-20, 08:44  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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