В ядре Linux выявлено несколько уязвимостей, вызванных обращением к уже освобождённым областям памяти и позволяющих локальному пользователю повысить свои привилегии в системе. Для всех рассматриваемых проблем созданы рабочие прототипы эксплоитов, которые будут опубликованы через неделю после публикации информации об уявзимостях. Патчи с устранением проблем отправлены разработчикам ядра Linux...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57622
А если бы Линус послушал Таненбаума и сделал микроядро, этих уязвимостей бы не было?
Ага, и линукса тоже не было бы
Был бы православный Hurd. А Linux все равно подстилка корпораций и нинужОн.
У HURD всегда Linux виноват. Вот если бы не Linux, ухх развернулись бы!
Правда, хурд на год раньше линукса родился, но этот неудобный факт не афишируется.
А Рамблер появился на 2 года раньше Гугла. А Яндекс на 1 год раньше Гугла. И чего? Какая вообще разница кто когда появился?
Сравнивать русскоязычные поисковики с гуглом вообще некорректно. А рамблер vs яндекс — как раз очень показательно: как, имея всё, всё просрать.
Yahoo search на 3 года раньше Гугла и заграничный. Давай вещай свой бред дальше.
Та же самая ситуация. Появились раньше и всё проср-ли.
А АльтаВиста - на 3 года раньше Гугла. Но без ранжирования Пейджа не взлетело бы.
> А АльтаВиста - на 3 года раньше Гугла. Но без ранжирования Пейджа
> не взлетело бы.Да и в нормальное масштабирование на глобальные масштабы только гугл и сумел. Остальные слились на индексировании. Нет, знаете, индекс протухший на месяц это не очень ценно, полно 404 или наоборот не может найти актуальное. Только гугол и смог всю планету оперативно сканировать своими ботами. Остальные где-то сильно позади.
Развесистая структура нужных связей плюс потомок советских математиков? )
> Развесистая структура нужных связей плюс потомок советских математиков? )Я так понимаю что одно из ноухау это распределенная мегаструктура, способная все это хранить нормально без напряга. Они этим с другими не делятся особо. Кроме того у них краулеров тупо в разы больше и они в разы активнее. На десяток визитов гугла будет один бинга, 0.1 яндекса, а остальных там вообще под микроскопом искать надо.
Ну вот так и получается что спросить гугол о каких-то недавних событиях, новостях, и так далее - он в курсе. А остальные - ну, блин, зачем мне это знание через месяц? Через месяц я это и без них уже где-нибудь да прочитаю, так что спасибо за такую индексацию, но...
Какая разница, кто и когда родился?
Факт в том, что неоплачиваемые недоучки-джастфофаны пошли писать, что попроще. Ешьте теперь свои двадцатилетние дыры.
А маэстро программирования тем временем чем занимались?
Сидит эникеет в протухшем НИИ.
Слово эникей уже устарело.
Изобретали швятой Rust.
найс приплёл
Есть другой вариант. Занятся HURD'ом и лет триста отлавливать баги и уязвимости внутренних интерфейсов.
Его нельзя оживить он жестко прибит к 32-м битам.
Но 4 гибибайта должно хватить для всех браузеров, текстовых редакторов и видеоплееров.
>позволяющих локальному пользователю повысить свои привилегии в системеКогда критикуют systemd, то обычно ссылаются на его огромность, которая якобы приводит к большому числу уязвимостей. Только вот эти товарищи у себя под боком не замечают более жирненький источник уязвимостей - монолитное ядро linux. Что не день, так новая порция уязвимостей. Systemd на фоне ядра - бастион безопасности.
> Когда критикуют systemd, то обычно ссылаются на его огромностьsystemd критикуют не за это
Не, есть куча сектантов, которые орут ололо небезопасно же.
http://skarnet.org/software/systemd.html
>Cross-platform compatibility. BSD is not dead, Solaris is not dead, but systemd ignores Unix.А что, бздуны мечтают прикрутить себе systemd?
>>Cross-platform compatibility. BSD is not dead, Solaris is not dead, but systemd ignores Unix.
> А что, бздуны мечтают прикрутить себе systemd?Не знаю. Скарнет вообще странный слегка, Solaris именн что dead.
> Не знаю. Скарнет вообще странный слегка, Solaris именн что dead.Да и этот их s6 не очень то решает вопрос контейнеров и изоляции сервисов друг от друга и от системы. Очередное лоскутное одеяло со всеми характерными проблемами оного - как то невозможность собрать огораживаемому процессу арену без вывешивания ему полсистемы (не секурно) или отвалбашки в процессе (потому что большая часть системы уже недоступна, а приспичило что-то вызывать).
Уже вгруженый в память резидентно и имеющий полные права системд вон той дурацкой проблемы не имеет, ему никого вызывать не надо. Может сам сисколы отвесить как надо не уповая на доступность с диска тех или иных программ (что в контексте огораживаемого процесса ну вот совсем не факт).
А, ну правильно, если началось увещевание за соляру и прочие бзды которые нот дед, значит и равняться надо на самый убогий и архаичный из наборов фич. И вот тут пожалуй хорошо что Linux это не unix так что можно позволить себе и не админить систему как будто на дворе 80е прошлого века.
Сплошное «яскозал» без конкретики. Это не критика, это обычная демагогия.
Вы слово «критикуют» со словом «обсирают» не путайте. Критикует один из десяти разве что.
В основном тут системдишники обсираются.
Правда проблема не в монолитности, модули netfilter/nf_tables даже не загружены в ядро, если не пользуешься фаерволом. А если пользуешься, то на любой оси даже абсолютно сторонний дырявый драйвер может позволить получить доступ к ядру.
А вот был бы netfilter на Rust...
А вот были бы комментаторы на Rust...
Взаимоисключающие понятия. Они тогда не были бы комментаторами, ибо им было бы некогда.
Самопереписывались бы на Rust?
Тогда бы нетфильтр вообще бы не работал.
discord же работает. А он уже на Rust.
Раз на Rust, значит, не работает. А будете сомневаться - отменим!
Вопрос надо ставить по другому: Если netfilter/nf_tables были в юзерспейсе...
То были бы жесткие тормоза.
> проблема не в монолитности
> абсолютно сторонний дырявый драйвер может позволить получить доступ к ядруну даже и не знаю
Подобное раздутое ПО лишает свободное ПО смысла ведь, нпапример, крайне трудно проводить аудит кода. Продвинутые люди критикой systemd не ограничиваются и уже смотря на негативные тенденции в полном серьезе рассматривают OpenBSD, seL4, Plan9. А в systemd было крайне много уязвимостей за историю, а если считать его не вирусом, а системой инициализации, то поразительно много, там уязвимостей быть вообще не должно.
> Продвинутые люди критикой systemd не ограничиваются и уже смотря на негативные тенденции в полном серьезе рассматривают OpenBSD, seL4, Plan9.Очень продвинуто, особенно учитывая, что "безопасность" опёнка держится в основном на громких заявления Тео и отсутствии аудита.
Очень продвинуто, особенно учитывая, что "безопасность" линукса держится в основном на громких заявления анонима и отсутствии аудита.
Очень продвинуто, особенно учитывая, что готовность к проду и безгемморность установки популярного ПО на поделия вроде Plan9 держится в основном на громких заявления анонима и отсутствии аудита.
Очень продвинуто, особенно учитывая, что готовность к проду и безгемморность установки популярного ПО на поделия вроде десятки держатся в основном на громких заявления микрософта и имитации деятельности.
Раздувание ПО это беда не только культуры opensource, но и айти в целом.
> вызванных обращением к уже освобождённым областям памятиОпять ненастоящие программисты на Си в ядро прокрались и накоммитили там?
Запомните, программисты на Си не могут ошибаться по определению. Они не какие-нибудь смузихлебы на расте. Поэтому если находят уязвимость в Си коде, то оставлена она там СПЕЦИАЛЬНО.
Я специально не убираю структуры из списка, даже если освободил всё, что было по адресам указателей в этой структуре.Так веселее.
> Опять ненастоящие программисты на Си в ядро прокрались и накоммитили там?А настоящие программисты на Си, которые не делают дуршлаг из всего, к чему прикасаются - вообще бывают?
Ну и не пользуйся всем, что написано на С и не используй сишные либы.
Развивай redox.
А потом сравним оси по быстродействию, жору ресурсов и дырявости.
А это же сишники виноваты в том то на расте ничего не написано.
Точно, на Опеннетике Rust хейтят, тем самым, пейсателям Redox мешают.
когда черпак с дырочками, не надо грешить на то, что вода слишком текучая.
Нет.
Писать на Си — всё равно что работать на крыше без страховки. Каким ты ни будь альпинистом, рано или поздно наипнёшься.
Вы с бригадами молдован общались? Сколько у них в бригадах наипнулось?
А типа не случается? Одного знаю, кстати (хоть тот и не молдаванин).
Цели провести прям вот чёткую аналогию не было, так, намёк просто.
> Вы с бригадами молдован общались? Сколько у них в бригадах наипнулось?Пока плитку в ванной клали - ни одного.
Ну бывают, и что?
Настоящие программисты на Си, это Вам не какая нибудь детерминированная машина (имени кого нибудь %). Мало того, они должны (и будут!) ошибаться!
Си Дзинь Пин сейчас сделает дуршлаг из всех кто упоминает его в треде...
>Опять ненастоящие программисты на Си в ядро прокрались и накоммитили там?Накоммитил - убери за собой!
Пусть растаманы за собой убирают, а мы будем гордо жить в том, что накоммитили!
интересно, какое медианное время жизни уязвимостей?
Уязвимости, потому что код не написан на Carbon.
> созданы рабочие прототипы эксплоитов, которые будут опубликованы через неделюА зачем, ©, - пометить дерево, так сказать?
Ре Ше То. Сишники 30 лет не могут научиться с памятью работать. Зато rust критикуют профессионально.
Код сишников 30 лет работает и проработает ещё немало, а растаманы, складывается впечатление, больше щёки надувают.
Угу, проработает... Видим мы как оно "работает"
Так код на Rust вообще не работает, за отсутствием оного.
Ну да, ведь если не видишь чего-то, потому что не смотришь, значит, этого нет. Очень удобно для дискуссий на Опеннете: отвернулся - и противник повержен. А противник он почему? Да патамушта смузихлёбы и вообще!
>>> Сишники 30 лет не могут научиться с памятью работать<<<А чего вы ожидали?, учитывая тот факт, что изо всех щелей, до сих пор рекомендуют книгу K&R.
Кто-нибудь, скажите уже им, что этого недостаточно чтобы писать production code🤦 Нужно ещё как минимум обязательно прочитать CERT C Coding Standard, а также познакомиться с таким понятием как тестирование, а то складывается впечатление, что Сишники вообще не знают что это такое, а если и знают то не понимают какие входные данные нужно использовать.ПС: Помню, в своё время, когда изучал libc и ковырялся в open source проектах, в частности в pico libc например, то в функции strrchr наткнулся на типичный баг, который связан с некачественным тестированеим (подбором входных данных). Лично я никогда не репортю баги:), так иногда пишу то здесь то там (в частности писал здесь в комментариях) Так вот гуру с опеннета пытался мне доказать, что ну да, мол программист типа опечатался, типа бывает (уже не помню, что он там мне лечил), на моё замечание, что при должном тестировании данную ошибку стразу бы легко обнаружили, - он разумеется снова ответил что-то столь же полезное:), ну хоть не поленился и зарепортил баг на github:)))
Тут программисты не сидят.
Программистки?
Опять закладки спалили и приходится выдавать их за ошибки.
Таков Путь!
Шо вы таки понимаете в бизнесе? Сначала встраиваем уязвимости и получаем за это $, потом находим уязвимости и получаем ещё $, потом устраняем уязвимости и получаем ещё немножко, а потом уже можно и новые встраивать. Ничего личного! 😈
Готовые майнеры битка есть, которые можно подвесить к этой уязвимости есть?
> Уязвимость присутствует начиная с выпуска 2.6.12-rc2
> Уязвимость присутствует начиная с выпуска 3.16-rc1
> Уязвимость присутствует начиная с выпуска 3.16-rc1Но ведь.. но тысячеглаз же
Но ведь в итоге нашли
А в NT ядре даже и не искали. Они пишут сразу без ошибок, нет.
> А в NT ядре даже и не искали. Они пишут сразу без ошибок, нет.Прикольно это выдать после вторника патчей :)
Наверное, кто-то да нашёл по утекшим исходникам. Но публично не скажет, ибо низзя - раскрытие интеллектульной собственности MS.
Нет доцкера, нет проблем. CAP_NET_ADMIN им ещё подавай
И опять в двух случаях из трех без включенного namespace не обошлось.
Rust не нужен, говорили они.
Зачем он нужен болезный?
Чтобы хоть как-то заставить сишников перестать дважды очищать память?
Это с учетом того, что сложные связные структуры в расте надо в unsafe делать, а в ядре практически все структуры сложные и связные?
Брехня, unsafe нужен для очень назкоуровневых вещей. Все остальное пиши как обычно с нужными объектами синхронизации.Ну а то что в ядре такая связность просто показатель прекрасно продуманной архитектуры))
> Брехня, unsafe нужен для очень назкоуровневых вещей.А в ядре какие?
> Ну а то что в ядре такая связность просто показатель прекрасно продуманной архитектуры))
Тут конечно - не без этого. Но! Большинство таких вещей обусловлено или исторически сложившимся (пока работает - потом перепиашем) или скоростью работы (тут уж никуда не попрешь) или самими задачами (тут тем более никуда не попрешь).
Вот мне и интересно, когда покажут хоть один пример, где будет видна польза от rust?
Хоть и не рустофоб, но не могу не заметить, что даже двусвязный список уже оказывается не такой тривиальной структурой с точки зрения ownership, что уж говорить о всяких rcu
Чтобы тролить опеннет, очевидно же. К разработке этот язык отношения не имеет.
Офигеть...
3.16-rc1 - Jun 2014
2.6.12-rc2 - Apr 2005Три древнючих уязвимости и все из-за рукожопства с памятью.
И ведь не спихнешь на всяких смузихлебов, тогда еще ядро диды писали.
Но и они нешмогли.
Так всё именно потому, что писали старпёры, а вот если бы писали школьники с Опеннета, то ошибок бы не было. Здесь даже первоклашки знают стандарт наизусть. На уроках пишут планировщики, на дом им задают дрова, а в качестве хобби они пишут микроядра.
не было бы. Извините )
Комментаторы про микроядра от бога. Да, если поделить функционал ядра на 100, то получим 1 ядро и 99 других мест с теми же уязвимостями. Но стоп. Главное в ядре которое само по себе ничего не может будет меньше проблем.Просто интересно, они понимают, что повторение похожего функционала и всех подсистем это +\- тот же объём кода, и даже почти того же самого, просто в пространстве пользователя или прилепленного с боку.
Но при этом каждый из кирпичиков был бы меньше по объему кода, с существенно меньшей связностью и описывался бы только протоколами взаимодействия. Для них можно было бы сделать доп защиты вроде своих участков памяти, что бы исправило много проблем описанных в статье. Или написать свой использую предоставленный протокол.
Плата за это - накладные расходы на трансляцию объектов между отдельными подсистемами.
Вот только такой объем функционала подразумевает в разы больший чем в linux объем внутренних интерфейсов. Людей способных проанализировать такое на непротиворечивость и безопасность не существует. Кто будет этим заниматься?
Интерфейсов в любом случае будет меньше чем кода в ядре.
Если даже их невозможно "проанализировать на непротиворечивость и безопасность", то что можно говорить про само ядро где эти все интерфейсы присутствуют, только в менее явном и более запутанном виде?А для интерфейсов можно применить формальную верификацию, что конечно сложно, но существенно проще чем для кода.
Основная проблема что когда все начиналось, компы были слишком слабые для накладных расходов на интерфейсы, а код на порядки меньше и проще. Поэтому микроядра вначале и не взлетели, а потом "ну оно ж уже работает - не переписывать же! давайте в него нахерячим еще пару млн строк кода, хуже не станет"
> Интерфейсов в любом случае будет меньше чем кода в ядре.Категорически неверно.
> Если даже их невозможно "проанализировать на непротиворечивость и безопасность", то что можно говорить про само ядро где эти все интерфейсы присутствуют, только в менее явном и более запутанном виде?
Конкретный хак - не интерфейс. Он минимален, Он понятен. Он легко изменяем.
Огромное количество проверок отпадает за ненадобностью.
Так что микроядро - конечно, хорашая вешь. Но она случится при внуках моих внуков.
> Он минималенВозможно
> Он понятен
Чуваку который его писал примерно пару месяцев. А далее без развесистого коммента не обойтись. И то не факт что поможет.
> Он легко изменяем.
А потом выстреливает совсем в другим месте. Потому что забыли дописать про сайд-эффекты.
Я не предлагаю все классы наследовать заставлять реализовывать интерфесы. Был у меня один такой проект и это был маленький адок. Но разделить логические блоки (хотя бы крупные) для уменьшения связности и изоляции - это было бы очень круто.
А сейчас с ядром понятно что ничего не сделаешь :(
> Но стоп. Главное в ядре которое само по себе ничего не может будет меньше проблем.Ага. А локализация проблемы при ошибке? В монолите драйвер какой-нибудь звкуковухи, USB или вайфая (не важно, какой-нибудь относительно некритичный для системы в целом), особенно редкого железа, из-за ошибки полез не в свою память, переписал структуры драйвера файловой системы, блочных устройств или какой-нибудь подсистемы безопасности или менеджера памяти, те в свою очередь еще успели поработать по рандомным данным, наворотили что-то страшное и только потом всё это навернулось медным тазом. В микроядре же - такой драйвер USB "полез не в свою память" (т.е. по несуществующему адресу, он же как обычный процесс в своей выделенной памяти работает) - сразу же аппаратное исключение, микроядро и дальше уже как настроено будет или как требуется по логике - просто снос процесса драйвера или перезапуск, если допустимо (драйвер усб или звуковухи часто обычно не так чтобы очень важны и критичны). Ну конечно если драйвер супер-дупер важный и перезапуск ничего не решает, то тогда только перезапуск всей системы. Устойчивость системы выше, конечно всё это за счет производительности (переключений контекстов задач значительно больше). Компромиссы и кому что важнее.
> медным тазом. В микроядре же - такой драйвер USB "полез не
> в свою память" (т.е. по несуществующему адресу, он же как обычный
> процесс в своей выделенной памяти работает) - сразу же аппаратное исключение,Угу, только потом оказывается что народу скорости мало, так что вот вам usb 3.x, это уже минимум 10Гбит. Т.е. порядка гига в секунду минимум, а игрунам еще латенси подавай и проч - т.е. довольно дофейхоа пакетов и переключений контекста.
...и вот тут оказывается что микроядро будет в разы больше грузить проц, а то и упрется в него, на таких то потоках данных. После чего оно и оказывается нахрен не упершимся никому. Видите ли разделение адресных пространств нагибает и быстрый обмен большими объемами данных. В одном адресном пространстве это был бы заведомо zerocopy с минимальным сетапом. По сути дал указатель на регион, 4 или 8 байтов надо передать, и все, это можно референсить. А вон там придется весь этот гиг в секунду копировать туда-сюда. И комп займется в основном каким-то бесолезным техническим действом по тасовке байтов отсюда туда, потому что абстракция такая.
> придется весь этот гиг в секунду копировать туда-сюдану строго говоря из микроядерности это не следует
Ты ничего не понял в микроядерной архитектуре.
Очевидно, обратное.Он же говорит. Что само по себе микроядро - не дает ничего. А дополнительными модулями - огромное число доплнительных связей, за каждой из которых нужны дополнительные проверки.
> А дополнительными модулями - огромное число доплнительных связейТам это "огромное число доплнительных связей" "расшито" через подсистему IPC которая обычно на сообщениях строится и это "число связей" не отличается от монолита. Какая разница - дернуть функцию в монолите (надо знать какую) или отправить кому-то сообщение единообразным способом через микроядро? Единственное преимущество монолита - скорость. А у микроядра - бОльшая надежность (ошибка не распространяется дальше процесса драйвера и не затрагивает структуры памяти других драйверов/процессов/приложений).
> Там это "огромное число доплнительных связей" "расшито" через подсистему IPC которая обычно
> на сообщениях строится и это "число связей" не отличается от монолита.
> Какая разница - дернуть функцию в монолите (надо знать какую) или
> отправить кому-то сообщение единообразным способом через микроядро? Единственное преимущество
> монолита - скорость. А у микроядра - бОльшая надежность (ошибка не
> распространяется дальше процесса драйвера и не затрагивает структуры памяти других драйверов/процессов/приложений).Это все очень теоретически. Практически - там еще много чего интересного есть. DMA, железки которые сами bus-master-ы на шинах и все такое. Поэтому гимора и продолба скорости во, а эффекта во. Бонусом еще и кодинг дров начинает напоминать некропедосадомазо так что желающих кодить дрова вот так - ну вот нет. И все микроядерные выперыщи на этом утыкались.
Ничего что для скорости современное железо mem-mapped? То-есть, драйвер тупо пишет в нужные адреса что хотел - из режима ядра, в том же пространстве это очень быстро и легковесно. И например DMA програмить просто, если с физическими адресами работали. А если это так более не работает и надо контекст переключать, скорость будет очень сильно другая, а не сойти с ума при программировании DMA транзакций будет вообще малореально. Ведь в вашем отдельном процессе адреса - тоже свои. Поэтому "просто скормить DMA этот блок"? Ага, сейчас. Вместо этого ээээвона какое действо придется откаблучить с трансляцией адресов и черт знает чем еще. И то что в этом будет меньше багов и лучше стабильность - ну вот уже не факт.
Мдауш. Вот тебе и безопасность, вот тебе и надёжность. Даже таймер за двадцать лет написать без ошибок не смогли.
> Мдауш. Вот тебе и безопасность, вот тебе и надёжность. Даже таймер за
> двадцать лет написать без ошибок не смогли.Вообще-то смогли, НО потом народу контейнеры захотелось. В изначальной логике этого не было, ну их и прикрутили на спички и изоленту. Не переписывать же ради 1 фичи ядро с ноля, потому что на моммент начала кодинга 0.чтототам о контейнерах и близко не задумывались?!
А за вот это вот - воздается довольно развеселыми логическими факапами, когда логика деланая под "одноголовое" ядро - при попытке косить под змейгорыныча с независимыми головами начинает отъезжать. И даже на хрусте в этом допущении гамна, имхо, покушали бы. Сложная это затея, многопоточное, нафиченое нечто перепилить под совсем другие допущения на ходу. Сишники лажают? А покажите как вы такие номера сделаете. А, вы такими масштабами вообще не ворочаете а в хелловорлде так при всем желании не обгадишься? :)
> при обработке нулевого дескриптора старый фильтр не удалялся из хэш-таблицы до очистки памяти
> приводит к обращению к освобождённой области памяти после удаления данной таблицы
> остаётся в списке, несмотря на очистку выделенной для хранения памятиПока что амна покушали сишники.
Добавление контейнеров, как и изменение любой логики, никак не должно влиять на такое. Это же классические проблемы с памятью. Они написали г0внокод и он просто не выстреливал им в ногу до поры до времени.
Но день настал))В расте оно бы или просто не дало бы дважды обратиться к области памяти или бы запаниковало с выводом трейса (и эта паника скорее всего была бы перехвачена ядром чтобы не падать, а дальше залогированно и напр. перезапущен упавший сервис)
Что легко бы нашли во время тестирования или уже у юзеров (прям как сейчас))). Только на много лет раньше.
В расте оно бы никогда не было написано.
Ну что, получается затролели вас растоманы, раз при любой уязвимости вы начинаете оправдываться?
Как я уже писал все структуры ядра сложные и связные. В расте в таких случаях unsafe сплошной. Кто там и что не дал бы сделать?
Затролен.
Спасибо, что отчитываешься.Но нам не интересно, затролен ты или нет.
> Пока что амна покушали сишники.Да вообще охренеть внезапность! А кто еще? Ну не фуксики же, с их драйвером фата на игогошке? И не хрустики с редоксом, которые до такой крути всерьез если и дорвутся то лет так через много? Сейчас они явно не в форме ТАКИЕ фичи кодить.
> Добавление контейнеров, как и изменение любой логики, никак не должно влиять на такое.
С хрена ли? Это вся модель пермиссий и все допущения имеющие хоть какое-то отношение к всему этому идут лесом. В системе без контейнеров вон то по сути не вулн, ибо обладатель CAP_NET_ADMIN может пялить систему в хвост и гриву, чаще всего это рут же. А в контейнерах оно, видите ли, немного "виртуальное" и по задумке CAP_NET_ADMIN с гуеста уже хренсгары на хосте. И если он может что-то еще получить с этого - вот тут это рут, но не тот рут, и вот тут некоторые допущения не удержались. И как ты понимаешь есть сотни кода писаные ДО эпохи контейнеров, где допущения при кодинге про модель безопасности и результирующие проблемы сильно другие.
> Это же классические проблемы с памятью. Они написали г0внокод и
> он просто не выстреливал им в ногу до поры до времени.Вон то скорее гибридное комбо, наполовину вылезающее из смены парадигм от реализации контейнеров.
> Но день настал))Вокруг namespaces в линухе наверняка водится много всякого интересного. Потому что изначально его не кодили с namespaces in mind, а столь резкое изменение допущений в середине пьесы вообще-то провернуть проблематично, когда это не было частью дизайна сразу.
> скорее всего была бы перехвачена ядром чтобы не падать,
И чего при этом было бы? Я так понимаю что в хрусте нет способа корректно продолжить операцию если он panic() захотел. Парадигма у них вроде бы такая. Собственно 9 итерация патчей хруста состоят из борьбы с подобной хренью чуть менее чем полностью. В процессе оказалось что патчи стали огромные и начали напоминать месиво.
> а дальше залогированно и напр. перезапущен упавший сервис)
Это какой такой сервис вы собрались перезапускать при хрустиковом panic()-е в ядре? Кернел то? Ну да, юзеры обожают ребуты и паники.
> Что легко бы нашли во время тестирования или уже у юзеров (прям
> как сейчас))). Только на много лет раньше.А вот это - ну не факт. Если кто хочет про память попиндеть, ядро под kasan и т.п. сейчас гоняют и он таки фатально валится при детекте проблем с памятью. А гугл и ко это к тому же делают под syzcaller'ом к тому же. У них там вообще забавная штука есть, syzbot. Сам fuzz'ит сам bisect'ит, сам баги пишет... небось и вон то отловлено какой-нибудь автоматикой типа этого.
> CVE-2022-2585 - уязвимость в POSIX CPU timer, вызванная тем, что при вызове из не лидирующей нити структура таймера остаётся в списке, несмотря на очистку выделенной для хранения памяти. Уязвимость присутствует начиная с выпуска 3.16-rc1.а по линку в баге
"This bug was introduced by commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task"), which is present since v5.7-rc1."
Вы не поняли. Ядро это не баг, ядро это фитча.
Но с таймером конечно засада. Тупенький баг.
Что-то я не понял, а где патчи?В каких ядрах пофикшено?
Текущие уже "старые":
5.19 2022-07-31
5.18.16 2022-08-03
Напиши сам, тебе бесплатно патчи высылать должны чтоли?
Надеюсь, что для RHEl 4 и Debian 8 выкатят фикс, даже несмотря на закончившуюся поддержку. Ради исключения.
Не выкатят, я гарантирую это.
Ради какого исключения? Это линукс, а не мелкософт какой-то, который еще для семерки фиксы выпускает!
Копроядра уже окаменели, пора закопать и обновиться.
Фиксы… Фиксы для копроОС, в которой не работает примерно ничего уже 10 лет. Оно долго живо только потому что это был последний тулчейн без метро, работоспособности это не очень помогает.
Фиксы… Фиксы для GNU, в котором не работает примерно ничего уже 20 лет. Его труп пинают только потому, что это был последний тулчейн без раста. Работоспособности это впрочем не помогает.
Кстати, GNU успешно развивается, это самая комфортная для работы система сегодня и каждый год она становится только лучше. Ядра только не завезли. А без раста всё без раста -- поделки, которые пытаются копировать GNU, поделками и остаются.
Да что там GNU? Вот BSD - да, успешно развивается, факт. Это самая комфортная для работы система на сегодняшний день и каждый год она становится только лучше. Вы коммиты видели? Растом там даже не пахнет! А ядро, ммм! А вот линуксы -- это всё поделки, которые пытаются копировать MS-DOS, поделками и остаются.
Хаха, на семерке прекрасно запускается что современный софт, что современные игры. Последнее что пробовал: Stray работает прекрасно. А все потому что некоторые умеют в обратную совместимость, в отличие от...
Она небезопасна - разумеется, но если гонять ее в виртуалке, то вполне норм.
Вряд ли. Может, ты думал, что прекрасно, а на самом деле там не было звука где-нибудь? Это прям вообще частая тема. С багами всё интереснее. В софте баги уровня format c выплывают при попытке запустить на 7. И анриал энжин нещитово наверно, с юнити больше проблем.
> современный софт,Adboe — всё.
Autodesk — всё.
VMWare — всё.
Список можно продолжить.
Продолжай.
Епт, да тот же Blender.
Да та же Krita.
Продолжай...
CAP_NET_ADMIN - это больше про контейнерщиков, смузи-докер, вот это всё. Этим можно. А вот с таймерами да, некрасиво.
Что не месяц то уйзвимость в netfilter, самое время переписать его на rust.
Ненужон, лучше бы bpfilter доделали
Коллеги, можете поджсказать, правильно ли понимаю, что отключение модуля cls_route (rmmod cls_route) не даст возможность для эксплуатации уязвимости?