> Можешь считать, что я слился и так далее - мне безразлично.Очевидно, что не безразлично. Но мне удобнее, чтобы ты не слился, а наоборот продолжал.
> Тогда у меня нет адеватных идей, зачем могли перейти на xattr.
За тем, что это более универсальный способ. Во-первых, setfattr есть практически во всех системах в отличие от paxctl. Во-вторых, чтобы работала проприетарщина вроде скайпа, которая сама проверяет целостность своего экзешника. И вот только в-третьих - твоя догадка о чексуммах, проверяемых стредствами вроде debsums.
>> Два инструмента - pledge и MAC - которые ортогональны и лишь частично пересекаются областью применения и природой накладываемых ограничений, ты сравниваешь напрямую. MAC хуже, PaX-флаги хуже, pledge лучше. И считаешь это технической конкретикой.
> Я ещё уточнял, для чего pledge лучше.
Ну разумеется, ты уточнял! Сравнивал тёплоё с мягким. Сам же мне пишешь про различия в назначении MAC и pledge, и сам же их в лоб сравниваешь, впрочем как и с PaX-флагами. До тебя всё никак не дойдёт, что все эти инструменты, включая твой любимый pledge, позволяют получить результат с _разными_ свойствами. Причём, с разными первостепенными свойствами, не побочными. Я тебе привёл SELinux, как пример инструмента, предоставляющего пользователю выбор в заданных рамках - настройки ПО (а не его модификации и пересборки). Это не про лучше-хуже, это про факт наличия/отсутствия выбора. Каковое отуствие в данном случае является следствием политики разработчиков OpenBSD. И вот о наличии/отсутствии уже можно говорить в категориях лучше/хуже - для тебя отсутствие лучше, для меня хуже. Обменяться мнениями и закрыть вопрос.
В линуксе задачи, аналогичные pledge, решает SECCOMP BPF. Не PaX-флаги, не SELinux, не другие LSM-модули, а именно SECCOMP BPF. И вот с ним можно было бы посравнивать pledge напрямую. Но чтобы это всё чётко понимать, в голове должен быть порядок, а не каша из поверхностных и ошибочных представлений, мотивации пубертатного подростка и дурного воспитания.
> И если бы ты и это прочитал/процитировал, было бы не так феерично.
Это тебе так кажется.
> Я писал, что pledge лучше чем MAC подходит для защиты приложений от "самих себя", т.е. от эксплуатации дыр в них.
А я тебе писал в ответ, что твоё лучше-хуже - не более, чем субъективное мнение. Тебе кажется, что ты в чём-то прав, а я этого не замечаю. На самом же деле всё я вижу, но всё, в чём ты можешь оказаться правым с теми или иными оговорками, у тебя находится в подчинённом положении аргументов к личному мнению с претензией на объективное, авторитетное, общепринятое или имеющее больше прав на существование.
> Pledge - сорт privilege revocation, MAC - это принудительный контроль доступа, _очевидно_, что это разные решения разных проблем.
Не разных проблем. А решения пересекающихся множеств проблем (задач), обладающие _разными_ свойствами, такими как мандатность, например. И PaX-флаги - тоже не являются аналогом подмножества pledge, и кроме того, что обладают свойствами DAC, позволяя пользователю задавать произвольные ограничения, также в рамках заданной модели угроз комплементарны по отношению к политике TPE и сочетании с ней дают решение, также в известных рамках обладающее свойством мандатности. И если ты мне захочешь рассказать, что под "разные решения" ты имел ввиду примерно выше мною изложенное... То нет, мой юный друг, это тебе так кажется и очевидно в ретроспективе, не более.
> Многие проблемы, которые можно решать при помощи MAC, при помощи pledge или аналогов решать нельзя в принципе, или какими-то адовыми костылищами. И это _нормально_.
Но я тебе скажу, откуда ноги у твоего энтузиазма растут, и почему ты несёшь чушь, приправленную какими-то задатками здравого рассуждения. Причина в том, что я сравнил свойства решений, в первую очередь наличие/отсутствие свободы выбора у пользователя. И ты воспринял это как нападки на pledge, на те титулы, которыми он награждён в твоей голове. Он ведь лучше! :)) Вот тебя до сих пор и не отпускает.
>> когда PaX с SELinux сравнил
> Ты делаешь то, в чём постоянно обвиняешь меня - не учитываешь контекст.
> В сравнении была логика, но ты предпочёл попытаться поглумиться.
Ты не понял, о чём речь. Ткну носом. Твоё высказывание: "Существование того же PaX во многом обусловлено тем, что selinux сложен и неудобен." Моя реплика: "Этот перл вообще без комментариев. Sapienti sat." Ты даже не понял, какую дремучую чушь ты брякнул. И даже не заметил, что таки брякнул, я так подозреваю. Потому что я сразу тебя носом мне ткнул. И сейчас не понимаешь, небось. Ну давай, расскажи мне, какая тут логика. Посмеюсь ещё раз (в буквальном смысле, в голос, а не "ха-ха, ваши доводы мне смешны").
>> Патчи работают сами, отдельно от ядра? Нет. Ядра работают сами, отдельно от приложений? Нет. Вот я и сравниваю OpenBSD со связкой grsecurity-ядро + дистрибутив общего назначения. А ты мне под надуманным предлогом пытаешься отказать в праве на такое сравнение.
> Какой смысл сравнивать _нишевое_ решение и то, что позиционируется, как общее решение?
Кем PaX позиционируется, как нишевое решение? Это OpenBSD по факту - нишевое решение. Я уже дал критерий разделения на нишевые ОС и ОС общего назначения: работоспособность приложений и само их наличие для ОС в рассмотрении. По этому критерию связка "ядро с grsecurity + дистрибутив общего назначения" нишевым решением является именно OpenBSD, даже если производительность за уши не притягивать, а связка "ядро с grsecurity + дистрибутив общего назначения" - решение общего назначения. А как там своё детище разработчики OpenBSD _поцизицонируют_ - вопрос детсятый. А как лично ты позиционируешь PaX/grsecurity - это даже не вопрос, а курьёз.
> Право ты, имеешь, и кто я вообще такой, чтобы в чём-то тебя ограничивать? Только а смысл?
Смысл есть. И тебе остаётся от него только бегать, бегать, бегать.
>> Ну да, а в OpenBSD в своё время была опубликована уязвимость к удалённому выполнению произвольного кода в ядре. Покажи мне аналогичную уязвимость в линуксе за время с тех пор по сегодня. Хотя бы такую, которая так же надёжно эксплуатировалась бы в простом линуксе, без grsecurity. И дело не в том, чтобы померяться уязвимостями, а какие выводы затем сделать по факту наличия или отсутствия предпринятых мер, дабы ситуация не повторилась.
> Насколько я помню, меры были разве что в области проверки аналогичных по смыслу мест, аудиту и так далее. Интеграция тех или иных мер безопасности не бесплатна.
Почти всё в этом мире не бесплатно. Но речь идёт не о потерях производительности или внесении видимых изменений в поведение системы, а о внедрении мер, аналогичных тем, что на то время уже несколько лет были в PaX, и которые разработчики OpenBSD ещё лет 10 не трудились внедрять даже после появления NX-бита в x86-процессорах.
> Я не знаю, насколько хорошо принятое опенбсдшниками решение поступить так, как они
> поступили, но аналогичных дыр, емнип, более и в OpenBSD не было.
Не было опубликовано. В линуксе тоже не было опубликовано, дальше что? Защиты ядра не нужны? ;) Ждём, пока опубликуют вторую, третью, десятую аналогичную уязвимость и не считаем локальные? Давай, озвучь свои авторитетные соображения на этот счёт.
>> Про государствннные дистрибутивы специального применения с grsecurity ты тоже не в курсе.
> Никогда не сомневался в вероятном существовании чего-то подобного.
Может и не сомневался, но не в курсе. И однако ж тебя сносит в шкодливые тирадки а ля "игрули для секуьюрити-энтузиастов и proof of concept". Между которыми ты наивно, почти искренне недоумеваешь, почему это мне не интересено беседовать с тобой чинно по существу. Потому что ты себя так позиционируешь. Да и не умеешь иначе, по большему счёту.
>>> Но пока это сторонние патчи (даже если и опенсорсные, как раньше) - это всё игрули для секуьюрити-энтузиастов
>> Ещё один технический аргумент от не-эксперта.
> Ну а что, нет? Едва ли "гос дистрибутивы" - это тупо наложенные и активрованные pax-патчи, правда?
Для создателей этих дистрибутивов, grsecurity - надёжная основа всему. А для тебя - "игрули [...] и proof of concept". И если говорить о специфике защиты ядер таких дистрибутивов, то да, это по большему счёту именно "наложенные и активрованные pax-патчи" - не тупо, разумеется, если речь не идёт об Astra Linux.
> "Гос дистрибутивы" - это, вероятно, "готовое решение", патчи - playground для разработчиков и энтузиастов и база для чьего-то stable.
> Я принципиально неправ?
Так ты во всём принципиально не прав, мой юный друг. Это для тебя, админа локалхоста, патчи были плейграундом. А по факту в grsecurity на сегодняшний день поддержка стабильных ядер лучше, чем в апстримном линуксе, и многие клиенты платят деньги именно за эту поддержку. Ты снова рассужаешь о том, о чём не имеешь ни малейшего понятия. Продолжай в том же духе, я доволен.
>>> Сравнивать openbsd с pax нулевых мне как раз малоинтересно, писями меряться - это детский сад.
>> История тебе не интересна, потому что в неё вошли успехи PaX и бездействие OpenBSD
> Почему же бездействие? Согласись, не факт, что из-за одного инцидента следует тащить в ядро некую конструкцию, а не просто зачинить то, что было сделано плохо?
Вот видишь, оказывается, сравнения в историческом контексте - это не детский сад, как тебе кажется. Видимо, воспоминания о детском саде у тебя ещё свежи в памяти, вот и просятся на язык.
И конечно же не соглашусь. "Не просто зачинить" - это называется proactive security. И сами разработчики OpenBSD если не придумали, то всячески старались до какого-то момента популяризировать этот подход. А "зачинить то, что было сделано плохо" - это называется reactive security, каковой подход опять-таки сами разработчики OpenBSD всячески критиковали. Но как запахло жаренным, так сразу и раскрылись. Читай: слились. Такова неприглядная правда о твоей любимой операционочке.
> Успехи PaX, безусловно есть, и в моём признании не нуждаются, но это довольно нишевые успехи.
Вот и расскажи, чем они нишевые. Ты ведь любишь заявлять, будто ты что-то по существу написал, а я не заметил. Вот и покажи, где ты попытался обосновать нишевость теперь уже успехов. А не попытался - так потрудись.
> Есть, например, OpenVMS, которая тоже нишевая и тоже умеет КУЧУ того, что OpenBSD не умеет, даже рядом не умеет. Но мы же не сравниваем их, не так ли?
Мы их не сравниваем, потому что под ядром OpenVMS не работают все приложения из состава дистрибутива Linux общего назначения, а под ядрами с grsecurity - работают.
>> Ты ляпнул в очередной раз, не подумав, про безопасность через корректность. А как запахло жаренным и стало ясно, что безопасность через корректность - это бред, и я за него с тебя спрошу
> Нет, безопасность через корректность это не бред.
Ты не путай безопасность через корректность вне контекста - с тем бредом, который ты ляпнул. Ты ж её _противопоставил_ "митигациям", как ты их назвал.
> Просто закладываться _только_ на корректность - неправильно.
Так определись уже, правильно или не правильно. Или ты рад тому, что разработчики OpenBSD неправильно делают? И что там остаётся, кроме корректности? Уж не "митигации" ли?
> И опенбсдшники этого не делают.
То есть, всё-таки "митигации".
> Но и число интегрированных защит у них меньше, чем у grsecurity, например.
Тут дело не в количестве, а в качестве. А именно, в соответствии оных защит современному технологическому уровню угроз. В случае с OpenBSD - в несоответствии.
>> Ну так и PaX/grsecurity крайне осторожны. Ты ведь намекаешь на обратное?
> Я намекаю на то, что PaX/grsecurity - это набор патчей, который ни в одну публичную ОС общего назначения в стандартную поставку интегрирован не был.
Это мы уже обсудили. Я изложил свои доводы, ты их проигнорировал. А с темы о влиянии "митигаций" на производительность ты пытаешься съехать, потому что фактических претензий к PaX/grsecurity в этом плане у тебя нет. Только FUD.
>> И зачем ты мне эти банальности рассказываешь? Ты ведь намекаешь на то, что grsecurity поступает иначе. А факты где? Фактов нет.
> Какие могут быть факты, если grsecurity - это патчи, не используемые <и далее по тексту, см. выше>?
Снова ужимки и прыжки. Перевожу твою реплику с обезьянего на человеческий: "Я очень неуверен себе и сказать по существу мне нечего, поэтому я буду как бы троллить, и если собеседник мне что-то скажет по существу, значит, я его затроллил! Ура!"
> Не сомневаюсь, что разработчики grsec тестируют в том числе и производительность своих решений, но при всём уважении, полнота их тестов едва ли может быть абсолютной.
Ничья полнота тестов в таких случаях не может быть абсолютной. Это математический факт. Дальше что?
> Но я не намекаю не то, что разработчики grsecurity поступают иначе, я намекаю на то, что есть смысл сравнивать openbsd и какой-нибудь дистрибутив linux, по-возмоности показательный. Но не ОС и набор патчей.
Ты намекаешь ровно на одно: что артументов по существу у тебя нет и ничего умнее, чем про "набор патчей", ты придумать не можешь.
> Для справки: opennet выдал мне ошибку о том, что сообщение превышает 30000 символов и я вырезал всё, чтобы сэкономить. Ты напрасно ищешь в этом тайный смысл (но - бога ради).
Это ты своим воображаемым зрителям в голове расскажешь. Я тебя в одно вырезанное и твой ответ носом ткнул уже.
>> То есть, у такого враппера остаётся проблема, аналогичная игнорированию LD_PRELOAD.
> Справедливо (тоже не проверял).
>> Так зачем он такой нужен? [враппер]
> Они никакой не ну..н.
Вот так и заканчиваются твои попытки что-то сказать по существу, а уж тем более родить концепцию технического решения. Такова твоя реальность. Продолжай рассказывать мне про набор патчей.
> Потому что я не понимаю, зачем мудрить с "правильным" (в твоей терминологии) решении с хитрожопым враппером, если это всё равно _костыль_?
Где я его правильным назвал, покажи? Зачем мудрить - я сказал. Чтобы удовлетворить _моим_ личным критериям (если представить, что я начал пользоваться OpenBSD и захотел воплотить решение). Тебе просто не нравится, что у кого-то могут быть личные критерии. В твоём представлении есть только твои критерии, которые правильные. А все остальные - неправильные, костыльные, уродливые, неудобные и т.п. И вот ничего ты с этим поделать не можешь. И это понятно: человек, который не научился ещё давать собственному мнению право на существование, а привык оглядываться на других - не может дать такое право и чужому мнению.
> По задумке, это не я придумал, можешь посмотреть в презентациях, pledge и должен явно вызываться в коде.
Я знаю, что по задумке должен, успокойся.
> Я думал, что ты хотел костыль-воркэраунд и предложил тебе более простое решение.
Чем оно более простое-то, госсподи? И ничего я не хотел. Может быть, захотел бы, если б OpenBSD пользовался, но не пользуюсь, да и не о том речь.
> Как основное решение - никаких врапперов не предполагается. Не вижу смысла обсуждать это - неправилен сам подход.
Ну так и не обсуждай. Я заставляю, что ли? Сам пустился в рассуждения, как враппер сделать. Потому что идея пришла и язык зачесался. Мне враппер как таковой вообще не нужен и не интересен. Был нужен как пример, чтобы раскрыть твою некомпетентность. Раскрыл. Всё.
>> в прошлом пользователь grsecurity в течение двух лет, на Arch Linux.
> Продакшен был на debian, но к его настройке я не имел отношения.
Ещё лучше.
> Это ничего не значащий опыт - факт.
Факт или нет, ты его всё равно не учитываешь. Но что касается фактов, нет ничего зазорного в том, чтобы пользваться чем-то хотя бы и только на локалхосте. Важно то, существенно ли отсутствие (более богатого) опыта. В твоё случае - существенно. Оно не позволяет тебе обозреть более широкий круг практических задач. Вот я тебе рассказал (а ты сделал вид, что не заметил), зачем paxctld нужен и чем он лучше хуков пакетного менеджера. Будь у тебя чуть более богатый опыт работы, ты бы сам сообразил и просто вспомнил, что кроме системных пакетов в продакшене нередко присутствует много, чего ещё, что может потребовать настройки PaX-флагов.
>> Во-вторых, даже мнение о том, что PAX_MPROTECT является нарушением стандарта - всего лишь мнение.
> Это очень удобная позиция. Поэтому я сразу добавляю всегда "и, что самое главное, ломает приложения". Если бы не ломал - чхали бы все на нарушения стандарта.
Не не просто добавляешь "ломает приложения" - ты убегаешь в эту расплывчатую формулировку. "Ломает" - как многозначительно звучит-то! А я говорю: системные вызовы возвращают ошибку и работают в рамках, допустимых стандартом.
Но тут есть одно обстоятельство, которое, как всегда, корнями уходит в твою некомпетентность. Ты ведь, как ты сам сказал, думал, что семантика работы PAX_MPROTECT - это аварийное завершение процессов, которые нарушили ограничения PROT_EXEC. А это не так. Но откуда у тебя такое заблуждение, я догадываюсь.
Первый фактор: ты мог наблюдать падение приложений, которые сами не следуют стандарту, то есть не проверяют результат вызова mprotect/mmap и работают из допущения, что память стала доступна для исполнения. Попытка выполнить инструкцию из неисполняемой памяти закономерно вызывает страничное исключение и процесс убивается кодом ядра, который давно есть сам по себе, а не добавляется в PaX или grsecurity.
К слову, когда в OpenBSD вводили W^X, были разговоры, что это сломает работу некоторых приложений, на что разработчики OpenBSD вполне обоснованно возражали, что если приложение не следует стандартам, нужно исправлять приложение, а не подстраиваться под его изъяны. Попробуй теперь этот факт подружить с иллюзиями в своей голове.
Второй фактор: ты мог включить (или за тебя могли включить, если ядра в арче могут поставляться в бинарниках - я не в курсе) опцию PAX_MPROTECT_COMPAT, с которой при включении PAX_MPROTECT вызовы mprotect/mmap с PROT_EXEC уже не возвращают ошибку. Эта опция сборки ядра оставлена для случаев, когда приложения написаны неправильно, а именно не проверяют результат вызова mprotect _и/или_ запрашивает PROT_EXEC для памяти, где он не нужен. В любом случае все претензии о сломанных приложениях можешь адресовать сугубо себе или сборщикам пакетов ядра, которые сделали выбор за тебя.
Поэтому, мой юный друг, это не только удобная, но и хорошо обоснованная позиция.
