> Ну то есть ещё раз: если для некоторых приложений не ОТКЛЮЧИТЬ pax-защиты, они работать не будут.
> А если отключить - будут. Ещё раз: это whitelisting, лучшая практика по индустрии.Вместо решения конкретных проблем - мантры о стандартах индустрии. В случае проблем в условном хромиуме, PAX ему принципиально ничем помочь не может, в то время как pledge - потенциально да. А кроме браузера на десктопах, например, не так много запущено приложений, которые нужно защищать.
> какой PaX неудобный и неправильный, что говно и что абсурд
PaX таки решает ту проблему, что призван, если не выключен, конечно. Так что совсем неправильным не назвал бы. Но да, неудобен.
И говном я назвал не PaX, а paxd. Ну и, видимо, paxctld. Именно им я не пользовался, но едва ли он может чем-то принципиально отличаться от paxd. Сама идея подобного демона уже отвратительна. Вместо того, чтобы уменьшать количество сущностей, мы их плодим. Ну и как бы расписываемся в том, что управлять конфигурацией исключений pax без отдельного демона-костыля не очень удобно. Хотя, казалось бы, можно хотя бы пакеты с нужными xattrs собирать (гнутый tar, да и вроде bsdtar (libarchive) их умеет).
>> предлагать пользователю решать самому - абсурд
> Раскрылся, эксперт.
Да я и не скывался, лол. По-существу: автор программы в любом случае лучше пользователя знает, какие разрешения нужны его программе. Предположение о том, что пользователь в общем случае будет вдумчиво анализировать, а не "отключать, чтобы работало" - нелепость и абсурд, да.
>>> В OpenBSD всё решили за пользователя: только следование стандарту, только в ущерб безопасности.
>> Решили, но не в ущерб безопасности. Хром на ведре с PAX-патчами нестановится безопаснее, потому что для него PAX всё равно выключается.
> Нет, именно в ущерб. В PaX без MPROTECT работают процессы, для которых он явно отключён, а в OpenBSD без аналогичной защиты работает всё, что не собрано с pledge.
Это так, в OpenBSD без вызова pledge (по-умолчанию) mprotect позволяет переключать память в +x. Это действительно следование стандарту и реальности, в которой есть приложения (нужные) на этот стандарт рассчитывающие.
PAX MPROTECT (не включённый по-умолчанию примерно нигде, кстати) такого не позволяет, да.
Я тебе даже больше скажу: до того, как появился pledge, был период (годы), когда в OpenBSD был только W^X pt 1 и всё. И вовсе не потому, что никто в openbsd не догадывался, что можно реализовать W^X pt 2, подсказываю. Даже более того, прежде чем просто W^X внедрили, долгое время занимались аудитом кода (базовой системы) и его адаптацией к грядущему принудительному W^X.
PAX MPROTECT - это сиюминутное решение, "починить" здесь и сейчас, не считаясь с потерями. Pledge требует затрат на внедрение, но решает проблему с W^X pt 2 (и не только) в перспективе. PAX MPROTECT - костыль (в хорошем смысле слова; вот paxd - в плохом), быстрое решение, pledge - api для privilege revocation вообще. В перспективе, если всё сложится, pledge будет использоваться примерно во всех программах, что повлечёт за собой в том числе и W^X pt 2 везде, где возможно - при использовании pledge prot_exec по-умолчанию запрещён. А в будущем у PAX MPROTECT всё те же per-binary исключения и выключенность по-умолчанию примерно везде. Даже в NetBSD, в единственной ОС (HardenedBSD - не вполне самостоятельная ОС), в которой он из коробки, без необходимости патчить ядро, по умолчанию он выключен.
Но да, сейчас PAX MPROTECT позволяет "одной кнопкой" зафорсить W^X pt 2, а OpenBSD - нет. Но это не значит, что PAX MPROTECT лучше или правильнее. Безопаснее - да, если речь не про ПО, которому нужен mprotect с неотломанным +x.
>> Вообще-то знаю, я даже написал про это в сообщении, на которое ты отвечаешь: "Ну да, "W^X part two" оно тоже умеет, но это скорее посмеяться".
> Когда нет аргументов по существу, остаётся только "смех" и физиологизмы.
Аргументы: это неудобно. И непрактично. Существование того же PaX во многом обусловлено тем, что selinux сложен и неудобен. Хотя и более гибок (на самом деле, надо читать не "хотя и", а "потому что").
>>> Даже в линуксе. А в OpenBSD - выбора нет. Если тебе этот выбор не нужен - это твоё и только твоё дело.
>> Повтори мантру про выбор ещё, чо.
> И повторю.
Бога ради. Конкретно отзыв prot_exec, а не осмысленное внедрение pledge добавляется тривиально. Чем стонать тут про отсутствие выбора, попатчили бы уже то, что нужно. Но нет, испускать шум интереснее. Бог в помощь.
>> сделай патч, это 1-2 строки кода примерно будет.
> Сделать патч, пересобрать, развернуть.
Отослать патч автору ПО, добиться включения в кодовую базу, забыть навсегда.
> С PaX обхожусь без этих лишних трудозатрат, оставляя ресурсы для более важных вещей.
Слабый аргумент, как по мне. Если бы было нужно решить какую-то настоящую проблему, а не поныть, патч был бы сделан. Если никакой проблемы решать не надо - ждите, пока кто-то напишет патч за вас.
>> Наружная крутилка для внутренней логики работы программы - это абсурд и иллюзия безопасности.
> Иллюзия безопасности - это OpenBSD с набором защит ядра уровня ниже PaX начала нулевых.
OpenBSD, несмотря на все стереотипы, всегда достаточно осторожно относились к внедрению всяческий "секурити фич". Важно не только внедрить защиту, но и не сломать нужное ПО, работающее в рамках стандарта, а также не просадить до невозможности производительность. Ибо OpenBSD - ОС общего назначения. Что касается патчей от PaX, то даже во времена открытого grsecurity не было ни одного "серьёзного" дистрибутива, использующего наработки PaX и чтобы они был включены по умолчанию. Отдельные наработки, типа того же W^X pt 1 и 2 перекочевали в NetBSD (отключены по умолчанию) и в HardenedBSD (забирать код из которого в родительский FreeBSD фряшники не спешат и пилят свой сорт pledge - capsicum). Отдельные специализированные (и серьёзные, уже без кавычек, хотя я и в первый раз ничего сильно плохого не имел ввиду) дистрибутивы, типа Openwall, насколько я знаю (самому использовать не приходилось) используют (или использовали в прошлом) активированный PaX, но, ключевое слово тут - специализированные, ЕМНИП едва ли не где-то на опеннете (но и не только) Солар высказывался о том, что, например, для графического десктопа Openwall не очень подходит, и это так задумано, а не так получилось. Так как ограниченная поддержка стандартов заявлена изначально, сравнивать с операционными системами общего назначения не вижу смысла, разные поставленные цели могут требовать разных инструментов.
>> Не делай, пожалуйста так (хак с LD_PRELOAD). Ты совсем не понял суть pledge, если хочешь делать так.
> Это тебе кажется, что я не понял. Wishful thinking. Хочешь казаться экспертом, а демонстрируешь неспособность понимать смысл написанного в контексте.
Ну ты написал "прикручивать pledge через инъекцию библиотеки посредством LD_PRELOAD", я вот именно про это.
Суть pledge - сделать удобный api для privilege revocation, а не слепить костыль для принудительного отключения prot_exec. Если в итоге появится и преуспеет описанный костыль, то задумка pledge будет в известной степени провалена. Хороший и правильный вариант - осмысленная модификация кода программы.
А то, что pledge можно позвать более чем 1 раз, уменьшая каждый раз список выданных классов доступа, я в курсе, спасибо.
В любом случае, ты зря думаешь, что я считаю себя экспертом.
Про враппер прокомментирую отдельно ниже.
> Знаю людей, которые пишут собственные политики для систем с усиленной защитой ядра (grsecurity). Потому что - сюрприз! - штатные политики никуда не годятся, ибо накладывают слишком общие и потому почти бесполезные ограничени. Так вот, они не делают setenforce=0. Представь себе, целевая аудитория систем с заявкой на повышенную защищённость - не только хомячки, за которых нужно делать выбор. И задачи они решают не только по защите локалхоста от мнимых угроз.
Я не знаю, какие задачи эти люди решают -> не знаю, насколько оправдано их решение. Я не говорю, что MAC или RBAC не нужен никому никогда в принципе и вообще бесполезен, я говорю, что они плохо подходят для защиты приложений "от самих себя" (ну чтобы там условный хромиум не мог залезть в ~/.ssh/, например). Но есть и области применения, где они, напротив, уместны.
Если люди не хотят, чтобы за них был сделан выбор, они и в код посмотрят, и патч, если надо напишут, и всё вообще на свете сделают и проверят. А _по_умолчанию_ должен быть максимально безопасный вариант, но в пределах допустимого стандартом, если заявлена поддержка оного.
>> В целом же, я про другое. Использовать selinux для включения W^X для отдельно взятого приложения, конечно же, можно, только очень неудобно.
> Удобно или нет, но это можно сделать, и находятся люди, которые делают, в рамках кастомных более запретительных политик MAC.
Абсолютно не важно, что кто-то сумел так всё настроить. Этот кто-то молодец. Важно, что это неудбно. Зачем использовать более сложный вариант при наличии более простого при равном итоге?
>> огораживать приложения им, ИМХО, неудобно.
> Да неужели прогресс? Уже не "говно" и не "абсурд", а "ИМХО, неудобно".
Говно - это paxd. Абсурд - это подход с настройкой возможности prot_exec извне приложения, потому и неудобно.
>> И pledge, повторюсь, задуман ради бОльшего, нежели отзыв prot_exec.
> А флаги PaX - ради меньшего. У них более узкие задачи, с которыми они прекрасно справляются.
Ага. Костыли для отключения костыля. Но спорить не буду - делает то, что обещает делать.
>> Это принципиально неверный способ использования pledge. Его предполагается вызывать после того, как приложение закончило инициализацию, подгрузило все модули и перед тем, как оно перешло в main loop. Так как предлагаешь ты, ничего нормально работать не будет.
> Во-первых, тебя сносит в обсуждение собственных мыслей о pledge. Если б ты постарался понять (или не сделал бы вид, что не понял), о чём тебе собеседник пишет, то заметил, что речь шла о включении запрета на использование PROT_EXEC.
Вот тут есть маленько, продолбался. Я не знаю, почему решил что речь об отзыве всех разрешений. Тем более, pledge можно вызвать N раз, при условии, что правила становятся только строже.
> И его-то нужно включать как можно раньше: что через хак с LD_PRELOAD, что через штатное использование pledge() в исходниках.
В целом согласен, хотя и большой проблемы в более позднем отзыве prot_exec не вижу - инициализация обычно это в худшем случае секунды, это не успеют использовать. Но да, prot_exec отзовётся уже при первом вызове pledge, который нужно делать как можно раньше.
> В main loop, как ты выразился, можно включать другие запреты, которые при включении на более ранних стадиях помешали бы нормальной инициализации приложения.
Всё так. Я не вполне сейчас могу объяснить себе, почему я написал то, что написал, на самом деле я хотел написать что-то типа того, что написал (чуть выше, там где про api для privilege revocation). Видимо, в последний момент переключился на другую мысль. Так или иначе, это мой косяк, спасибо.
> Более сложный рантайм-враппер, подгруженный через LD_PRELOAD
> При желании такой враппер можно даже сделать настраиваемым через конфиг, где описывать набор правил: в момент вызова какой процедуры - какие ограничения включать.
Последнее не будет работать, т.к. pledge позволяет только уменьшать список доступных классов доступа (обратное было бы небезопасно) в пределах процесса.
Настраивать ограничения для отдельной функции в стороннем (по отношению к приложению) конфиге мне в любом случае не кажется хорошей идеей.
Использовать LD_PRELOAD - тоже. Хотя бы потому что LD_PRELOAD игнорируется для suid и sgid бинарников, лепить ещё один костыль для обхода этого - странно.
>> Мне, конечно, следовало написать "потенциально небезопасно".
> "Потенциально небезопасно" - высказывание с объёмом, близким к бесконечности и обратно пропорциональным же содержанием. Лучше б ты вообще промолчал.
В конкретном случае всё просто. В случае pledge всё настроено один раз в жизни при написании программы и в дальнейшем настроек не требует вообще, разве что, программа принципиально поменяет набор возможностей и/или способ их реализации. Но даже в этом случае можно обложиться тестами, например. В случае с PaX нужно поддерживать в правильном состоянии конфиг условного paxd (обновлять его настройки согласно требованиям программ), нужно держать в системе запущенный демон, который может выставлять рутовым бинарникам опасные разрешения - это всё, очевидно, сложнее чем отсутствие какой либо настройки. При равном (в итоге) результате - зачем?
>> Знатоком сортов говен не являюсь.
> А совершенно не важно, говна то или не говна. Это всё твои субъективные ощущения, представленные в характерной форме физиологизмов. А по факту ты лишь расписался в том, что судишь о вещах, о которых имеешь самое поверхностное представление.
Каким именно образом? Я не использовал Hardened Gentoo, и не в курсе, что там paxd называется paxctld. И мне не интересно, причём - совсем. Делают они одно и то же, и я слышал ещё по меньшей мере про один аналог. Это именно что сорта говна.
Ссылку на остатки от paxd на гитхабе я тебе скинул - такой демон был. Так что пытаясь обличить меня в недостаточном знании вопроса, ты обличил в нём и себя, так как продемонстрировал, что не знаешь про paxd. Хотя как по мне, можно ничего не знать ни про paxd, ни про paxctld - и то и другое костыли и так делать не надо. Надо хотя бы пакеты с правильными xattrs собирать.
>>>> pledge() предполагает, что будет использоваться автором программы, а не пользователем;
>>> Вот именно. Защищённая система, где включать защиты можно только разработчикам. ;)
>> Нет. Они или есть и включены изначально, или их просто нет.
> Я вот до сих пор не пойму, это такой троллинг, или всё-таки эмоциональный пересказ глубоко воспринятой доктрины? Ну сказал бы "или они просто не работают" - нет, ляпнул "их просто нет". Тут и добавить нечего.
ЯННП. Но и не очень интересно. Но если что, я абсолютно серьёзно отношусь к тому, что пишу на этот счёт. И, как мне кажется, вполне могу обосновать правильность своей позиции.
>> Провокация не удалась
> Это и не провокация, а констатация факта. В PaX (и grsecurity) в начале нулевых уже были защиты от эксплуатаций уязвимостей ядра, пять лет назад появился CFI, а относительно недавно - GCC-плагины для защиты от атак на микроархитектуру (Spectre). В OpenBSD же на ядерном поприще если и делается что, так только под лозунгами наведения корректности. Явный курс на безопасность они оставили ещё в начале нулевых и с тех пор даже не пытались на него вернуться.
Если это не провокация, то демонстрация невежества.
Заморачиваться лень, простой контрпример - KARL. Да, я в курсе, что это не внуриядерный механизм,а скрипты сбоку, но так или иначе, это именно пример защиты ядра. А то, что в OpenBSD стараются решать проблемы наведением корректности, а не "митигациями" - это хорошо. Не забывай, что в OpenBSD значительно более простое и компактное ядро, чем в Linux, даже динамически загружаемые модули не умеет уже, например. И серьёзных дыр _в_ядре_ довольно давно не было (что, конечно же, может быть и не показательно).
В целом, за grsec я перестал следить после того, как они закрыли код. Сделали что-то хорошее - молодцы. Забавно, что ты соскочил со сравнения подхода по включению W^X pt2 на сравнение возможностей OpenBSD и PAX в целом. Это разные ОС, разные подходы и разные ядра. Точнее, PaX - не ОС, а набор патчей, к ядру linux (в основном). Который, на самом деле, тоже не ОС, а только ядро.
Короче, неплохо, что PaX существует и в каких-то ситуациях он может быть полезен и применим, но не надо сравнивать опциональные меры безопасности (применимые не всегда) с безальтернативными (без злого вырезания функционала из кода не заставишь перестать работать).
>> я не намерен ни хамить, ни оправдываться.
> Ты уже нахамил.
А я только про конкретный наброс.
> Сперва на "ты" перешёл в фамильярной форме
Это не была попытка задеть, мы в интернете, тут общение на ты - норма. Я даже не придал этому значения. За это, в принципе, готов извиниться, если почему-то так задело.
> затем физиологизмами свои писульки приправил.
Ты принимаешь это слишком близко к сердцу, тем более, я снабдил это аргументами, а не только обозвал говном. Со своей терминологией я по прежнему согласен, и называть условный paxd "решением", а не говном отказываюсь.
> Или ты считаешь, что только прямые личные оскорбления хамством являются?
Хамством являются _необоснованные_ прямые личные оскорбления. Но мы уходим от изначальной темы совсем уж далеко
>> Почему я думаю так как я думаю я уже написал.
> А я тебе аргументированно возразил. Пишешь своё авторитетное экспертное мнение в комментах, претендуя на что-то уровнем выше плинтуса ("троллинга") - знай, о чём пишешь, умей держаться в рамках приличий, понимать написаннное тебе в ответ и возражать по существу, а не прыгать с темы на тему.
Сложно удержаться от соблазна потроллить, когда человек просто не хочет открывать для себя новое, потому что уже есть привычные решения. А иногда это вызывает раздражение, когда начинает казаться, что троллят тебя. Там где ты поправил меня по существу - я сказал тебе спасибо, и это за дело. А в целом, меня устраивает, как я выражаю мысли. Ты пишешь сюда не потому что тебе очень приятно общаться со мной, а потому что у тебя есть возражения, вот давай на них и сосредоточимся.
И да, экспертом я себя не считаю.
