Извини, но далее я буду стараться отвечать только на то, на что есть смысл отвечать. Можешь считать, что я слился и так далее - мне безразлично.

> Это где _пакетный менеджер_ ругается на битые чексуммы у _пакета_?

Там потерялось слово "файлов". Т.е. речь о:

> Если речь о средствах проверки целостности _файлов_ пакета

Да.

> И волновать это будет только тебя и только с моих слов.

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

> Два инструмента - pledge и MAC - которые ортогональны и лишь частично пересекаются областью применения и природой накладываемых ограничений, ты сравниваешь напрямую. MAC хуже, PaX-флаги хуже, pledge лучше. И считаешь это технической конкретикой.

Я ещё уточнял, для чего pledge лучше. И если бы ты и это прочитал/процитировал, было бы не так феерично.
Я писал, что pledge лучше чем MAC подходит для защиты приложений от "самих себя", т.е. от эксплуатации дыр в них. Pledge - сорт privilege revocation, MAC - это принудительный контроль доступа, _очевидно_, что это разные решения разных проблем. Многие проблемы, которые можно решать при помощи MAC, при помощи pledge или аналогов решать нельзя в принципе, или какими-то адовыми костылищами. И это _нормально_.

> когда PaX с SELinux сравнил

Ты делаешь то, в чём постоянно обвиняешь меня - не учитываешь контекст. В сравнении была логика, но ты предпочёл попытаться поглумиться.

> Патчи работают сами, отдельно от ядра? Нет. Ядра работают сами, отдельно от приложений? Нет. Вот я и сравниваю OpenBSD со связкой grsecurity-ядро + дистрибутив общего назначения. А ты мне под надуманным предлогом пытаешься отказать в праве на такое сравнение.

Какой смысл сравнивать _нишевое_ решение и то, что позиционируется, как общее решение? Право ты, имеешь, и кто я вообще такой, чтобы в чём-то тебя ограничивать? Только а смысл?

> Ну да, а в OpenBSD в своё время была опубликована уязвимость к удалённому выполнению произвольного кода в ядре. Покажи мне аналогичную уязвимость в линуксе за время с тех пор по сегодня. Хотя бы такую, которая так же надёжно эксплуатировалась бы в простом линуксе, без grsecurity. И дело не в том, чтобы померяться уязвимостями, а какие выводы затем сделать по факту наличия или отсутствия предпринятых мер, дабы ситуация не повторилась.

Насколько я помню, меры были разве что в области проверки аналогичных по смыслу мест, аудиту и так далее. Интеграция тех или иных мер безопасности не бесплатна.
Я не знаю, насколько хорошо принятое опенбсдшниками решение поступить так, как они поступили, но аналогичных дыр, емнип, более и в OpenBSD не было. Может быть, потому что таки починили. Может - дыры ещё ждут своего открывателя.
Лучше бы OpenSMTPD починили, блин, с ним пока никакие дыры в ядре не нужны.

> Про государствннные дистрибутивы специального применения с grsecurity ты тоже не в курсе.

Никогда не сомневался в вероятном существовании чего-то подобного.

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

Ну а что, нет? Едва ли "гос дистрибутивы" - это тупо наложенные и активрованные pax-патчи, правда?
"Гос дистрибутивы" - это, вероятно, "готовое решение", патчи - playground для разработчиков и энтузиастов и база для чьего-то stable.
Я принципиально неправ?

>> Сравнивать openbsd с pax нулевых мне как раз малоинтересно, писями меряться - это детский сад.
> Я смотрю, история тебя интересует, только когда ты делаешь к ней многозначительную отсылку фразой "история нас рассудит, посмотрим". А когда речь заходит о уже свершившейся истории, о реальных успехах и неудачах, так сразу "детский сад". История тебе не интересна, потому что в неё вошли успехи PaX и бездействие OpenBSD

Почему же бездействие? Согласись, не факт, что из-за одного инцидента следует тащить в ядро некую конструкцию, а не просто зачинить то, что было сделано плохо?
Успехи PaX, безусловно есть, и в моём признании не нуждаются, но это довольно нишевые успехи.
Есть, например, OpenVMS, которая тоже нишевая и тоже умеет КУЧУ того, что OpenBSD не умеет, даже рядом не умеет. Но мы же не сравниваем их, не так ли?

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

