>> Я обратил внимание и уверен, что это не более чем фигура речи. Кроме того, уязвимость, оставленная доступной для эксплуатации не может быть маленькой проблемой, если только речь не идёт о конкретных частных случаях.
> Ты можешь быть уверен в чём угодно - я не против.Это ты на словах не против. А на деле две недели упражняешься в зарабатывании права на жизнь для своего мнения и претензий на его объективность. Если это не фигура речи, то очередной бесполезный тезис с привлечением чисто субъективного критерия.
> Во всех ОС общего назначения по-умолчанию аналог PAX MPROTECT не активирован => уязвимость оставлена для эксплуатации примерно везде.
Аргумент к опыту миллиона мух не принимается. У них по той же причине "оставлен для эксплуатации" не только данный класс уязвимостей, но и все остальные. В том числе RCE. И это с точки зрения "миллионов мух", видимо, тоже не является "большой проблемой".
> Ну я сразу писал, почему "удобнее и красивее", а то, что ты прочитал не то, что я написал - это _твои_, а не мои проблемы.
Я прочитал как раз то: претензии одного мальчика на объективность собственного мнения, сформулированного в чисто субъективных категориях, которым подчинены остальные его аргументы.
> Он позволяет решить примерно те же проблемы, что и PAX MPROTECT [...] Конкретно возможность отозвать prot_exec - аналог PAX MPROTECT.
ПроблеМЫ? То есть, ты претендуешь на объективную оценку сходства множества проблем. А сходство там только одно: в некоторых ситуациях PAX_MPROTECT тоже запрещает использование PROT_EXEC. В чём различия и почему они существенны, ты не знаешь и не понимаешь.
>> примеры были не про потенциальную неэффективность ...., а к тому, что ограничения PROT_EXEC нужно включать как можно раньше.
> Это одно и то же.
Нет, не одно и то же. От того, что pledge нужно вызывать как можно раньше, он не становится потенциально неэффективен. Его _можно_ вызывать как можно раньше. Запрет pledge на PROT_EXEC уже подготовлен для активации на самой ранней стадии. Но ты не смотрел в исходники и этого не знаешь. Или не понимаешь. Чукча не читатель, чукча писатель.
> А вот возможность динамически включать pledge с бОльшей вероятностью позволит найти возможность понизить уровень защиты всё также динамически.
Снова возникло непреодолимое желание врапперы обсудить? Ты отвечаешь на реплику о каноническом использовании pledge, а не о динамическом: через добавление в исходники, а не через врапперы.
> Захардкоженная реализация более дубовая и ради этой дубовости можно пожертвовать какими-то другими кейсами.
Ты ещё за всех порешай, какими кейсами можно пожертвовать.
> Сопоставлять цели, средства и прочие возможности. Универсального ответа тут, имхо, нет. Каждое принятое решение плохо хоть в чём-то, идеальных - нет.
Вижу, тебе о судьбах мира в масштабах всей Земли захотелось порассуждать. Бессодержательность требует выражения.
> Отдельно защищать - проще. Суидные бинарники по пальцам можно пересчитать. Городить инфру для общего случая - гораздо сложнее.
Не знаю, какая там "инфра для общего случая" тебе в голову взбрела, а линковщик уже обрабатывает setuid-бинарники как особый случай. И запрет pledge на PROT_EXEC уже подготовлен для активации на ранней стадии. Я смотрю, ты совсем зарвался. Утверждаешь, что "отдельно защищать - проще", так предъяви конкретику, мальчик. Это ведь _твой личный_ тезис. Спрятаться под юбку к разработчикам OpenBSD или ещё к кому-то тут не получится. Тут за свои слова отвечать надо.
> Ну так почему бы не писать, что "ты так не хочешь", а не писать, как бы ты сделал враппер?
Из технических соображений о реализации враппера и её свойствах желание его писать не следует никак. Я уже обозначил, что не пользуюсь OpenBSD. Тебе этого мало? Влючай мозги.
> Да, безусловно, это ограничивает область применения и может не подходить для решения лично твоих задач. И это _нормально_.
Часть этих "лично моих" задач существует в рамках любой модели угроз с локальным непривилегированным присутствием атакующего в системе. Пример: защита от повышения привилегий путём эксплуатации уязвимостей в setuid-root экзешниках через выполнение произвольного машинного кода. У тебя другая модель? Озвучь. Реальность же такова, что сейчас эти задачи в OpenBSD не решаются никак. Ни в каждом случае, ни даже для базовой системы, защённость по умолчанию которой они выпячивали.
> Ну вот я и порассуждал. И пришёл к выводу, что это достаточно сложно. Не невозможно, а сложно.
Пришёл к выводу, но конечно же не считаешь нужным поделиться конкретными рассуждениями. И вот так у тебя во всём: или делишься и садишься в лужу, как с враппером, или бегаешь под юбку к кому-то. Якобы много знаешь, как делать не надо, а как делать надо - или не знаешь или стесняешься сказать.
> Ну да, сложно. Если для тебя это всё на полностью серьёзных щщах просто - могу только искренне тебе позавидовать, без всякой иронии.
Не "это всё", а конкретные вещи, в конкретных рамках.
> А вот мне - сложно. Разработчикам pledge, судя по всему, тоже.
> Не теоретическое решение для спора на форуме, а полноценное, общее решение.
А ты за их спины не прячься и мотивацию не додумывай. Никак конкретно свои личные опасения ты не обосновал. А многозначительно руками махать и объезьяна может.
>>> Это не требует инфраструктуры.
>> Только в твоих фантазиях, где за пользователя всё в полном объёме сделали разработчики.
> Ну нет. В одном случае нужен враппер и конфиги к нему, в другом - нет.
В одном случае нужен враппер с конфигами, а в другом - инфраструктура сборки, тестирования и доставки пакетов + время на выполнение работ и/или взаимодействие с третьими лицами.
> См. выше. Я про ОС.
Разумеется. Тебе ведь хочется задать искусственные рамки, чтобы пренебрегать обстоятельствами реального мира.
>> Сравниваешь в категориях лучше-хуже, красивее-уродливее, удобнее-неудобнее.
> Нет.
Не нет, а да. И главное, с претензией на объективность.
> Сравниваю в категориях сброс привилегий vs принудительный контроль доступа. Это разные
> подходы, решающие проблемы по разному.
Все эти "категории" у тебя находятся в подчинении у субъективны. Строчкой ниже наглядный тому пример.
> Что _удобнее_ решать одним, что-то другим.
Здесь ты говоришь об удобстве, а не о "сброс привилегий vs принудительный контроль доступа". И не уточняешь, что так удобно лично тебе, а снова пытаешься решать за всех.
> Под удобнее я подразумеваю очевидное: priv revocation позволяет сбросить изнутри самого процесса больше привилегий, чем можно отозвать снаружи.
А вот лично мне и множеству других людей гораздо важнее не то, что pledge позволяет сделать в теории и перспективе, а что он позволяет или не позволяет сделать на практике. А на практике и в частости в контексте ограничений PROT_EXEC он позволяет сделать ещё меньше, чем PAX_MPROTECT и PAX_EMUTRAMP - даже когда фактически используется приложением, а не в силу обратного. Например, если приложению нужно подключать .so-плагины на поздних стадиях, запрет PROT_EXEC уже нельзя включать через pledge. А вот PAX_MPROTECT - можно. Ты ничего из этого не знаешь и не понимаешь, но берёшься рассуждать и решать за всех. Продолжай в том же духе.
> В то время как изнутри процесса сделать настраиваемый MAC, конечно, можно, но внешнее универсальное решение будет лучше и правильнее, хотя бы потому что подходит для любого ПО без модификации.
На примере этой реплики хорошо видно, как ты сравниваешь средства решения задач, но не сами практические задачи в контексте практических же моделей угроз. Да и кругозора не хватает: ничего не знаешь об интеграции MAC и в частности SELinux с приложениями.
>> А вот своё утверждение, что для обхода игнорирования LD_PRELOAD придётся лепить ещё один костыль, ты сможешь обосновать, только записав в костыли все оставшиеся решения.
> "костыль", согласись, очень условное понятие, и зависит оно от постановки целей и имеющихся в наличии возможностей?
Представь себе, соглашусь. Вот только ты сам себе противоречишь, когда принимаешься решать за всех, что костыль, а что не костыль.
> Так вот: я называю возможные тут решения костылями, потому что отсутствие динамики в контексте pledge - это задумка.
> А не потому что ты предлагаешь что-то, на мой взгляд, невообразимо плохое.
Тут важнее другое. Не то, ЧТО ты назваешь костылём, а твой изначальный тезис, будто бы костыль придётся городить, то есть, создавать. Ты пытаешься подменить его другим и направить обсуждение в удобное для тебя русло. Тогда как мой исходный тезис остаётся прежним: для подключения враппера к экзешникам, включая setuid-root, можно использовать уже существующие и доступные средства и способы. Ничего нового, никакой "ещё один костыль" городить не нужно.
>> Вот лучше б ты сразу думал. Дело не в том, чтобы больше знать или мериться, а в том, чтобы не лениться думать.
> Я бы не отказался обладать достаточным кругозором, чтобы не задумываясь догадываться о возможных решениях, но конкретно в рамках данного вопроса это, как по мне, не самая актуальная повестка.
Резюмирую. 1. У тебя не хватает омпетенций для обсуждения затронутых тобой же вопросов по существу. 2. И прилагать умственные усилия ты не хочешь.
>> Нет, не все "hardened-вариации" загнулись. Спонсорские (теперь клиентские) - остались. И появились новые. А на мантры "про специализированное решение и общее решение" я уже ответил.
> Я не сомневаюсь, что приватные решения на базе grsec или чего-то ещё цветут и пахнут.
Они не приватные, а платные и доступны широкому кругу лиц.
> Мантры - это не мантры, это рамки, в границах которых, на мой взгляд, есть смысл проводить сравнение.
А на мой взгляд - рамки другие. Но ты ведь не только с ними не согласен, но и с тем, что твоё мнение ничем не лучше моего. Поэтому все твои реверансы в сторону разумной скромности а ля "на мой взгляд" - не более, чем пустые и безответственные слова.
> Но не понимаю, что тебя так огорчает в специализированности решений, которые милы твоему сердцу (худ. оборот, не принимай близко).
Ты вообще мало, что понимаешь. В основном тебе только кажется. Вот и сейчас тебе кажется, что меня что-то огорчает.
> Если сравнивать абстрактно, то прогрессивных митигаций и не только в grsec больше чем в OpenBSD.
А если сравнивать конкретно, в рамках практических моделей угроз, то окажется, что в grsec их не только больше, но они ещё и более качественно выполнены: более полны, комплементарны и лучше отвечают требованиям.
> Можно сравнить рынок спец. решений, долю grsec и OpenBSD там
Неинтересно.
>> Это факты. Какая мне вообще разница, кто их в комментах на опеннете признаёт и тем более ты?
> Ну вот и я не понимаю, какая тебе разница. Это факты, которые я, заметь, не оспариваю.
Ну конечно не понимаешь, кто б сомнвался. Я их привожу для создания контекста. И технические доводы привожу ровно с той же целью. И вот сам контекст уже выполняет целый ряд нужных мне функций.
>> По чётко озвученным критериям - не доросли. И это тоже факт.
> Если абстрагироваться от области применения, то это корректное утверждение. Какой смысл сравнивать сферических коней в вакууме?
Задай этот вопрос себе. Ты же рвёшься абстрагироваться от конкретики, не я.
> Трактор лучше чем гелик? Комбайн лучше чем автобус?
> Вот ты предлагаешь такую же постановку вопроса. Хотя по каким-то характеристикам трактор может быть лучше гелика и т.п.
Нет, это ты мне рассказываешь, что условный гелик становится условным трактором после условной смены замков, сигнализации и покрытия поверхностей защитным составом.
>> А pledge не сводится к запрету PROT_EXEC. Как мне узнать, какие ограничения pledge действуют? Какие "костыли" мне для этого нужно сделать? И почему не-костылей нету в шатном наборе утилит?
> Кстати, не знаю. Может такого пока и нет, и я согласен, что это нужно.
Это нужно, но этого нет. Опять перспективы вместо реальных рабочих решений.
>>> Естественно. Я нигде не утверждал обратного.
>> Значит, приложения, для которых не включат PROT_EXEC, окажутся хуже защищены от эксплуатации уявзимостей посредством выполнения произвольного машинного [кода], чем эти же приложения на системах с PaX. Даже в перспективе. ЧТД.
> И я изначально топил за то, что pledge не ограничен prot_exec. И другими, связанными с защитой памяти флагами pax. Ты можешь сказать, что это уже из другой оперы - да.
Я скажу, что лично мне не интересна альтернатива, которая не позволяет даже PROT_EXEC ограничить для целого ряда случаев. Построить защищённый JIT-компилятор она тоже не позволяет, в отличие от PAX_MPROTECT. Не вижу смысла в таком решении _вместо_ подхода PaX, если самым базовым практическим требованиям оно не удовлетворяет. Не имею ничего против pledge в качестве комплементарной меры, но на большее она в текущей реализации претендовать не может - ни в каноническом формате применения, ни с врапперами или другими механизмами настройки ограничений пользователем.
> Но я-то изначально объяснял почему я считаю, что pledge имеет больше шансов быть дефолтным решением, чем PAX.
В отрыве от реальных требований безопасности это бессмысленно обсуждать. Изначально ты выдвинул ряд тезисов - в том числе, что PaX хуже pledge. И не в перспективе, а прямо сейчас.
> Это не аналоги, но 1) в openbsd нет pax 2) pledge реализует подмножество возможностей PAX MPROTECT 3) pledge можно использовать, даже когда отозвать prot_exec нельзя.
В контексте практических моделей угроз и реально существующих приложений важно то, что в ряде случаев, когда PROT_EXEC можно ограничить с помощью PAX_MPROTECT и PAX_EMUTRAMP, через pledge в текущей реализации его "отозвать" нельзя.
> Безусловно, правильнее было бы сравнить pledge и seccomp. В том смысле, что это идеологически примерно равнозначные вещи.
У SECCOMP, кстати, та же проблема с PROT_EXEC: он не позволяет "отозвать" его достаточно гибко, в отличие от PAX_MPROTECT и PAX_EMUTRAMP. Поэтому, как и pledge, в качестве комплементарной меры годится, но не более.
>> в PaX сделано лучше: там есть PAX_EMUTRAMP, а в OpenBSD аналогов нет.
> Конкретно это, насколько я понимаю, в pax лучше.
И не только это. Я не поленился и посмотрел код pledge для ограничения PROT_EXEC - там банальный полный запрет после первого вызова kbind(). Расскажи мне теперь о перспективах, как в OpenBSD возьмут да доведут pledge до ума, до уровня PaX. Когда-нибудь. И вот тогда заживём.
>> линуксе есть SECCOMP BPF, который уже позволяет гораздо более гибко задавать ограничения.
> Seccomp гибче, но сложнее. Pledge проще и надёжнее.
Главная проблема SECCOMP BPF в том, что он позволяет фильтровать системные вызовы, но не меняет логику их работы. А вот pledge меняет. И это было бы плюсом в случае PROT_EXEC, если б реализация ограничений на его использование не сводилась к банальному безусловному запрету, аналогично SECCOMP BPF.
> Как по мне, для такого инструмента избыточная гибкость скорее во вред.
Как выяснилось, у него и базовой-то гибкости нет.
>> Важно, что он не решает проблем, которые решает PaX.
> Всех - безусловно. Какое-то подмножество проблем - да. Про это подмножество речь в первом сообщении и шла.
Ага, подмножество из одного элемента.
> И да, я считаю, что так, как эти проблемы решает pledge (неотзываемо из кода программы) - правильнее.
И считай себе наздоровье.
>> Теперь те, кто заинтересован в получении доступа к grsecurity, могут попытаться договориться и заплатить, получив в ответ не просто тот же набор патчей
> Я понимаю. И что?
Это к твоему тезису: "Ну так это аргумент "в мою пользу", а не в твою." Тот аргумент, а вернее обстоятельства, на которые он ссылается, однозначно "ни в чью пользу" не говорят.
> Сколько раз мне ещё повторить, что я не считаю разработчиков grsec даунами-неудачниками, а grsec - бесполезной фигнёй?
Видмо, столько раз, сколько раз ты за меня додумаешь. Не нравится - потрудись если не отследить и не понять, то хотя бы спросить у меня контекст и смысл.
> И наличие поддержки - это тоже плюс, который я осознаю.
> Но ты согласен, что это всё в любом случае не для всех и в т.ч. - по задумке?
Это стало не для всех по факту закрытия доступа. А по задумке, по области применения - для всех. Я уточнил у автора PaX, он подтвердил: "i've always worked on defenses that can be applied to anything" Так что свои домыслы с претензиями на авторитет можешь применить по назначению.
> В конце концов, чем закончились попытки протолкнуть grsec в ядро ты и без меня знаешь
Разумеется, знаю, но не без тебя, а в отличие от тебя. Потому что со стороны авторов PaX и grsec таких попыток не предпринималось. Никогда. И желания они такого не высказывали. Максимум - предлагали обсудить возмездную помощь апстриму в портировании.
> ребята из grsec может быть и рады были делиться своими наработками с апстримом, сам апстрим не захотел этого as-is.
Продолжай трепать языком о том, чего не знаешь.
> А grsec'и - переписывать (и хорошо обосновали, почему). Но и апстрим обосновал почему он хочет иначе.
Ты говоришь так, как будто апстрим что-то аргументированно обосновал. ;) Не было ничего, кроме претензий, что авторы PaX и grsec не хотят работать забесплатно и патчи свои на части для включения в апстрим разбивать.
> Как по мне, то, что пути основного Linux и grsec разошлись окончательно - это закономерно.
Разойдутся, когда/если grsec станет форком ядра.
> Потому что linux - ОС общего назначения, а grsec ориентирован на безопасность и иногда это в ущерб каким-то кейсам.
Это всё твои домыслы. По факту grsec задумывался и позиционируется именно как решение для широкого круга задач, в том числе и в рамках ОС общего назначения. Разумеется, ты не привык, что у пользователя есть выбор - его делают в OpenBSD за тебя. В случае с grsec всё иначе. Осознай, если сможешь.
>> И это тоже твои субъективные оценки. И обосновать ты их попытался всё в тех же субъективных и непрозрачных категориях. Когда я говорю о лучших практиках, например, то апеллирую к _общепринятым_ нормам. А ты - сугубо к своим собственным.
> Нет, это не мои субъективные оценки. Zero-conf всегда предпочтительнее необходимости настройки, если оно возможно.
Нет, именно твои субъективные. Ты очень хочешь примазаться к авторитету лучших практик, но на деле "zero-conf" предпочтительнее при прочих равных качествах результата, о чём речи и близко не идёт.
> А если для удобной настройки требуется ещё побочный демон - то это уже совсем громоздко. Неужели ты никогда не ошибался при конфигурировании софта?
Вот, в этом весь ты, как ты есть. Продолжаешь навязывать мне свои критерии. Где же твои оговорки в стиле и духе "мне кажется"? Вижу, все претензии на месте.
Ещё раз для альтернативно одарённых повторяю: мне лично paxctld нравится. Я лично перешёл на него с хуков dpkg. Потому что мне лично удобнее. И рамки запретов по умолчанию - тоже удобны. Ну а то, что ошибиться можно - так и в слове из трёх букв можно четыре ошибки сделать. Некоторые делают. И что? Попытаешься в очередной раз "объективно обосновать" свои впечатления в лице "совсем громоздко"? Про сложность paxctld.conf мне расскажешь? Тебя просто не устраивает, что эти твои субъективные критерии - именно субъективные. Потому что изначально ты заявил претензию на их объективность, а отказаться от неё - незрелое уязвлённое самолюбие не позволяет.
