> Я обратил внимание и уверен, что это не более чем фигура речи. Кроме того, уязвимость, оставленная доступной для эксплуатации не может быть маленькой проблемой, если только речь не идёт о конкретных частных случаях.

Ты можешь быть уверен в чём угодно - я не против.
Во всех ОС общего назначения по-умолчанию аналог PAX MPROTECT не активирован => уязвимость оставлена для эксплуатации примерно везде.

> ага, не аналог, а лучше, удобнее, красивее! :)) И не на твой взгляд, а прям-таки объективно. В такой вот позиции ты стоишь.

Ну я сразу писал, почему "удобнее и красивее", а то, что ты прочитал не то, что я написал - это _твои_, а не мои проблемы.
Он позволяет решить примерно те же проблемы, что и PAX MPROTECT, однако, в тех случаях, когда он неприминим по объективным причинам, pledge позволяет ограничить процесс другими, не связанными с PAX MPROTECT защитами.
Конкретно возможность отозвать prot_exec - аналог PAX MPROTECT.

> примеры были не про потенциальную неэффективность ...., а к тому, что ограничения PROT_EXEC нужно включать как можно раньше.

Это одно и то же.
А вот возможность динамически включать pledge с бОльшей вероятностью позволит найти возможность понизить уровень защиты всё также динамически.
Захардкоженная реализация более дубовая и ради этой дубовости можно пожертвовать какими-то другими кейсами.

>> Неисполнимую память тоже пытаются обходить, я про всяческий ROP.
> И что теперь, ничего не предпринимать и удешевлять во всех смыслах стоимость проведения атаки?

Сопоставлять цели, средства и прочие возможности.
Универсального ответа тут, имхо, нет. Каждое принятое решение плохо хоть в чём-то, идеальных - нет.

> Да не нужно их отдельно защищать. То, что ты начал рассуждать об отсуствии "больших проблем", не отменяет факта, что pledge можно использовать и в самом раннем коде. Снова самораскрываешься же. Ничто не мешает вызывать pledge из кода ld.so, а запрос на запрет того же PROT_EXEC передавать, например, через ELF-заголовок, который добавлять в setuid/setgid-экзешник на этапе сборки или после.

Отдельно защищать - проще. Суидные бинарники по пальцам можно пересчитать. Городить инфру для общего случая - гораздо сложнее.

> Чтобы pledge там применить результативно, а не для галочки, нужно проектировать браузер под него или аналогичные средства, вроде SECCOMP. Чтобы какую-то существенную поверхность атаки браузера запускать в сэндбоксе. Чем разработчики хрома в гугле и занимаются, например.

Разработчики pledge говорят слово в слово также. И с ff так долго колупались как раз потому что он (якобы, не проверял) сделан в этом месте хуже.

> Может быть, потмоу, что я так не хочу? Ты просто не видишь разницы между желаниями и предполагаемыми целями при решении задачи. Ну или придуриваешься. Ты тоже варппер придумал, на базе execpromises. Зачем ты его хочешь? Ах, прямым текстом сказал, что не хочешь? Ну так и я тебе прямым текстом сказал, что не хочу.

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

> Возьми да порассуждай, какие возможны варианты. Снова всё разжёвывать - от области применения до принципов реализации и настройки предпочтений пользователем?

Ну вот я и порассуждал. И пришёл к выводу, что это достаточно сложно. Не невозможно, а сложно. И не понятно зачем. Закрыть вектор атаки, который можно закрыть более простым способом?
Можно. Но мне (и, как я понимаю, разработчикам pledge) кажется это не оправданным.

> И всё-то для тебя слишком сложно, бедненький. Да, гибкость инструмента предполагает, что с его помощью можно решать и сложные задачи, и издержки соответсвующие нести. А можно решать и задачи попроще. Свобода выбора - она такая. Если самостоятельно патчить исходники, добавляя pledge, тоже что-то может сломаться. И?

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