Нет, безопасность через корректность это не бред. Просто закладываться _только_ на корректность - неправильно. И опенбсдшники этого не делают. Но и число интегрированных защит у них меньше, чем у grsecurity, например.

> Ну так и PaX/grsecurity крайне осторожны. Ты ведь намекаешь на обратное?

Я намекаю на то, что PaX/grsecurity - это набор патчей, который ни в одну публичную ОС общего назначения в стандартную поставку интегрирован не был.

> И зачем ты мне эти банальности рассказываешь? Ты ведь намекаешь на то, что grsecurity поступает иначе. А факты где? Фактов нет.

Какие могут быть факты, если grsecurity - это патчи, не используемые <и далее по тексту, см. выше>?
Не сомневаюсь, что разработчики grsec тестируют в том числе и производительность своих решений, но при всём уважении, полнота их тестов едва ли может быть абсолютной.
Но я не намекаю не то, что разработчики grsecurity поступают иначе, я намекаю на то, что есть смысл сравнивать openbsd и какой-нибудь дистрибутив linux, по-возмоности показательный. Но не ОС и набор патчей.

>> Так это pledge опциональный. ...... пытаешься выставить недостатком.
> Вооот, видишь, как ты удобно для себя вновь поскипал смысловую часть моей реплики.

и далее:
> Ты специально потёр всю смысловую часть в моей реплике, чтобы увильнуть от отвественности за свои слова.

Для справки: opennet выдал мне ошибку о том, что сообщение превышает 30000 символов и я вырезал всё, чтобы сэкономить. Ты напрасно ищешь в этом тайный смысл (но - бога ради).

> То есть, у такого враппера остаётся проблема, аналогичная игнорированию LD_PRELOAD.

Справедливо (тоже не проверял).

> Так зачем он такой нужен? [враппер]

Они никакой не ну..н.

> Тем, что у тебя получилось идею родить? Молодец, только идея совсем на поверхности лежала и сравнительными достоинствами, увы, не обладает, в отличие от сравнительных недостатков.

Потому что я не понимаю, зачем мудрить с "правильным" (в твоей терминологии) решении с хитрожопым враппером, если это всё равно _костыль_? По задумке, это не я придумал, можешь посмотреть в презентациях, pledge и должен явно вызываться в коде.
Я думал, что ты хотел костыль-воркэраунд и предложил тебе более простое решение. Как основное решение - никаких врапперов не предполагается. Не вижу смысла обсуждать это - неправилен сам подход.

> в прошлом пользователь grsecurity в течение двух лет, на Arch Linux.

Продакшен был на debian, но к его настройке я не имел отношения. Никаких проблем с эксплуатацией не было, хотя некоторые вещи были сделаны, по-видимому, странно.
Это ничего не значащий опыт - факт.

> Во-вторых, даже мнение о том, что PAX_MPROTECT является нарушением стандарта - всего лишь мнение.

Это очень удобная позиция. Поэтому я сразу добавляю всегда "и, что самое главное, ломает приложения". Если бы не ломал - чхали бы все на нарушения стандарта.

> Ты потому не увидел проблемы "в более позднем отзыве prot_exec", что не учёл, например, случаев атаки на setuid-процессы, когда уязвимость может обнаружиться в самом раннем коде, и эксплуатироваться будет локально, для повышения привилегий.

Да нет, я сразу именно про xorg и подумал. Только, емнип, pledge там так или иначе не помог бы.
И обрати внимание, что я сказал про то, что не вижу _большой_ проблемы, а также что я согласился с тобой, что с точки зрения безопасности его правильнее отзыать как можно раньше.

> И про уязвимости, например, в libc

Да нет, не туда ты. Я просто изначально стою на позициях, что 1) pledge - не серебрянная пуля 2) не аналог pax_mprotect.
Можно придумать ещё много примеров, когда pledge потенциально(?) не эффективен, и что? Неисполнимую память тоже пытаются обходить, я про всяческий ROP.
В значительной части случаев тех мер, которые позволяет pledge достаточно, отдельные кейсы типа тех suid-бинарников можно защитить как-то отдельно.

