The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимость в механизме ucount ядра Linux, позволяющая повысить свои привилегии

31.01.2022 11:58

В ядре Linux в коде обработки ограничений rlimit в разных пространствах имён идентификаторов пользователей (user namespaces) выявлена уязвимость (CVE-2022-24122), позволяющая повысить свои привилегии в системе. Проблема проявляется начиная с ядра Linux 5.14 и будет устранена в обновлениях 5.16.5 и 5.15.19. Стабильные ветки Debian, Ubuntu, SUSE/openSUSE и RHEL проблема не затрагивает, но проявляется в свежих ядрах Fedora и Arch Linux.

Ошибка внесена в добавленном летом 2021 года изменении, переводящем реализацию некоторых счётчиков RLIMIT на использование структуры "ucounts". Созданные для RLIMIT объекты "ucounts" продолжали использоваться после освобождения выделенной для них памяти (use-after-free) при удалении связанного с ними пространства имён, что позволяло добиться выполнения своего кода на уровне ядра.

Эксплуатация уязвимости непривилегированным пользователем возможна только при включении в системе непривилегированного доступа к пространству имён идентификаторов пользователей (unprivileged user namespace), который включён по умолчанию в Ubuntu и Fedora, но не активирован в Debian и RHEL. В качестве обходного пути для блокирования уязвимости можно отключить непривилегированный доступ к user namespace:


   sysctl -w kernel.unprivileged_userns_clone=0


  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Уязвимость в Glibc, позволяющая поднять привилегии в системе
  3. OpenNews: Раскрыты подробности о root-уязвимости в ядре Linux, атакованной на Pwn2Own
  4. OpenNews: Локальная root-уязвимость в ядре Linux
  5. OpenNews: Уязвимости в OpenSSL, Glibc, util-linux, драйверах i915 и vmwgfx
  6. OpenNews: Уязвимость в VFS ядра Linux, позволяющая повысить свои привилегии
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/56610-kernel
Ключевые слова: kernel, usernamespace
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (99) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:06, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Ну что, кто-нибудь ещё скажет что-нибудь после такого о превосходстве Сишников? То-то же! Раст всем голова.
     
     
  • 2.3, Урри (ok), 12:08, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Я тебя даже плюсанул. Вполне неплохой наброс.
     
     
  • 3.26, Аноним (26), 12:58, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Такой неплохой наброс можно писать под каждой новостью про очередную сишную дыру. То есть минимум раз день.
     
     
  • 4.38, Урри (ok), 13:29, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    И это хорошо!

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

     
     
  • 5.41, Аноним (26), 13:32, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +7 +/
    С мыслью "этому миру нужно больше дыр".
     
     
  • 6.46, Аноним (46), 14:03, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    До слёз ;)
     
  • 6.95, malloc (?), 20:05, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Говори за себя, дыра.
     
  • 2.14, Аноним (14), 12:34, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Головка.
     
     
  • 3.57, DD (??), 14:59, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вертеть?
     
  • 2.90, Аноним (90), 18:30, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "Безопасный язык" только предотвращает ситуации, от которых всё падает.
    Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код.
    И так как мышление становится пережитком прошлого -- как легко видеть из ситуации с растохайпом -- то бэкдоры служить будут сильно дольше, а внедрение их обойдётся значительно дешевле.

    Поэтому раст выгоден.
    Поэтому хайп будет нарастать.

     
     
  • 3.104, Аноним (104), 10:21, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это значит что и у Си после вычесывания удачи типичных ошибок переполнениями ... большой текст свёрнут, показать
     
     
  • 4.106, Аноним (-), 17:34, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > (хотя на
    > Расте тоже можно при желании в сишном стиле написать, с разделяемыми
    > между потоками данными и объектами синхронизации и поиметь тот же ворох
    > проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код").

    Ну вот! Видишь! И зачем тогда нужен этот ваш Раст? * пошел выкручивать из машины ненужные подушки и ремни безопасности вместе со смузихлебными ESC и ABS *


     
     
  • 5.107, Аноним (104), 17:57, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    так ведь "при желании"! Если есть желание "самоубиться" - пжалста! Но только наСильник будет пытаться упорно применять техники из Си в Расте.
     

  • 1.2, Урри (ok), 12:08, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Для сишечки тоже есть умные указатели.
    Например, https://github.com/Snaipe/libcsptr

    Но в ядре их не используют.

     
     
  • 2.6, Аноним (6), 12:11, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Умные указатели для неумных людей.
     
     
  • 3.12, ilyafedin (ok), 12:21, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +17 +/
    Умные люди, видимо, получают use-after-free уязвимости
     
     
  • 4.81, Аноним (81), 17:33, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На раст уже редох написали. Ага, дайте две.
     
  • 2.7, Аноним (1), 12:12, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это опционально, а нужно чтобы принудительно было, чтобы нельзя было забыть что-то где-то. Максимум компиляторногг контроля
     
     
  • 3.39, Урри (ok), 13:31, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не компиляторного. А со стороны непрерывной интеграции.
     
     
  • 4.56, Аноним (1), 14:59, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль. Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход
     
     
  • 5.59, Урри (ok), 15:14, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль.

    Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда.

    Я бы вообще просто по фразе "CI - костыль" выпинывал из профессии назад в то ПТУ, где оного персонажа учили, на второй год.

    > Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход

    Это корректный код?

    float sine(float x)
    {
      return cos(x);
    }

    а это?

    float enis(float x)
    {
      return cos(x);
    }

    Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?

     
     
  • 6.62, Аноним (1), 15:24, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда

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

    > Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?

    По содержательным вещам - пишется спецификация и доказывается. Пример - seL4

    Что же касается темы Си, Раста и всего такого - если можно вложить доп проверки, почему не вложить? Си пропустит такой кусок кода

    int * x;
    if <somecond> {
    int tmp = 1;
    x = &tmp;
    }

    хотя он явно не корректен и поймать это легко. Что Раст и делает и не допускает такой код

     
     
  • 7.67, Урри (ok), 16:08, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Берите шире - Вселенной И это не стеб и не сарказм Если при этом не ломать раб... большой текст свёрнут, показать
     
     
  • 8.69, Аноним (69), 16:37, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Почему Абстрактные рассуждения про цену звучат, конечно, классно, но где конкре... текст свёрнут, показать
     
     
  • 9.79, Урри (ok), 17:29, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Узковато мыслите Добавьте сюда цена разработки и цена сопровождения ... текст свёрнут, показать
     
     
  • 10.83, Аноним (69), 18:00, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так снижается же цена сопровождения наоборот, по сравнению с опасной процедурой... текст свёрнут, показать
     
  • 8.73, Анонн (?), 17:23, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Цена чего Покажи пример большого оверхеда Ты можешь завернуть критический учас... текст свёрнут, показать
     
     
  • 9.82, Урри (ok), 17:53, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Разработки и сопровождения у вас, растоманов, совсем каша в голове Я так и не ... большой текст свёрнут, показать
     
     
  • 10.86, Аноним (69), 18:06, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ниже Ordu писал о проблеме - проблема в семантике Си, в которой очень многое, с ... текст свёрнут, показать
     
  • 10.87, Анонн (?), 18:21, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну и где примеры высокой цены Разработки и сопровождения на расте То что науч... большой текст свёрнут, показать
     
  • 10.99, Аноним (-), 20:44, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    - code 1 2 The Structure of a Compiler 1 2 1 Lexical Analysis 1 2 2 Syntax Ana... большой текст свёрнут, показать
     
     
  • 11.100, Урри (ok), 00:22, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Когда закончились аргументы, побежим размахивать авторитетами Слив засчитан, ... текст свёрнут, показать
     
     
  • 12.102, Аноним (-), 03:31, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Когда Урри опять с умным видом пyкнул в лужу, демонстрируя незнание азов и _обще... текст свёрнут, показать
     
  • 5.68, анонимус (??), 16:22, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    не обязательно. логика простая - чем раньше обнаружена ошибка, тем ее дешевле править. так просто дешевле их править, но при строгом ci тоже вполне можно ловить большую часть. и на хрусте тоже надо писать тесты
     
     
  • 6.70, Аноним (69), 16:38, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не спорю, но чем больше у нас проверок на ранних этапах, тем лучше. Надеяться только на CI - уже попахивает костылищем
     
  • 2.8, Аноним (8), 12:13, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну нафиг, если они такие умные то рано или поздно выйдут из под контроля и образуют скайнет
     
     
  • 3.11, Жироватт (ok), 12:17, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    "Ты чё, умный дох*я? А, указатель? Память есть? А если найду?"
     
     
  • 4.28, Аноним (8), 13:00, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    память как бы не его, он на неё показать токмо и может
     
     
  • 5.30, bOOster (ok), 13:06, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > память как бы не его, он на неё показать токмо и может

    Ну это с какой стороны посмотреть. Умные указатели еще и для того чтобы память не освобождалась несколько раз. Так что можно сказать что указатель данную память забирает на себя.

     
  • 2.47, Ordu (ok), 14:07, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Там же только uniq_ptr и shared_ptr, причём со всеми граблями C++'овых аналогов, типа "никаких гарантий". Например, uniq_ptr может быть NULL, то есть просто взять и разадресовать его, не проверяя на NULL -- это лишь до первого бага, который положит NULL туда, где NULL быть не должно.

    Более того, насколько я вижу, эти указатели реализованы на _рантайм_ проверках, и более того эти рантайм проверки должны выполняться клиентским кодом. То есть, не, он может не проверять, и в случае ошибки в коде получит в рантайме разадресацию NULL с вытекающим из неё сегфолтом. Это _динамическая_ типизация в статически типизированном языке. В C++ тоже с этим проблемы вылезают[1]. Более того, если присмотреться[2], то проблема вытекает из свойств C и C++, которые делают невозможной move-семантику с compile-time проверками на то, что значение было перемещено, и поэтому программист, реализуя move constructor _вынужден_ обеспечивать своему типу специальное значение, которое семантически можно описать фразой "value was moved out, nothing to see here, go away", чтобы это значение можно было бы проверить в рантайме. А это означает, что uniq_ptr будет by design иметь значение NULL, и значит что если разадресовывая его ты забыл проверить на NULL, то значит ССЗБ.

    [1] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
    [2] https://www.thecodedmessage.com/posts/cpp-move/

    И это фундаментальная проблема, которая делает "умные" указатели бессмысленными в C и C++. Они не столько предотвращают ошибки, сколько снимают часть бойлерплейта, необходимого для того, чтобы избежать ошибок, и таким образом заметают потенциальные проблемы под ковёр, делают их менее заметными. Именно поэтому в ядре использовать uniq_ptr невозможно: в ядре всё в принципе по-возможности делается явным, чтобы было видно что происходит. Ядро пишется на C, и идеология написания кода ядра заточена под C: на компилятор нельзя полагаться, можно полагаться только на себя. Чтобы понять это, я могу порекомендовать Торвальдса, кормящего C++ тролля[3], где его ключевой тезис сводится к:

    C++ leads to really really bad design choices. You invariably start using
    the "nice" library features of the language like STL and Boost and other
    total and utter crap, that may "help" you program, but causes:

    - infinite amounts of pain when they don't work (and anybody who tells me
       that STL and especially Boost are stable and portable is just so full
       of BS that it's not even funny)

    - inefficient abstracted programming models where two years down the road
       you notice that some abstraction wasn't very efficient, but now all
       your code depends on all the nice object models around it, and you
       cannot fix it without rewriting your app.

    [3] https://harmful.cat-v.org/software/c++/linus

    То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app. А подход C++ не работает довольно часто, потому что он не устраняет ни одной проблемы C, он лишь декорирует их кружевами, позволяя в 90% случаев делать вид, что это не баг, а фича. Но в оставшихся 10% тебя ждут те самые infinite amounts of pain. И смарт-поинтеры, реализованные в C, не нужны в ядре по той же самой причине. Они не снимают ни одной проблемы: тебе точно так же придётся своими глазами следить за тем, чтобы не разадресовать нечаянно указатель, который был куда-то перемещён. Сама операция перемещения dst←src, с последующим обнулением src, будет чуть проще записываться, но следить за тем, чтобы не обращаться к src после перемещения ты точно так же будешь глазами. А каждый твой фейл будет приводить к рантайм краху. Это не делает программирование проще: проследить глазами за обнулением src проще, чем за тем, чтобы он потом не использовался.

    А если пытаться сделать всё хорошо и статически проверять все эти uniq_ptr, дабы не выносить проверки в рантайм, то:
    > if you try to statically detect such situations, you end up with Rust.[4]

    [4] https://www.foonathan.net/2017/09/destructive-move/

    Упс. И статические анализаторы не спасут C и C++, потому что эти языки не кодируют в своих API тех допущений, которые необходимы этим API для работы. Теоретически можно было бы API дополнять комментами (примерно как в некоторых динамических языках запиливают статическую типизацию, описывая типы в комментах), но хмм... я не уверен, что это сработает. Теоретически -- да, должно быть возможно, но практически, мы получим две одновременно действующие системы типов, и я подозреваю, это кончится таким уродством и ногу-сломишь-в-этом-коде, что нахрен никому не нужно. Проще лишнюю рантайм проверку вставить, и выкинуть панику если NULL оказался там, где его быть не должно.

     
     
  • 3.51, Аноним (51), 14:44, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Как поставить 100 плюсов?)
     
  • 3.58, Аноним (1), 15:08, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Браво за детальный ответ, сударь!
     
  • 3.77, Аноним (46), 17:28, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А ещё C++ абстракции не бесплатны.

    Например инициализация памяти с помощью конструкторов, которые вызывают конструкторы member-членов, которые вызывают ... ну вы поняли.

    Вместо того чтобы инициализировать кусок памяти разом и туда запихнуть весь layout структуры.

    В Zig отказались от (супер)быстрого pattern-matching. Потому что if else всё равно быстрее (до 10 раз).
    И компиляторы не способны в оптимизацию таких случаев как более простые и понятные конструкции.

    Поэтому до сих пор С быстрее С++.

    И, конечно, абстракции С++ текут. Например деструктор (и в нём надо защищаться от exception, использовать try / catch, и ... дальше у Майерса почитать).

    Получается лютый говнокод.

     
  • 3.84, Урри (ok), 18:01, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но я как бы и не говорил что умные указатели - серебряная пуля. Любой задаче, само собой, свои решения.

    Отличный ответ, без сомнения. За исключением некоторых моментов:


    > То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app.

    Это онтосится ко всем языкам и парадигмам программирования без исключений.

    > А подход C++ не работает довольно часто,

    А вот это совершенно не так. Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого.

    > позволяя в 90% случаев делать вид, что это не баг, а фича.

    И снова аргумент разбивается о реальность.

     
     
  • 4.111, Прохожий (??), 02:55, 03/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зато ты постоянно говорил, что умные указатели в плюсах - это так же эффективно ... большой текст свёрнут, показать
     
     
  • 5.116, Урри (ok), 12:50, 14/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да И продолжаю это говорить А сообщество в каждой новости это подтверждает А ... большой текст свёрнут, показать
     
     
  • 6.118, Прохожий (??), 01:47, 16/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не забывай в зеркало почаще смотреться Ты гораздо хуже Я-то прекрасно понял Т... большой текст свёрнут, показать
     
  • 3.88, Аноним (88), 18:26, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ладно крах при разименовывании NULL. Но от "что позволяло добиться выполнения своего кода на уровне ядра." как-то можно принципиально избавиться в таких случаях?
     
  • 2.50, Анонн (?), 14:15, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А толку что есть? Их все равно никогда (при жизни Линукса, по крайней мере) не затащат в ядро.
    Проект новье (вроде с 2016 года, но не точно). Не обкатано, не проверено. Еще и по MIT License.

    PS: О, неужели до сишников таки дошло что автоматическое управление памятью это хорошо?

     
     
  • 3.85, Урри (ok), 18:03, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > PS: О, неужели до сишников таки дошло что автоматическое управление памятью это
    > хорошо?

    Сишники, вообще-то, знают когда автоматическое управление памятью хорошо, а когда плохо. Для хорошо у них даже куча реализаций GC есть.

    https://github.com/mkirchner/gc

     
  • 2.110, Прохожий (??), 01:48, 03/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Q. Can I use this on a serious project ?
    A. Yes, but as this project has not been widely used, there might be some bugs. Beware!

    А ещё эта хрень зависит исключительно от одного свойства компилятора gcc, насколько я понял. То есть, для других компиляторов может не работать.

     
     
  • 3.117, Урри (ok), 12:52, 14/02/2022 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (38)

  • 1.4, макпыф (ok), 12:08, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > user namespace

    Второй ebpf

     
     
  • 2.10, Аноним (10), 12:15, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    отключается в отличие от, как я понял проблема в очередной раз притянута за уши и в данном случае речь просто об ошибке в ядре из-за недостаточно качественно проведённой работы по рефакторингу
     
     
  • 3.13, макпыф (ok), 12:33, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    всм? оба отключаются.

    Я про решетo, половина уязвимостей в ядре - ebpf и userns

    P.S. Почему ворд вильтер агрится на "решетo"

     
     
  • 4.21, Аноним (10), 12:49, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    как отключить ebpf в актуальном ядре?
     
     
  • 5.22, макпыф (ok), 12:52, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > как отключить ebpf в актуальном ядре?

    # CONFIG_BPF_SYSCALL is not set
    # CONFIG_BPF_JIT is not set

    CONFIG_BPF как я понял ни на что не влияет

    Алсо, в актуальном ядре оно запрещено непривелигерованным пользователям

     
     
  • 6.24, Аноним (10), 12:55, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это не ebpf. В выводе видно на что он влияет, но он тоже не отключается больше

    CONFIG_BPF=y
    # CONFIG_BPF_SYSCALL is not set
    CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
    # CONFIG_NETFILTER_XT_MATCH_BPF is not set
    # CONFIG_BPFILTER is not set
    # CONFIG_BPF_JIT is not set
    CONFIG_HAVE_EBPF_JIT=y

     
     
  • 7.27, макпыф (ok), 13:00, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не ebpf.

    cbpf мертв, не помню удалили его полностью или нет, но всегда используется ebpf

    > CONFIG_BPF=y

    Инклюдит мейкфайл bpf

    > # CONFIG_BPF_SYSCALL is not set

    Это оно как раз

    > CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
    > CONFIG_HAVE_EBPF_JIT=y

    Это значит что архитектура поддерживает ebpf jit

    > # CONFIG_NETFILTER_XT_MATCH_BPF is not set
    > # CONFIG_BPFILTER is not set
    > # CONFIG_BPF_JIT is not set

    Эти забыл, да.

    > он тоже не отключается больше

    Все норм отключается, и на мастере, и на next, и на 5.16


     
     
  • 8.34, Аноним (10), 13:17, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Раньше можно было убрать любые упоминания ... текст свёрнут, показать
     
  • 5.40, Аноним (26), 13:31, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  как отключить ebpf в актуальном ядре?

    Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную группу, практически per-appliaction firewall.

    А вот для не-рута надо запрещать, да.

     
     
  • 6.96, макпыф (ok), 20:27, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную
    > группу, практически per-appliaction firewall.

    Ну не всем и не всегда это требуется

    > А вот для не-рута надо запрещать, да.

    В принципе, в 5.16 так и сделано по дефолту

     
  • 4.65, Аноним (65), 15:57, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > P.S. Почему ворд вильтер агрится на "решетo"

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

     
  • 3.16, Аноньимъ (ok), 12:38, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >речь просто об ошибке в ядре

    Всего-то на всего. Тьфу ерунда.

     
     
  • 4.23, Аноним (10), 12:54, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы кое-кто выполнял работу более аккуратно, этого можно было бы избежать. Или если бы другой кое-кто проследил, что ожидаемая и предсказуемая ошибка не была допущена. Не стоит стигматизировать удобные механизмы из-за банального раздолбайства.
     
  • 2.35, Аноним (35), 13:18, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    первый.

    Лет десять уже этой попытке сделать чтоб вот любой юзер был как рут, но не совсем. На пол-шишечки.

    Опыт винды (где это даже не считается уязвимостью) ничему не научил. Вернее, научил все тому же - "мне двойное то же самое что тому джентльмену!"

     
  • 2.61, псевдонимус (?), 15:23, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Первый хронологически.
     

  • 1.5, Аноним (10), 12:10, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory

    CONFIG_USER_NS=y

    что надо включить?

     
  • 1.9, Аноним (6), 12:13, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    >Проблема проявляется начиная с ядра Linux 5.14
    >linux-image-generic/impish-updates,impish-security,now 5.13.0.27.37 amd64 [установлен, автоматически]
     
     
  • 2.43, НяшМяш (ok), 13:40, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого патча и гордится этим.
     
     
  • 3.66, Аноним (65), 16:01, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого
    > патча и гордится этим.

    Актуальные бунту ядра поддерживаются самой канониклой, а вот насколько эта сикурити-поддержка качественная, это уже другой разговор, не нужно ссылаться на то, что ядра бунт уже EOL в kernel.org, что у Debian подобная практика имеется, что у красношляпы.
    Я удивлён, что вы про это не знали, или если это такой наброс с вашей стороны, также удивлён, вроде такой сурьёзный мужчина?!

     
     
  • 4.93, НяшМяш (ok), 19:17, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > а вот насколько эта сикурити-поддержка качественная

    Меня смущает тот факт, что патч версия у Анонима (6) до сих пор 0, хотя на кернел.орг последний патч для этой версии был 9. И тут есть два варианта - либо они нарушают версионирование (что плохо), либо они не обновляют патч версии из апстрима (что тоже плохо). В общем, убунтыдебианы сами себе проблем создают, вместо того чтобы использовать LTS с кернел.орг

    > вроде такой сурьёзный мужчина?!

    Вот это уже обидно было. Был бы я серьёзным - не страдал бы фигнёй на опеннете xD

     
     
  • 5.94, mikhailnov (ok), 20:01, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У убунты ядро всегда версии x.y.0, они много чего в него переносят, не поднимая 0, иначе бы их версия, допустим, 5.13.6 не соответствовала бы настоящей 5.13.6.
     

  • 1.15, Аноним (46), 12:34, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Вот и разбиваются доводы Военов АнтиРастового Сопротивления о суровую реальность и кучи уязвимостей.

    Не могут даже ucount безопасно отрефакторить, отличный язык.

    JavaScript получше будет.

     
  • 1.17, Аноним (17), 12:44, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А вы спрашиваете, зачем стейбл во времена блидинг эджей.
     
  • 1.18, Шарп (ok), 12:44, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >use-after-free

    пикачу^Wrust - я выбираю тебя!

     
     
  • 2.31, Аноним (14), 13:10, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А C# уже всё, не в моде?
     
     
  • 3.89, Аноним (88), 18:29, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Будето там такого нельзя. При желании тоже можно звать объект после вызова деструктора.
     
  • 2.36, Аноним (36), 13:20, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что не питон?
     

  • 1.45, Fracta1L (ok), 13:48, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > продолжали использоваться после освобождения выделенной для них памяти (use-after-free)

    Захохотал

     
     
  • 2.48, Аноним (46), 14:08, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free?

    Погонять на устройствах, отловить такие баги, часть хотя бы.

    Походу дела ядро вообще не тестируют.

    Вроде что-то похожее использует в Zig.

     
     
  • 3.55, Аноним (55), 14:50, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Походу дела ядро вообще не тестируют.

    Ядро тестируют на пользователях, это официальная позиция корпораций-разработчиков.

     
  • 3.112, anonymous (??), 11:57, 03/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free?

    Для этого нужно прогнать через всевозможные сценарии использования и окружения. Иначе можно и не поймать.

     
  • 2.54, Аноним (55), 14:48, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Redox is a Unix-like Operating System written in Rust

    Да, я тоже посмеялся.

     
     
  • 3.71, Аноним (-), 16:43, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Redox is a Unix-like Operating System written in Rust
    > Да, я тоже посмеялся.

    Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого Вторжения"?


     
     
  • 4.92, самокатофил (?), 19:16, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>> Redox is a Unix-like Operating System written in Rust
    >> Да, я тоже посмеялся.
    > Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают
    > раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого
    > Вторжения"?
    >"Redox is not correct, secure, or documented. It does a lot of things in a cavalier, leave it up to the application, manner. Applications can malloc and forget to free, Redox will not clean this up. Applications can access missing memory or kernel memory, Redox does not care. All applications run in Ring 0, and have all permissions. Some syscalls use vtables that rely on exactly the same struct defintions in userspace as kernel space. Syscalls cannot return values, except by writing them into a passed pointer. Memory allocation is done in the application, and uses a global memory allocation table that applications directly modify. None of its functionality is documented, outside of example source files." -- https://redox-os.org/

    Гениально, Карл! С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом. А учитывая что этому хелловорду даже CVE присваивать стыдно -- то можно с уверенностью сказать, что редох это флагман безопасности осестроения растаманек. :-D

     
     
  • 5.113, anonymous (??), 12:02, 03/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом.

    Если не знаете -- это понятно. Но вы не увиливайте: там use-after-free много уже нашли или нет?

     
  • 2.109, Аноним (14), 21:07, 02/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Rust-то такого не позволяет. Он просто память не освобождает, потому и нет use-after-free.
     
     
  • 3.114, anonymous (??), 12:04, 03/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле "не освобождает"? Вы про что? Можно так же ссылку на первоисточник? И напомню, что вы сказали про Rust, а не про Redox.
     

  • 1.49, Анонн (?), 14:11, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Йохохо, всего два дня прошло с предыдущей дыры, а тут уже новая подоспела. И опять повышение привилегий, и опять налажали с памятью.
    Стабильность признак мастерства!
     
     
  • 2.53, Аниме (?), 14:46, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Растовчане то так не могут, что за неудачники
     
     
  • 3.64, DD (??), 15:38, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Янукович & Co?
     

  • 1.60, псевдонимус (?), 15:16, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И снова неймспейсы. Эта музыка будет вечной.
     
  • 1.63, RAMbug (?), 15:32, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    И снова перекидывания фекалиями фанатиков раста и сишечки.

    Дело не в том, что какой-то из этих языков лучше или хуже, а в том, что ядро Linux — это 30-летний поток монолитного говнокода без какого-либо намёка на продуманную архитектуру и контроля за качеством.

     
     
  • 2.98, nvidiaamd (?), 20:31, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И тут ты такой из-за угла с продуманной архитектурой. Что, нету? Странно.
     

  • 1.72, самокатофил (?), 16:50, 31/01/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Растаманьки, скажите, а правда что в расте невозможен use after free по определению? :-)

    lynx -dump 'https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust' | grep -A1 -B1 'use-after-free' --color

     
     
  • 2.91, Аноним (-), 19:04, 31/01/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    у растенек все течёт, но это безопасно. ведь порчи данных не будет, будет постоянный отказ в обслуживании или автоподрыв ракет
     
     
  • 3.101, x3who (?), 03:08, 01/02/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > автоподрыв ракет

    Да ладно, всё решается избыточностью - запускаем, допустим, пять контейнеров, в каждом из которых независимо крутятся программы управления ракетой, написанные независимыми группами разработчиков  на расте, электроне, сиплюсплюсе, петоне и джаво. Сверяем сигналы управления, которые генерируют эти программы. Если, допустим, какой-то контейнер выдал на элерон №1 управляющий сигнал, на N% отличающийся от того, что выдало большинство сервисов, то перезапускаем проштрафившийся сервис, сигналы от остальных усредняем. Если кворума вообще никакого нет, т.е. все пять сервисов выдают сигналы с разбросом более N%, то отключаем нафиг всю эту халабуду и летим как деды летали - на резервном контроллере, запрограммированном на сишечке..

     
     
  • 4.115, www2 (??), 07:50, 14/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее всего получится ситуация "а вы друзья, как ни садитесь, всё в музыканты не годитесь" и ракета всё-таки полетит на резервном контроллере, запрограммированном на сишечке. Но в пресс-релизах будет только пятикратный кворум, встроенный кубернетес и прочее вот это вот всё. Иначе не получится распиливать.
     

  • 1.103, soup2 (?), 08:32, 01/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь будет Rust Kernel за место Linux Kernel xDDDDDDDD
     
  • 1.105, Аноним (105), 13:04, 01/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    что-то в винде меньше дырок чем находят в linux kernel..
     
     
  • 2.108, Аноним (108), 00:46, 02/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не поверите - у винды исходники закрыты, поэтому приходится страдать и искать уязвимости в отладчиках и дизассемблерах с гораздо меньшей эффективностью, но гораздо более тяжёлыми последствиями. Вероятность того, что найдут zero day, который поставит раком половину планеты, как шифратор Petya через SMB протокол, сильно выше, чем в линуксе.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру