> Да нет, я сразу именно про xorg и подумал. Только, емнип, pledge там так или иначе не помог бы.Сразу - это прям сразу? Значит, у тебя в голове вместо целостной картины не один, а два отдельных юз-кейса. Разница ого-го!
> И обрати внимание, что я сказал про то, что не вижу _большой_ проблемы, а также что я согласился с тобой, что с точки зрения безопасности его правильнее отзыать как можно раньше.
Я обратил внимание и уверен, что это не более чем фигура речи. Кроме того, уязвимость, оставленная доступной для эксплуатации не может быть маленькой проблемой, если только речь не идёт о конкретных частных случаях. А она не идёт.
>> И про уязвимости, например, в libc
> Да нет, не туда ты. Я просто изначально стою на позициях, что 1) pledge - не серебрянная пуля 2) не аналог pax_mprotect.
Ага, не аналог, а лучше, удобнее, красивее! :)) И не на твой взгляд, а прям-таки объективно. В такой вот позиции ты стоишь.
> Можно придумать ещё много примеров, когда pledge потенциально(?) не эффективен, и что?
Приведённые примеры были не про потенциальную неэффективность (уж куда-куда, а в код приложений с setuid-root pledge должны добавлять в первую очередь, и сделать это можно в коде ld.so), а к тому, что ограничения PROT_EXEC нужно включать как можно раньше.
> Неисполнимую память тоже пытаются обходить, я про всяческий ROP.
И что теперь, ничего не предпринимать и удешевлять во всех смыслах стоимость проведения атаки?
> В значительной части случаев тех мер, которые позволяет pledge достаточно, отдельные кейсы типа тех suid-бинарников можно защитить как-то отдельно.
Да не нужно их отдельно защищать. То, что ты начал рассуждать об отсуствии "больших проблем", не отменяет факта, что pledge можно использовать и в самом раннем коде. Снова самораскрываешься же. Ничто не мешает вызывать pledge из кода ld.so, а запрос на запрет того же PROT_EXEC передавать, например, через ELF-заголовок, который добавлять в setuid/setgid-экзешник на этапе сборки или после.
> Браузер - это просто _показательный_ кейс, показывающий пример силы подхода.
Нихрена он не показательный, если уж ты об этом хочешь поговорить. Доступ к файлам браузеру - нужен. Выделение исполняемой памяти - нужно. Доступ к видео, аудио и прочим вещам, порождение процессов - тоже нужно. Чтобы pledge там применить результативно, а не для галочки, нужно проектировать браузер под него или аналогичные средства, вроде SECCOMP. Чтобы какую-то существенную поверхность атаки браузера запускать в сэндбоксе. Чем разработчики хрома в гугле и занимаются, например.
> Про реальный мир - из контекста же было понятно, что речь про использование не на специализированных системах, типа военного и гос сектора, а in the wild?
Вся коммерция - in the wild. И персонал, который имеет доступ во все места инфраструктуры - тоже на дистрибутивах общего назначения сидит. Пока ты претендуешь на широкое применение своих оценок, никак ты не обоснуешь низкие шансы на эксплуатацию или возникновения такого интереса, а значит, и избыточность современных мер защиты.
> (мало != "не актуальны"). Возможно, недооценил специфики, например, хостинга.
Ты недооценил специфику любых целей, которые могут представлять интерес для более-менее продвинутой угрозы.
> Не, я правда не понимаю, зачем ты так хочешь.
Может быть, потмоу, что я так не хочу? Ты просто не видишь разницы между желаниями и предполагаемыми целями при решении задачи. Ну или придуриваешься. Ты тоже варппер придумал, на базе execpromises. Зачем ты его хочешь? Ах, прямым текстом сказал, что не хочешь? Ну так и я тебе прямым текстом сказал, что не хочу. Юродствовать любишь?
> Потом автор что-то поменяет в коде программы и что-то может в этой конструкции развалиться.
Возьми да порассуждай, какие возможны варианты. Снова всё разжёвывать - от области применения до принципов реализации и настройки предпочтений пользователем?
> Её придётся поддерживать. Это слишком сложно, тогда как добавить в код - просто (технически).
И всё-то для тебя слишком сложно, бедненький. Да, гибкость инструмента предполагает, что с его помощью можно решать и сложные задачи, и издержки соответсвующие нести. А можно решать и задачи попроще. Свобода выбора - она такая. Если самостоятельно патчить исходники, добавляя pledge, тоже что-то может сломаться. И?
> Это не требует инфраструктуры.
Только в твоих фантазиях, где за пользователя всё в полном объёме сделали разработчики.
>> Преимущества такого подхода в том, что не нужно править исходники. Ты не согласен с тем, что это преимущество, но я чётко и неоднократно озвучил свои предпочтения и требования.
> Само по себе это не преимущество и не недостаток.
Учись читать. Я пишу: "свои предпочтения и требования" - значит, не само по себе, а в рамках моих предпочтений и требований.
> Ты же сам про контекст мне напоминал, не?
Напоминал, да без толку.
> Да, нужно править исходники. Зато не нужна инфраструктура.
Взаимоисключающие утверждения.
> Твои требования и предпочтения - ради бога, я не утверждаю, что ты нуждаешься в OpenBSD. Я сравниваю конкретные подходы.
Сравниваешь в категориях лучше-хуже, красивее-уродливее, удобнее-неудобнее.
> И я в курсе, если ты не понял, что пока не так много программ защищено с использованием pledge, в то время как grsec используется давно и успешно, в своей области.
Я прекрасно понял, что ты в курсе, не волнуйся. А ещё я прекрасно понял, что осмыслить эти обстоятельства ты не в состоянии.
>> Ха, действительно, в OpenBSD нет и, похоже, не было ld.so.preload.
> Звучит, как будто это не ты допустил ошибку, а OpenBSD виновата.
Да? А должно звучать как констатация факта. Меня интересовало, был ли он там изначально, а не кого бы овинить. Хочешь указать на ошибку - укажи. Я ошибся, признаю. Но для моей позиции не принципиально, есть ld.so.preload или нет. А вот своё утверждение, что для обхода игнорирования LD_PRELOAD придётся лепить ещё один костыль, ты сможешь обосновать, только записав в костыли все оставшиеся решения. Которые ты не озвучил, потому что не придумал или не продумал ещё.
>> В любом случае, остаётся как минимум ещё один вариант
> Ради бога. Может быть, я немного подумаю и догадаюсь, о чём ты, а может быть и нет - не сомневаюсь, что ты знаешь немало того, чего я не знаю.
Вот лучше б ты сразу думал. Дело не в том, чтобы больше знать или мериться, а в том, чтобы не лениться думать.
>> Чем, по-твоему, занимаются бизнесы, которые оплачивают подписку на grsecurity? Нет, часть клиентов предлагает специализированные дистрибутивы, о grsecurity в составе которых тебе даже гугль не расскажет.
> Честно, хочешь верь, хочешь нет - ни секунды не сомневался в наличии чего-то подобного.
> Дальше-то что? Это всё _приватное_. Какой смысл сравнивать специализированное решение и общее решение?
А дальше я тебе напомню контекст. Твоё утверждение: "А после того, как код grsec закрыли, и те hardened-вариации дистрибутивов, что были - загнулись." Нет, не все "hardened-вариации" загнулись. Спонсорские (теперь клиентские) - остались. И появились новые. А на мантры "про специализированное решение и общее решение" я уже ответил.
> Ты хочешь, чтобы я признал (лол)
Нет, я хочу, чтобы ты продолжал.
> что в grsec разработано больше всяческих техник защиты ядра и не только?
Это факты. Какая мне вообще разница, кто их в комментах на опеннете признаёт и тем более ты?
> Только вот говорить про то, что "OpenBSD не доросли до grsec" (или как ты там написал) - некорректно, потому что одно - ОС, другое набор патчей.
По чётко озвученным критериям - не доросли. И это тоже факт.
>> в том числе и такое, вроде Mathematica, которое для "ОС общего назначения" OpenBSD даже не выпускаются. ;)
> А это, конечно, имеет такое отношение к обсуждаемым темам? Я в курсе, какая *nix ОС сейчас самая популярная, спасибо.
Самое прямое.
>> что каждый пакет и каждая новая его версия была собрана именно с pledge
> Процессы в ps помечаются "p". Это можно даже автоматизировать, если это важно. А так да, если важно - проверять.
Список PaX-флагов я вижу чётко в /proc/[pid]/status для каждого процесса. А pledge не сводится к запрету PROT_EXEC. Как мне узнать, какие ограничения pledge действуют? Какие "костыли" мне для этого нужно сделать? И почему не-костылей нету в шатном наборе утилит?
>> есть приложения, для которых PROT_EXEC через pledge в лучшем случае сделают опциональным (и придётся настраивать руками), в худшем - вообще не включат
> Естественно. Я нигде не утверждал обратного.
Значит, приложения, для которых не включат PROT_EXEC, окажутся хуже защищены от эксплуатации уявзимостей посредством выполнения произвольного машинного, чем эти же приложения на системах с PaX. Даже в перспективе. ЧТД.
>> И получится, что запрет PROT_EXEC через pledge тоже нужно настраивать, но через аргументы командной строки, конфиги (множество разных) или переменные окружения.
> Всё верно. Мы можем или также не включать, как в PaX или, _возможно_ попробовать сделать лучше.
Ну так это по факту в PaX сделано лучше: там есть PAX_EMUTRAMP, а в OpenBSD аналогов нет. И это при том, что в линуксе есть SECCOMP BPF, который уже позволяет гораздо более гибко задавать ограничения. Захочешь реализовать полный аналог pledge на библиотечном уровне - пожалуйста. В функциональном плане OpenBSD проигрывает по всем параметрам. Могут выиграть только по охвату и простоте применения, и только в изолированном контексте SECCOMP vs pledge.
> Ну или не сделать, пример ты привёл - pledge не серебрянная пуля, я в курсе, что она решает не все на свете проблемы.
Важно, что он не решает проблем, которые решает PaX.
>> У меня есть. Тебе - нигде.
> Ну так это аргумент "в мою пользу", а не в твою. С тем что приватно бывает очень всякое я никогда не спорил.
Это ответ на твой вопрос, а не аргумент. Хочешь аргумент - пожалуйста. Теперь те, кто заинтересован в получении доступа к grsecurity, могут попытаться договориться и заплатить, получив в ответ не просто тот же набор патчей, что получили бы раньше бесплатно, но и высококачественную поддержку, и возросшую скорость реакции проекта на появление новых классов и способов эксплуатации уязвимостей. Напоминаю, что комплексная защита от атак на микроархитектуру на данным момент есть толкьо в grsecurity и больше _нигде_, и является следсвием коммерциализации проекта.
>> Видишь, тебе _отвратителен_ сам подход. Какие ты от меня технические аргументы в ответ на отвращение хочешь услышать-то?
> Я писал и про то, что наличие дополнительного процесса, работающего со входными данными от пользователя и управляющего безопасностью приложений - это плохая практика.
И это тоже твои субъективные оценки. И обосновать ты их попытался всё в тех же субъективных и непрозрачных категориях. Когда я говорю о лучших практиках, например, то апеллирую к _общепринятым_ нормам. А ты - сугубо к своим собственным.
> Потому что это логика сбоку от пакетного менеджера. Потому там могут быть ошибки. Потому что он может упасть, а с обновлением приедет пакет без pax-флагов.
Как упадёт, так и поднимется - вопрос наличия супервизора. Так-то и sshd тоже упасть может, и ПО, существование которого деньги приносит. Последствия-то какие будут, если пакет какое-то время пробудет без PaX-флагов? Давай, думай, рассуждай.
> Не сомневаюсь, что ты или проигнорируешь это или объявишь несущественным.
Ошибся. Я объявлю это надуманной проблемой. А твои попытки раздуть её до существенных масштабов - не более, чем таковыми. paxctld, как я уже писал, решает более широкий перечень задач, чем пакетный менеджер - так ты вообще этого не заметил. Вот уж действительно, в чём я не сомневался.
>> То есть, примерно везде, где востребован уровень защиты наилучший из практически достижимых по совокупности требований на сегодняшний день.
> Доказательств ты, разумеется, не предоставишь. Не, я охотно допускаю, что всё так, но сам факт.
Доказательств чего? Что у grsecurity по совокупности и качеству реализаций защитных функций нет аналогов? Так это ты своё невежество выпячиваешь, спрашивая у меня доказательства. Такие вещи знать надо.
>> А кто сказал, что оно нишевое? Ты. А на каком основании? Может быть, есть общепринятые представления, классификация ОС? Нет. Может быть, ты эксперт и даёшь экспертное заключение? Тоже нет. Утверждение о нишевости - твоё личное мнение, которое ты очень хочешь выдать за авторитетное.
> А это напрямую следует из их приватности и декларированных целей - предоставлять максимальную безопасность насмотря на стандарты (например).
Это где такие цели задекларированы, покажи? Мало того, что твои выводы остаются сугубо твоими, не имеют веса и статуса, так ещё и на ложных фактах основаны.
>>> PAX MPROTECT прибивает процесс, который вызывает mprotect, добавляющий PROT_EXEC
>> Не прибивает, а возвращает EACCES. Поэтому
> Да, это ты по делу, а я нет. Я не могу сказать, что на самом деле я тогда хотел сказать, или имел ввиду, но так или иначе, по факту я написал херню.
Ага. И даже не попытался разобраться, почему херню написал. Я это сделал за тебя выше, не благодари.
> Но странно, ведь по контексту _нашей_ беседы, уж что что, а то, что я понимаю, что делает pax_mprotect следует. Стоит ли так передёргивать?
Из контекста нашей беседы, который, представь себе, включает и те аспекты, которые здесь затронуты не были, следует как раз то, что ты не понимаешь, что делает PAX_MPROTECT. Это если говорить о полном понимании, с учётом всех известных и даже очевидных обстоятельств, вроде синергии с TPE. Речь не о каких-то деталях реализации, а о существенных аспектах, о большинстве которых ты был бы в курсе, если бы внимательно читал, запоминал и анализировал хотя бы текст help'ов в Kconfig.
> Впрочем, ты всё равно будешь - успехов.
Успехи достигнуты, но не в них суть.
>> О нём уже можно сказать ... полнотой своего применения.
> А где я опровергал что-то из написанного тобой тут?
Пытался оспорить тезис о трудозатратах, например. А вообще я лишь резюмировал, что уже можно сказать.
>> Для масс содержимое paxctld.conf могло бы управляться пакетным менеджером
> Могло бы. Реальность иная и моей вины в этом нет. Это и есть аргументы, а не "выдуманные сложности".
Мой юный друг, говорить о возможных перспективах позволительно не тебе одному. Уясни это. И твои "аргументы" (почему-то во множественном числе) - не аргумент ни в пользу чего-либо, кроме утверждений, которые меня не интересуют. Вроде отсутствия дистрибутива с PaX "для масс".
>> В grsecurity KASLR от-клю-чён.
> Да, ошибка. Я что-то перепутал, был уверен в обратном.
Тут случай, когда осознание ошибки отнюдь не говорит о том, что она будет осмыслена.
>> Нет, факты того, что в стремлении не просадить производительность они от кого-то отличаются, а конкретно от PaX и grsecurity.
> А я не хочу ничего такого доказывать.
Вот и славно.
> Дистрибутивов общего назначение с grsec внутри нет - нет возможности наокпить опыт с сравнить производительность до и после.
Глупое утверждение. Вот я сижу сейчас на дистрибутиве общего назначения, но ядро с grsecurty. Могу измерить призводительность, загрузиться со штатным дистрибутивным ядром, снова измерить. Ничто не мешало раньше и в известных рамках не мешает сейчас. Ты просто пыжишься и пытаешься создать видимость какой-то неопределённости. Spreading FUD.
> Согласен, из контекста выглядит так, будто я конкретно в этом противопоставлял openbsd grsec'у. Нет, я просто перечислял, чиселок с grsec у меня нет, и я на это не намекал.
Значит, теперь намекаешь. Есть старые версии grsec, в конце концов, включая относительно недавнюю утечку исходников. Кому надо - опыт накопит.
>> Ну-ка, ну-ка, какие там накладные расходы на KASLR?
> Копейки, но они есть. А KARL - не рантайм процедура.
Так какие, конкретно? И в чём существенная разница c KARL? Ты же его в пример привёл, как в OpenBSD производительность берегут: что вот KARL позволяет какихт-то накладных расходов избежать. Так выходит, и пример у тебя копеечный.
> Сравнивай условный debian до pax и с pax, зачем тут OpenBSD? Приложений под неё меньше, и для меня это не новость, но это по другим причинам.
Для классификации ОС на общего назначения и специального я выдвинул свои критерии, _на базе общепринятых_. Согласно моим критериям, дистрибутив общего назначения с grsec-ядром является ОС общего назначения. Которая решает задачи общего назначения - тот же их перечень, что и линукс без grsecurity. А OpenBSD не является ОС общего назначения или является ей в меньшей степени, с тенденцией к уменьшению, поскольку круг задач, которые она позволяет решить, ограничен более узким перечнем доступных и работоспособных приложений. Приложений под линукс всё больше, приложений под OpenBSD - всё меньше. Эмуляция линукса работает всё хуже (если ещё работает - не уточнял), не поспевая за его развитием. Да и проблемы параллелизмом у ядра OpenBSD на современных многоядерных многопоточных процессорах выводят её из группы ОС общего назначения, существенно сужая область применения. А у тебя критерий один: патчи, а не ядро, которых в стандартной поставке нет. Ну, мой юный друг... OpenBSD в стандартной поставке ОС общего назначения тоже нет. ;)
> Ты ещё про то, что она масштабируется хуже, например, вспомни, ага.
И вспомнил, потому что это действительно важно. Это существенно ограничивает область применения на практике. Ты не согласен с этим?
> Критерии - декларируемые цели / реализуемые по факту решения.
Ну, про декларируемые цели ты мне ещё расскажешь, где ты их для PaX/grsecurity вычитал. А про реализуемые по факту решения я тебе уже всё сказал. А вот как в твои критерии укладываются дистрибутивы, вроде RHEL, где политики SELinux включены по умолчанию? И которые пользователям "для нормальной работы" приходится отключать, как ты верно заметил. Это ОС общего назначения или специального?
>> Тебе не надо, а мне надо. "Ни в коем случае" - типичный нигилизм и неуважение к чужому мнению. Один ты умный с правильным мнением, да разработчики OpenBSD. У всех остальных мнение неправильное.
> Цели задеть тебя не было, если ты об этом.
Нет, я о твоих претензиях на авторитетное мнение.
