> Не разных проблем. А решения пересекающихся множеств проблем (задач), обладающие _разными_ свойствами, такими как мандатность, например.Вопрос выбора абстракций/определений.
Как по мне, меры защиты должны быть реакцией на модель угроз. В случае, когда мы хотим сбросить полномочия процесса у нас одна модель угроз, в случае, когда мы хотим сложным образом ограничить доступ процесса к каким-то ресурсам - другая.
Разные проблемы - разные инструменты удобны. А то, что там что-то пересекается - это нормально, не вижу никакой проблемы в этом.
> Причина в том, что я сравнил свойства решений, в первую очередь наличие/отсутствие свободы выбора у пользователя.
Если ты это про то, что в OpenBSD нет MAC, то с этим можно согласиться, его там нет -> выбора нет.
Если ты про то, что pledge by desig дубовое и захардкоженное, то нет. 1) это задумка 2) выбор есть, но требует, безусловно, больше ресурсов.
> Существование того же PaX во многом обусловлено тем, что selinux сложен и неудобен." ... Ну давай, расскажи мне, какая тут логика.
Логика тут такая, что разработчики PaX используют pax mprotect и т.п., а не накручивают те же ограничения selinux'ом. Потому что PaX много-много проще. И его сложнее настроить неправильно.
То же и с gradm (или как там mac/rbac в grsec'е назывался?).
Зачем было бы делать альтернативу, если SElinux всем хорош?
> Кем PaX позиционируется, как нишевое решение?
Не PaX, а решения на базе него. Теми, кто эти решения реализует.
Просто по факту - это не паблик и не пытается им быть.
> Это OpenBSD по факту - нишевое решение.
OpenBSD по факту может меньше, чем linux, даже с PaX. Но это следствие отсутствия какого-то ПО и/или функционала, а не задумка.
> Я уже дал критерий разделения на нишевые ОС и ОС общего назначения: работоспособность приложений и само их наличие для ОС в рассмотрении.
Это неверный критерий. Сравнивай с обычными дистрибутивами Linux, если так проще будет.
Ну и всем критериям ОС общего назначения OpenBSD таки соответствует. По меньше, производительность, как правило, хуже и т.п. - всё так.
Если ты про то, что опенбисиди менее "продвинутая" ОС общего назначения, чем линукс, то мне нечего возразить.
> А как лично ты позиционируешь PaX/grsecurity
Никак.
> Смысл есть.
Пиписями меряться, да. Другого придумать не могу.
> Но речь идёт не о потерях производительности или внесении видимых изменений в поведение системы, а о внедрении мер, аналогичных тем, что на то время уже несколько лет были в PaX, и которые разработчики OpenBSD ещё лет 10 не трудились внедрять даже после появления NX-бита в x86-процессорах.
Если ты про W^X, то да, всё так. Потому что это сломало бы кучу ПО, база и порты не были к этому готовы. ЕМНИП.
Хотя из контекста не следует, что ты про W^X...
Так или иначе, я в курсе, что многих решений, что есть в PaX нет в OpenBSD или они появились позже. Что далее?
Само по себе это ни о чём не говорит же, ну. Вопрос в том, _почему_ они так решили (если что, в зависимости от, я могу и не знать, почему именно _они_ так решили).
> Не было опубликовано. В линуксе тоже не было опубликовано, дальше что? Защиты ядра не нужны? ;)
Я не думаю, что на этот вопрос можно ответить для общего случая. Смотря какие именно дыры, смотря какие именно защиты и сколько они "стоят".
Архитектор каждой отдельно взятой конструкции должен делать вывод исходя из целей и вышеозвученного.
> И если говорить о специфике защиты ядер таких дистрибутивов, то да, это по большему счёту именно "наложенные и активрованные pax-патчи" - не тупо, разумеется, если речь не идёт об Astra Linux.
Ничего не знаю про астру, но главное ты написал - "не тупо". ЧТД.
Не сомневаюсь, что grsec там используется к месту и никого не раздражает по объективным причинам. И настроен умными людьми для того, чтобы приложения работали в рамках предполагаемых условий.
> ты во всём принципиально не прав
> А по факту в grsecurity на сегодняшний день поддержка стабильных ядер лучше, чем в апстримном линуксе, и многие клиенты платят деньги именно за эту поддержку.
Прости, но не впечатлило. В сотый раз повторяю: я не считаю grsec крапом. И не считаю, что комерчесские клиенты grsec платят им за воздух.
Просто приватные дистрибутивы с "не тупо" наложенными и активированными патчами != самим патчам. И тем более != ОС общего назначения.
Это не значит, что они лучше или хуже - другие.
> "Не просто зачинить" - это называется proactive security. И сами разработчики OpenBSD если не придумали, то всячески старались до какого-то момента популяризировать этот подход. А "зачинить то, что было сделано плохо" - это называется reactive security, каковой подход опять-таки сами разработчики OpenBSD всячески критиковали.
Спасибо за безвозмездный ликбез, я в курсе. А как называется, когда в коде ищут проблемные места, типа как при дыре, и тупо убирают их, вместо proactive security?
Я точно не знаю.
В любом случае, ни один подход не должен быть религией. Если целеобразно уничтожить класс проблем, вероятно, следует внедрить проактивную меру, если не целесооразно - соответственно.
Было ли целесообразно в том конкретном случае - я не знаю.
> Вот и расскажи, чем они нишевые.
Тем, что нет публичных дистрибутивов (и далее по тексту). Тем, что те, что были, из коробки не работали как "обычные", были немаловажные нюансы.
Тем что готовых решений общего назначения не было (не утверждаю, что они принципиально невозможны).
У пользователей обычных ОС разнообразные требования, за grsec, обычно, приходят, когда хотят безопасности. Это и является очевидной спецификой.
> Ты не путай безопасность через корректность вне контекста - с тем бредом, который ты ляпнул. Ты ж её _противопоставил_ "митигациям", как ты их назвал.
Я не противопоставляю. Я просто не считаю, что _каждая_ дыра должна приводить к внедрению проактивных защит и/или митигаций. И хорошо, что в опенбсд предпочитают наводить порядок и корректность, а не плодить подпорки, пока это возможно. ИМХО.
> Так определись уже, правильно или не правильно. Или ты рад тому, что разработчики OpenBSD неправильно делают?
Разработчики OpenBSD стараются делать правильно. А когда правильно внедрять проактивные защиты, а когда нет - имхо, очень непростой вопрос. Я рад, что OpenBSD'шники практикуют технический, а не религиозный подход и применяют меры исходя из целесообразности. Да, они _разумеется_ могут ошибаться в своих решениях.
> Тут дело не в количестве, а в качестве. А именно, в соответствии оных защит современному технологическому уровню угроз. В случае с OpenBSD - в несоответствии.
Не только. Ещё в целях проекта, стоимости внедрения и так далее и тому подобное - сто раз уже писал.
> Это мы уже обсудили. Я изложил свои доводы, ты их проигнорировал.
А мне кажется, что проигнорировал меня ты. Если так и будем ходить по кругу, скорее всего, ни до чего не договоримся. Я это переживу, ты, уверен, тоже, но тогда лично я предпочту закрыть эту тему - мне ок, что у кого-то есть мнение отличное от моего.
> фактических претензий к PaX/grsecurity в этом плане у тебя нет
Чиселок у меня нет, и я нигде не заявлял обратного.
> Снова ужимки и прыжки.
Да никаких ужимок. То, что приемлемо для частного решения, может быть неприемлемо для общего. Этот простой факт ты почему-то никак не хочешь принять.
> Ничья полнота тестов в таких случаях не может быть абсолютной. Это математический факт. Дальше что?
Дальше - опыт практической эксплуатации. Который, в случае grsec несравним с стоковым линуксом. В случае OpenBSD нет отдельно "безопсности" и отдельно ОС, там всё сразу и тестируется (последняя стадия - в продакшене) на полной аудитории, а не на подмножестве.
> что артументов по существу у тебя нет и ничего умнее, чем про "набор патчей", ты придумать не можешь.
Я намекаю на очевидные следствия из этого факта.
> Чтобы удовлетворить _моим_ личным критериям (если представить, что я начал пользоваться OpenBSD и захотел воплотить решение).
Ты захотел "как в линукс", это не цель, и не критерий, это проецирование опыта и отсутствие кругозора. В твоём случае, я почти уверен, - просто троллинг.
Инструменты надо подбирать под задачи. Ты захотел от pledge того, для чего его не проектировали. И начал предлагать костыли. Хотя надо было выбрать другое решение. Вероятно.
> Ну так и не обсуждай. Я заставляю, что ли? Сам пустился в рассуждения, как враппер сделать. Потому что идея пришла и язык зачесался. Мне враппер как таковой вообще не нужен и не интересен.
А, ну то есть про враппер - это типа я начал? ;)
Я привёл ровно один пример, как бы сделал я, будь мне нужен костыль. Это ты мне рассказывал, как делать надо.
> Вот я тебе рассказал (а ты сделал вид, что не заметил), зачем paxctld нужен и чем он лучше хуков пакетного менеджера. Будь у тебя чуть более богатый опыт работы, ты бы сам сообразил и просто вспомнил, что кроме системных пакетов в продакшене нередко присутствует много, чего ещё, что может потребовать настройки PaX-флагов.
Нет, это просто было за рамками обсуждения.
И если бы paxctld предлагался бы как решение для того, что по задумке не под пакетным менеджером (там типа уже всё с правильными флагами и нужды в paxd нет), вопросов бы, как раз не было.
Но он предлагается именно как дополнение подпорка к пакетному менеджеру, в первую очередь. Кроме, видимо, hardened gentoo и приватных дистрибутивов.
> Не не просто добавляешь "ломает приложения" - ты убегаешь в эту расплывчатую формулировку. "Ломает" - как многозначительно звучит-то! А я говорю: системные вызовы возвращают ошибку и работают в рамках, допустимых стандартом.
1) Это вольная, игнорирующая реальность трактовка стандарта.
2) Не всё ПО умеет обрабатывать такие ошибки -> проблема актуальна.
3) Даже то ПО, что умеет такое обрабатывать, может начать работать медленнее - это _можнет_быть_ критично.
> как ты сам сказал, думал, что семантика работы PAX_MPROTECT - это аварийное завершение процессов, которые нарушили ограничения PROT_EXEC. А это не так.
Нет, ты ошибся, я так не думал. Я так почему-то один раз написал (ты цитировал, где) и объяснить, почему я написал так я не могу, наверное, думал о чём-то другом или пропустил какие-то этапы в рассуждениях.
Цель той писанины была не объяснить механику pax mprotect, а показать, почему и без него не факт что всё будет обязательно трагично.
> К слову, когда в OpenBSD вводили W^X, были разговоры, что это сломает работу некоторых приложений, на что разработчики OpenBSD вполне обоснованно возражали, что если приложение не следует стандартам, нужно исправлять приложение, а не подстраиваться под его изъяны. Попробуй теперь этот факт подружить с иллюзиями в своей голове.
Я такого не помню, помню зато, как тот же W^X pt 2 называли нарушением стандарта. Если ты напомнишь, где такое почитать - смогу высказаться по теме, пока - увы нет.
Если приложение нарушает стандарты, его безусловно нужно чинить. Но доступная на запись и исполнение память, к сожалению, не нарушает стандарты.
И в OpenBSD есть wxneeded (которым никто не гордится, да). Почти PaX-флаг, в первой инкарнации.