> браузел - лишь один из кейсов, а ты мне снова мычишь в ответ про pledge и unveil, как они могут быть практичнее, чем PaX, и про шансы на эксплуатацию в реальном (!) мире.

Браузер - это просто _показательный_ кейс, показывающий пример силы подхода.
Про реальный мир - из контекста же было понятно, что речь про использование не на специализированных системах, типа военного и гос сектора, а in the wild?
Я _в_курсе_ что PaX используется. Я сомневаюсь в его шансах стать решением по умолчанию хотя бы в одной ОС общего назначения. Насчёт pledge, напоминаю, тоже сомневаюсь, но сам подход мне видится более правильным и перспективным.

>>> была, ну т.е. на стадии инициализации), но шансы на эксплуатацию подобного
>> в реальном мире невелики.
> Очередное самораскрытие. .... И этот опыт нередок

Ну, может в какой-то степени, ок. Согласен. Специфика моего текущего окружения - отсутствие посторонних на машинах, поэтому локальные атаки для меня мало актуальны (мало != "не актуальны"). Возможно, недооценил специфики, например, хостинга.

> То есть, чтобы добиться практически эквивалетнтого по гибкости использования pledge без модификации и пересборки исходников.

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

> Преимущества такого подхода в том, что не нужно править исходники. Ты не согласен с тем, что это преимущество, но я чётко и неоднократно озвучил свои предпочтения и требования.

Само по себе это не преимущество и не недостаток. Ты же сам про контекст мне напоминал, не?
Да, нужно править исходники. Зато не нужна инфраструктура.
Твои требования и предпочтения - ради бога, я не утверждаю, что ты нуждаешься в OpenBSD. Я сравниваю конкретные подходы. И я в курсе, если ты не понял, что пока не так много программ защищено с использованием pledge, в то время как grsec используется давно и успешно, в своей области.

> Ха, действительно, в OpenBSD нет и, похоже, не было ld.so.preload.

Звучит, как будто это не ты допустил ошибку, а OpenBSD виновата.

> В любом случае, остаётся как минимум ещё один вариант

Ради бога. Может быть, я немного подумаю и догадаюсь, о чём ты, а может быть и нет - не сомневаюсь, что ты знаешь немало того, чего я не знаю.

> Чем, по-твоему, занимаются бизнесы, которые оплачивают подписку на grsecurity? Нет, часть клиентов предлагает специализированные дистрибутивы, о grsecurity в составе которых тебе даже гугль не расскажет.

Честно, хочешь верь, хочешь нет - ни секунды не сомневался в наличии чего-то подобного.
Дальше-то что? Это всё _приватное_. Какой смысл сравнивать специализированное решение и общее решение?
Комерчесские решение есть на базе всех или почти все *BSD систем, например, и что? Там, наверное, тоже немало всего интересного.
Ты хочешь, чтобы я признал (лол), что в grsec разработано больше всяческих техник защиты ядра и не только? Я никогда этого не отрицал, для начала!
Только вот говорить про то, что "OpenBSD не доросли до grsec" (или как ты там написал) - некорректно, потому что одно - ОС, другое набор патчей. В публичных дистрибутивах их уже нет, да и при опенсорсности - не было, приватные - отдельная история, т.к. являются спец. решениями (просто по своей сути, на случай, если ты захочешь потроллить меня вопросом "почему?").

> в том числе и такое, вроде Mathematica, которое для "ОС общего назначения" OpenBSD даже не выпускаются. ;)

А это, конечно, имеет такое отношение к обсуждаемым темам? Я в курсе, какая *nix ОС сейчас самая популярная, спасибо.

> что каждый пакет и каждая новая его версия была собрана именно с pledge

Процессы в ps помечаются "p". Это можно даже автоматизировать, если это важно. А так да, если важно - проверять.

> есть приложения, для которых PROT_EXEC через pledge в лучшем случае сделают опциональным (и придётся настраивать руками), в худшем - вообще не включат

Естественно. Я нигде не утверждал обратного.

> И получится, что запрет PROT_EXEC через pledge тоже нужно настраивать, но через аргументы командной строки, конфиги (множество разных) или переменные окружения.