Да, отсутствие динамики снижает гибкость инструмента, но даёт ему другие плюсы. Pledge - не сорт MAC и не пытается им быть, он не пытается быть гибким, он пытается быть железобетонным. Это не значит, что MAC плохо, а pledge хорошо; не значит это и обратного.

Если самостоятельно патчить, то тоже, безусловно, может сломаться. Но это можно покрыть тестами и/или оставить на откуп разработчику ПО.

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

Ну нет. В одном случае нужен враппер и конфиги к нему, в другом - нет. То, что для pledge нужна инфра в ядре - очевидно, но я не про неё.

>> Да, нужно править исходники. Зато не нужна инфраструктура.
> Взаимоисключающие утверждения.

См. выше. Я про ОС.

> Сравниваешь в категориях лучше-хуже, красивее-уродливее, удобнее-неудобнее.

Нет. Сравниваю в категориях сброс привилегий vs принудительный контроль доступа. Это разные подходы, решающие проблемы по разному.
Что _удобнее_ решать одним, что-то другим. Под удобнее я подразумеваю очевидное: priv revocation позволяет сбросить изнутри самого процесса больше привилегий, чем можно отозвать снаружи.
В то время как изнутри процесса сделать настраиваемый MAC, конечно, можно, но внешнее универсальное решение будет лучше и правильнее, хотя бы потому что подходит для любого ПО без модификации.

> Я ошибся, признаю.

Спасибо.

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

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

> Вот лучше б ты сразу думал. Дело не в том, чтобы больше знать или мериться, а в том, чтобы не лениться думать.

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

> Нет, не все "hardened-вариации" загнулись. Спонсорские (теперь клиентские) - остались. И появились новые. А на мантры "про специализированное решение и общее решение" я уже ответил.

Я не сомневаюсь, что приватные решения на базе grsec или чего-то ещё цветут и пахнут. Мантры - это не мантры, это рамки, в границах которых, на мой взгляд, есть смысл проводить сравнение.
Но не понимаю, что тебя так огорчает в специализированности решений, которые милы твоему сердцу (худ. оборот, не принимай близко).
Если сравнивать абстрактно, то прогрессивных митигаций и не только в grsec больше чем в OpenBSD.
Можно сравнить рынок спец. решений, долю grsec и OpenBSD там (про опёнок, например, лично я, в этом контексте слышал ну очень мало, и на уровне слухов. Типа где-то в гос. структурах он используется, только все стесняются признаться). У меня нет чиселок, но я почти уверен, что grsec там представлен в неизмеримо бОльшей степени, нежели OpenBSD.
А на "рынке" ОС общего назначения OpenBSD больше (но очевидно меньше, чем обычного Linux/FreeBSD и т.п.).

> Это факты. Какая мне вообще разница, кто их в комментах на опеннете признаёт и тем более ты?

Ну вот и я не понимаю, какая тебе разница. Это факты, которые я, заметь, не оспариваю.

> По чётко озвученным критериям - не доросли. И это тоже факт.

Если абстрагироваться от области применения, то это корректное утверждение. Какой смысл сравнивать сферических коней в вакууме?
Трактор лучше чем гелик? Комбайн лучше чем автобус?
Вот ты предлагаешь такую же постановку вопроса. Хотя по каким-то характеристикам трактор может быть лучше гелика и т.п.

> А pledge не сводится к запрету PROT_EXEC. Как мне узнать, какие ограничения pledge действуют? Какие "костыли" мне для этого нужно сделать? И почему не-костылей нету в шатном наборе утилит?

Кстати, не знаю. Может такого пока и нет, и я согласен, что это нужно. Пожалуйста, не сообщай, что ты не нуждаешься в моём согласии, я в курсе, мне надо как-то выразить отсутствие возражений - вот.

>> Естественно. Я нигде не утверждал обратного.
> Значит, приложения, для которых не включат PROT_EXEC, окажутся хуже защищены от эксплуатации уявзимостей посредством выполнения произвольного машинного, чем эти же приложения на системах с PaX. Даже в перспективе. ЧТД.