Всё верно. Мы можем или также не включать, как в PaX или, _возможно_ попробовать сделать лучше.
Ну или не сделать, пример ты привёл - pledge не серебрянная пуля, я в курсе, что она решает не все на свете проблемы.

> У меня есть. Тебе - нигде.

Ну так это аргумент "в мою пользу", а не в твою.
С тем что приватно бывает очень всякое я никогда не спорил.

> Видишь, тебе _отвратителен_ сам подход. Какие ты от меня технические аргументы в ответ на отвращение хочешь услышать-то?

Я писал и про то, что наличие дополнительного процесса, работающего со входными данными от пользователя и управляющего безопасностью приложений - это плохая практика. Потому что это логика сбоку от пакетного менеджера. Потому там могут быть ошибки. Потому что он может упасть, а с обновлением приедет пакет без pax-флагов.
Не сомневаюсь, что ты или проигнорируешь это или объявишь несущественным.

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

Доказательств ты, разумеется, не предоставишь. Не, я охотно допускаю, что всё так, но сам факт.

> А кто сказал, что оно нишевое? Ты. А на каком основании? Может быть, есть общепринятые представления, классификация ОС? Нет. Может быть, ты эксперт и даёшь экспертное заключение? Тоже нет. Утверждение о нишевости - твоё личное мнение, которое ты очень хочешь выдать за авторитетное.

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

>> PAX MPROTECT прибивает процесс, который вызывает mprotect, добавляющий PROT_EXEC
> Не прибивает, а возвращает EACCES. Поэтому

Да, это ты по делу, а я нет. Я не могу сказать, что на самом деле я тогда хотел сказать, или имел ввиду, но так или иначе, по факту я написал херню.
Но странно, ведь по контексту _нашей_ беседы, уж что что, а то, что я понимаю, что делает pax_mprotect следует. Стоит ли так передёргивать?
Впрочем, ты всё равно будешь - успехов.

> О нём уже можно сказать ... полнотой своего применения.

А где я опровергал что-то из написанного тобой тут?

> Для масс содержимое paxctld.conf могло бы управляться пакетным менеджером

Могло бы. Реальность иная и моей вины в этом нет. Это и есть аргументы, а не "выдуманные сложности".

> В grsecurity KASLR от-клю-чён.

Да, ошибка. Я что-то перепутал, был уверен в обратном.

> Нет, факты того, что в стремлении не просадить производительность они от кого-то отличаются, а конкретно от PaX и grsecurity.

А я не хочу ничего такого доказывать. Дистрибутивов общего назначение с grsec внутри нет - нет возможности наокпить опыт с сравнить производительность до и после.
Согласен, из контекста выглядит так, будто я конкретно в этом противопоставлял openbsd grsec'у. Нет, я просто перечислял, чиселок с grsec у меня нет, и я на это не намекал.

> Ну-ка, ну-ка, какие там накладные расходы на KASLR?

Копейки, но они есть. А KARL - не рантайм процедура.

> Нельзя говорить, потому что ты так сказал? Где критерии? Где факты? Тебе просто очень хочется вывести PaX и grsecurity из ряда конкурентов OpenBSD. Приём не тобой придуман. Эту песню я слышал от разработчиков OpenBSD ещё в начале нулевых. А по факту в этой "ОС не-общего назначения" работает больше приложений, чем в OpenBSD. Прямо с ходу, без расстановки флагов, из пакетов дистрибутивов общего назначения. Вот такой критерий. Можешь теперь с ним не соглашаться, сколько душе угодно. Лучше всё равно не предложишь.

Сравнивай условный debian до pax и с pax, зачем тут OpenBSD? Приложений под неё меньше, и для меня это не новость, но это по другим причинам. Ты ещё про то, что она масштабируется хуже, например, вспомни, ага.
Критерии - декларируемые цели / реализуемые по факту решения.

> Тебе не надо, а мне надо. "Ни в коем случае" - типичный нигилизм и неуважение к чужому мнению. Один ты умный с правильным мнением, да разработчики OpenBSD. У всех остальных мнение неправильное.

Конкретное решение (с pledge) мне кажется слишком очевидным, я, наверное, до этого сообщения воспринимал твой пример про LD_PRELOAD исключительно как троллинг и желание простого костыля. Цели задеть тебя не было, если ты об этом.