И я изначально топил за то, что pledge не ограничен prot_exec. И другими, связанными с защитой памяти флагами pax.
Ты можешь сказать, что это уже из другой оперы - да.
Но я-то изначально объяснял почему я считаю, что pledge имеет больше шансов быть дефолтным решением, чем PAX.
Это не аналоги, но 1) в openbsd нет pax 2) pledge реализует подмножество возможностей PAX MPROTECT 3) pledge можно использовать, даже когда отозвать prot_exec нельзя.
Безусловно, правильнее было бы сравнить pledge и seccomp. В том смысле, что это идеологически примерно равнозначные вещи.

> в PaX сделано лучше: там есть PAX_EMUTRAMP, а в OpenBSD аналогов нет.

Конкретно это, насколько я понимаю, в pax лучше.

> линуксе есть SECCOMP BPF, который уже позволяет гораздо более гибко задавать ограничения.

Seccomp гибче, но сложнее. Pledge проще и надёжнее. Как по мне, для такого инструмента избыточная гибкость скорее во вред.
Нужно просто помнить, что priv revocation - это только priv revocation, и там, где его возможностей не хватает, нужен другой инструмент. Тот же MAC, как пример.

> Важно, что он не решает проблем, которые решает PaX.

Всех - безусловно. Какое-то подмножество проблем - да. Про это подмножество речь в первом сообщении и шла.
И да, я считаю, что так, как эти проблемы решает pledge (неотзываемо из кода программы) - правильнее.

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

Я понимаю. И что? Сколько раз мне ещё повторить, что я не считаю разработчиков grsec даунами-неудачниками, а grsec - бесполезной фигнёй?
И наличие поддержки - это тоже плюс, который я осознаю.
Но ты согласен, что это всё в любом случае не для всех и в т.ч. - по задумке?
В конце концов, чем закончились попытки протолкнуть grsec в ядро ты и без меня знаешь - ребята из grsec может быть и рады были делиться своими наработками с апстримом, сам апстрим не захотел этого as-is. А grsec'и - переписывать (и хорошо обосновали, почему). Но и апстрим обосновал почему он хочет иначе.
Как по мне, то, что пути основного Linux и grsec разошлись окончательно - это закономерно. Потому что linux - ОС общего назначения, а grsec ориентирован на безопасность и иногда это в ущерб каким-то кейсам.

> И это тоже твои субъективные оценки. И обосновать ты их попытался всё в тех же субъективных и непрозрачных категориях. Когда я говорю о лучших практиках, например, то апеллирую к _общепринятым_ нормам. А ты - сугубо к своим собственным.

Нет, это не мои субъективные оценки. Zero-conf всегда предпочтительнее необходимости настройки, если оно возможно.
А если для удобной настройки требуется ещё побочный демон - то это уже совсем громоздко. Неужели ты никогда не ошибался при конфигурировании софта?

> Последствия-то какие будут, если пакет какое-то время пробудет без PaX-флагов? Давай, думай, рассуждай.

А это уже как повезёт. Может быть и никаких. Само по себе позднее выключение prot_exec тоже не приводит ни к каким последствиям.
Это один из возможных векторов атаки, безусловно, не факт, что он будет использован. Но если его не будет - лучше.
Я понимаю, что также как и некоторые решение в pledge (делающие его неидеальным, которые ты приводил в пример, например), pax(ctl)?d - это компромис.
По озвученным мной причинам - неудачный и является костылём, т.е. конструкцией сбоку от основной.

> Доказательств чего? Что у grsecurity по совокупности и качеству реализаций защитных функций нет аналогов?

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

> Это где такие цели задекларированы, покажи? Мало того, что твои выводы остаются сугубо твоими, не имеют веса и статуса, так ещё и на ложных фактах основаны.

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

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

Давай без лишнего словоблудия. Я писал про то, что PAX MPROTECT "ломает" mprotect, подразумевая (уже не помню, писал я это явно или нет) что на попытку сделать w+x он возвращает ошибку.
Ты отметил, что я написал про убийство процесса и это моя ошибка - я её признал.

> Пытался оспорить тезис о трудозатратах, например.

Я не пытался оспорить, что внедрение pledge требует трудозатрат. Это написано в моём первом же сообщении в этом треде.
Трудозатраты (по задумке) перекладываются на разработчика ПО/мэйнтейнера. В редком случае - пользователя.
Настройка PaX - забота пользователя.
Да, я помню, что приложений под pledge не так много, а PaX давно и успешно используется на практике.
Я про перспективность решений. И да, я могу быть не прав. Почему я думаю, что прав - я написал.

> не аргумент ни в пользу чего-либо, кроме утверждений, которые меня не интересуют. Вроде отсутствия дистрибутива с PaX "для масс".

Да это как раз аргумент. Причём, самый сильный из возможных, потому что это не пустое теоретизирование, а срез реальности.
А приватное решение для N людей не равнозначно общему для эксплуатации in the wild. Что, конечно же, не значит, что оно плохое.

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

А что я должен осознать? Статью, на которую ты сослался я когда-то читал. Будет время - освежу в памяти.
Я привёл неверный пример про grsec и kaslr и констатировал, что ты меня поправил.

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

Молодец. А вот когда мне по работе приходится сталкиваться с тем, как продакшен просаживается по производительности/ломается/глючит и т.п. даже от обычных релизов обычного ядра linux совсем не до шуток про то, как хорошо мне на локалхосте, где я уже не помню сколько лет обновляю ядро и не замечаю никаких проблем, ни с grsec, ни без.
Когда число инсталляций приближается к нескольким тысячам (десяткам тысяч) начинает стрелять даже палка.
А на ноуте у меня всё хорошо, да. И на том, что linux, и на том, что OpenBSD. И даже с условной Haiku, почти уверен, нормально будет.

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

Это пример того, что предпочтение отдаётся пассивным мерам защиты. Рандомизация libc - из той же серии. И я в курсе, что _всех_ возможных проблем это не решает.
Это лучше чем ничего и почти бесплатно в имплементации. Хотя имеет и понятные минусы - например, на дохлом роутере все эти перестройки библиотек и ядра непозволительно долгие и нудные и очень уж хочется отключить их.

> Для классификации ОС на общего назначения и специального я выдвинул свои критерии, _на базе общепринятых_. Согласно моим критериям, дистрибутив общего назначения с grsec-ядром является ОС общего назначения.

При всём уважении (кроме шуток, и да, да, я знаю, что тебе моё уважение не требуется), ты не прав.

> А OpenBSD не является ОС общего назначения

Является.

> Приложений под линукс всё больше, приложений под OpenBSD - всё меньше.

Их число тоже растёт. Но под линукс приложений больше и было бы очень тупо с моей стороны с этим спорить.

> Эмуляция линукса работает всё хуже (если ещё работает - не уточнял),

Её достаточно давно выпилили, в OpenBSD больше ничего такого нет.

> Да и проблемы параллелизмом у ядра OpenBSD на современных многоядерных многопоточных процессорах выводят её из группы ОС общего назначения, существенно сужая область применения.

Над многопоточностью работают, и работают активно. Но в целом, ты обозначил реально имеющиеся проблемы. Только эти проблемы никак не связаны с назначением ОС и безопасностью.
Линукс - ОС общего назначения, и более успешная по очень многим критериям, чем OpenBSD. Я с этим не спорю, доказывать обратное - игнорировать реальность.

> А у тебя критерий один: патчи, а не ядро, которых в стандартной поставке нет.

Потому что из этого следует очень многое. Обрати внимание: я не утверждаю (и не утверждал), что grsec не решает проблем и/или бесполезен. Или что там меньше "секурити-фич", или что они хуже.
Я увтерждаю, что применение grsec as-is по-умолчанию затруднено и никто, в итоге, не захотел делать дистрибутив общего назначения на базе grsec. Что автоматически лишает нас возможности сравнить опыт эксплуатации.
Не с OpenBSD - найди ещё поди продакшен с ней, а с обычным linux, разумеется.

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

Конечно важно. Конечно ограничивает. Только масштабируется она хуже не из-за "секурити-фич" или их отсутствия. Т.е. всё правда, но причём тут это?
Если не понятна логика, почему я вспоминаю, что gsec это патчи, а опёнок - ОС, то заменяй в моих примерах опёнка на "обычный" дистрибутив линукс.

> Ну, про декларируемые цели ты мне ещё расскажешь, где ты их для PaX/grsecurity вычитал. А про реализуемые по факту решения я тебе уже всё сказал.

Ну вот, с их сайта: "grsecurity® is an extensive security enhancement to the Linux kernel that defends against a wide range of security threats through intelligent access control, memory corruption-based exploit prevention, and a host of other system hardening that generally require no configuration."
Ни слова про стандарты.

> А вот как в твои критерии укладываются дистрибутивы, вроде RHEL, где политики SELinux включены по умолчанию?

Никак. Если бы там были PaX патчи и всё было бы сделано для того, чтобы этим можно было пользоваться с эквивалентными возможностями не замечая их наличия (условно), то это тоже была бы ОС общего назначения.
Проблема не в реализованных механизмах, а в целеполагании.

> И которые пользователям "для нормальной работы" приходится отключать, как ты верно заметил. Это ОС общего назначения или специального?

Заявляется, что общего. По факту, насколько я могу судить, это так. SElinux можно отключать, да. Возможно, даже нужно, в каких-то ситуациях. Ну так это просто говорит о том, что, возможно, выбрана неудачная мера обеспечения безопасности по-умолчанию. В винде тоже есть какие-то ACL и какие-то "продвинутые" механизмы защиты, это не делает её специализированной ОС.

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

Само по себе это не преимущество.

> setfattr есть практически во всех системах в отличие от paxctl

В openbsd нету :) Осознанно. Не суть, да.

> чтобы работала проприетарщина вроде скайпа, которая сама проверяет целостность своего экзешника

Аргумент. Но вот в OpenBSD считают, что правильнее, если разработчики skype сами попатчат своё ПО, а не принудят тебя что-то делать, чтобы работало.
Ты можешь сказать, что они никогда этого не будут делать - может и так. Под опенбисиди скайпа вообще нет :)

> Сравнивал тёплоё с мягким. Сам же мне пишешь про различия в назначении MAC и pledge, и сам же их в лоб сравниваешь, впрочем как и с PaX-флагами.

Да, отчасти я сравниваю тёплоё с мягиким, всё верно.

> что все эти инструменты, включая твой любимый pledge, позволяют получить результат с _разными_ свойствами.

Я изначально придерживался именно такой позиции.

> Это не про лучше-хуже, это про факт наличия/отсутствия выбора. Каковое отуствие в данном случае является следствием политики разработчиков OpenBSD. И вот о наличии/отсутствии уже можно говорить в категориях лучше/хуже - для тебя отсутствие лучше, для меня хуже.

SElinux и MAC в контексте нашего спора это не лучше-хуже, а подходит для решения проблемы или не подходит. Для реализации политик MAC pledge не подходит. Никак.
SElinux может часть того, что может pledge, только "снаружи", а не "изнутри". Это не значит, что что-то одно "не нужно", это разные цели и разные инструменты.
И да, я считаю, и, как мне кажется, я это обосновал, что для _своих_задач_ pledge лучше подходит, нежели selinux для этих же задач.

> В линуксе задачи, аналогичные pledge, решает SECCOMP BPF. Не PaX-флаги, не SELinux, не другие LSM-модули, а именно SECCOMP BPF. И вот с ним можно было бы посравнивать pledge напрямую.

Всё так. Но всё началось с prot_exec, в OpenBSD он отзывается через pledge. Только поэтому разговор у нас про сравнение сортов тёплого с сортами мягкого. И я не могу ограничивать себя только подмножеством функций связанных с prot_exec, когда мы сравниваем pledge и pax mprotect. Просто потому что и то и другое сорт privilege revocation, пусть в pax это делается снаружи и принудительно.