Linux 6.11

Шо, боишься ниасилить? Не, тут надо себя заставлять! :)

Модераторы! Уберите картинку

Нормальная картинка. Торвальдс в носу ковыряется)

Не, я подожду когда ктонить сюда принесёт

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853 – «fs: don’t block i_writecount during exec».

Christian Brauner пишет:

Back in 2021 we already discussed removing deny_write_access() for
executables. Back then I was hesistant because I thought that this might
cause issues in userspace. But even back then I had started taking some
notes on what could potentially depend on this and I didn't come up with
a lot so I've changed my mind and I would like to try this.

Here are some of the notes that I took:

(1) The deny_write_access() mechanism is causing really pointless issues
    such as [1]. If a thread in a thread-group opens a file writable,
    then writes some stuff, then closing the file descriptor and then
    calling execve() they can fail the execve() with ETXTBUSY because
    another thread in the thread-group could have concurrently called
    fork(). Multi-threaded libraries such as go suffer from this.

(2) There are userspace attacks that rely on overwriting the binary of a
    running process. These attacks are _mitigated_ but _not at all
    prevented_ from ocurring by the deny_write_access() mechanism.

    I'll go over some details. The clearest example of such attacks was
    the attack against runC in CVE-2019-5736 (cf. [3]).

    An attack could compromise the runC host binary from inside a
    _privileged_ runC container. The malicious binary could then be used
    to take over the host.

    (It is crucial to note that this attack is _not_ possible with
     unprivileged containers. IOW, the setup here is already insecure.)

    The attack can be made when attaching to a running container or when
    starting a container running a specially crafted image. For example,
    when runC attaches to a container the attacker can trick it into
    executing itself.

    This could be done by replacing the target binary inside the
    container with a custom binary pointing back at the runC binary
    itself. As an example, if the target binary was /bin/bash, this
    could be replaced with an executable script specifying the
    interpreter path #!/proc/self/exe.

    As such when /bin/bash is executed inside the container, instead the
    target of /proc/self/exe will be executed. That magic link will
    point to the runc binary on the host. The attacker can then proceed
    to write to the target of /proc/self/exe to try and overwrite the
    runC binary on the host.

    However, this will not succeed because of deny_write_access(). Now,
    one might think that this would prevent the attack but it doesn't.

    To overcome this, the attacker has multiple ways:
    * Open a file descriptor to /proc/self/exe using the O_PATH flag and
      then proceed to reopen the binary as O_WRONLY through
      /proc/self/fd/<nr> and try to write to it in a busy loop from a
      separate process. Ultimately it will succeed when the runC binary
      exits. After this the runC binary is compromised and can be used
      to attack other containers or the host itself.
    * Use a malicious shared library annotating a function in there with
      the constructor attribute making the malicious function run as an
      initializor. The malicious library will then open /proc/self/exe
      for creating a new entry under /proc/self/fd/<nr>. It'll then call
      exec to a) force runC to exit and b) hand the file descriptor off
      to a program that then reopens /proc/self/fd/<nr> for writing
      (which is now possible because runC has exited) and overwriting
      that binary.

    To sum up: the deny_write_access() mechanism doesn't prevent such
    attacks in insecure setups. It just makes them minimally harder.
    That's all.

    The only way back then to prevent this is to create a temporary copy
    of the calling binary itself when it starts or attaches to
    containers. So what I did back then for LXC (and Aleksa for runC)
    was to create an anonymous, in-memory file using the memfd_create()
    system call and to copy itself into the temporary in-memory file,
    which is then sealed to prevent further modifications. This sealed,
    in-memory file copy is then executed instead of the original on-disk
    binary.

    Any compromising write operations from a privileged container to the
    host binary will then write to the temporary in-memory binary and
    not to the host binary on-disk, preserving the integrity of the host
    binary. Also as the temporary, in-memory binary is sealed, writes to
    this will also fail.

    The point is that deny_write_access() is uselss to prevent these
    attacks.

(3) Denying write access to an inode because it's currently used in an
    exec path could easily be done on an LSM level. It might need an
    additional hook but that should be about it.

(4) The MAP_DENYWRITE flag for mmap() has been deprecated a long time
    ago so while we do protect the main executable the bigger portion of
    the things you'd think need protecting such as the shared libraries
    aren't. IOW, we let anyone happily overwrite shared libraries.

(5) We removed all remaining uses of VM_DENYWRITE in [2]. That means:
    (5.1) We removed the legacy uselib() protection for preventing
          overwriting of shared libraries. Nobody cared in 3 years.
    (5.2) We allow write access to the elf interpreter after exec
          completed treating it on a par with shared libraries.

Yes, someone in userspace could potentially be relying on this. It's not
completely out of the realm of possibility but let's find out if that's
actually the case and not guess.

[1] https://github.com/golang/go/issues/22315 – «os: StartProcess ETXTBSY race on Unix systems».
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49624efa65ac – «Pull MAP_DENYWRITE removal from David Hildenbrand», «Remove all in-tree usage of MAP_DENYWRITE from the kernel and remove VM_DENYWRITE».
[3] https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736

Прикольно чувак резюмировал в конце, мол, потенциальные атаки не исключены, но давайте выясним на практике, так ли это, а не будем гадать :)

Аффиггейшн.жпг... Это какой-то... офигеть... Не. Буду сидеть на старом ядре пока не наиграются.

Буду сидеть на старом ядре

Насколько старом? [2] приняли в 5.15.

А что тогда разрешили теперь? ННП...

Запись в исполняемый файл запущенного процесса.

Насколько старом?

2.6.39 наше всё! Было еще вроде даже 2.6.40 у Федорки со своими патчами, если не изменяет память.

P.S. https://www.fedora.md/2011/08/11/linux-2-6-40-эксклюзив-для-fedora/

Хотя да, то по сути было уже 3.0.

ИМХО, картинка неуместна конкретно в данном случае. Это же просто релиз ядра очередной. Если бы там было что-то про отношение NVidia и ядра, или Линус бы опять на кого-то наорал, возможно, такая картинка была бы уместна. А тут как-то ни к чему.

Да вроде уже поддерживается, вот с ноутбуками всё сложно, добавляют поддержку через DeviceTree, а не ACPI. Видимо, там всё жутко гвоздями к винде прибито.

https://news.ycombinator.com/item?id=40350408

Arm SystemReady SR/ES assumes sane ACPI tables. That’s something that Snapdragon X (1st-gen) very much doesn’t have. The ACPI tables present there are pretty much only usable for Windows if you want full functionality.

С того.

man mmap

А где написано что что-то обходили? Хочешь портить память процессу - порти, больше не запрещаем. Хотя на самом деле я не знаю что там сделали, может и организовали чтоб на уже запущеные не влияло.

Прирост на 156% AES-GCM для zen4/5, надо будет когда-нибудь ещё и ядро linux-xanmod-x64v4 поставить, посмотреть, даёт ли что-нибудь в реальной жизни

В debian 11 ядро 5.10, а это ещё лет 5.

А где поддержка Snapdragon X Elite в Linux

А где эти устройства в России или хотя бы доставка с алиэкспресса? Вообще такое впечатление, что снова дикий дефицит чипов, так медленно новые всякие amd ai 300 и snap-ы выходят на рынок

В debian 11 ядро 5.10

А в бэкпортах? А в 12-м ? Да и вообще: http://snapshot.debian.org/package/linux/

эксперимент оказался неудачным, вместо ядра обсуждают палец.

Так а что ещё обсуждать? Допустим, раньше я мог поворчать из-за Wireguard в ядре или возрадоваться exfat не через fuse. А тут минорщина какая-то.

Тогда как средний палец - это интересно. Например, у лошадей и ослов остался единственный палец - средний. Получается, что некоторые пальцеходящие животные - факоходящие.

Сконпелял.

Честно говоря разницы особой не уловил.

Лезть глубоко не хочу, может кто подскажет, CONFIG_HZ можно передавать ведру при загрузке?

Бекпорты ставят когда не хватает фич, а этот этап с линуксом закончился ещё где-то в районе 3.х версий. Багфиксы же приносят в штатную версию.

Снятие запрета на запись в исполняемые файлы, связанные с работающими процессами.

Из каких соображений его вообще вкорячили изначально? Чтобы что не случилось?

Rust Rust Rust Rust Rust Rust

https://www.youtube.com/watch?v=TB2wqzGSsqM (Why Rust Tutorials Do This Every Time? - Tsoding) (2:11)

Ну, если все бинари подписывать, то, может, оно и не так страшно... :)

Сдается мне, что бы маппинг бинаря на память не покорежился. Сегменты бинаря же mmap'ом на память процесса отображаются (see mmstruct). Хотя, это моя гипотеза, я в тот кусок ядра, который про mmap и файловый кеш, пока не заглядывал.

Добавлена возможность удаления фрагментов кода драйверов блочных устройств на языке Rust...
с корнями, из системы и вместе с разработчиками Rust

а шо за дивна картинка была? линус с пальцем? :о)

https://www.linux.org.ru/news/kernel/17731774/history

и где там палец, кот. тут обсуждают? в версии - две еденицы? так там дальше еще «стрелка» - слив обозначает?! :о)

в версии - две еденицы?

Значит, не для всех. :)
А так?.

ну так-то ясен пень! наш корки мочит!
вот был-же когда-то приличным человеком! всех посылал куда «по делу». а тут тебе «на» - раст пропихнули без мыла, политика, мать ее...!!! :о)

Снятие запрета на запись в исполняемые файлы, связанные с работающими процессами. Ранее при попытке записи в исполняемый файл запущенного процесса ядро выводило ошибку.

Прикольно, а я никогда даже не пытался так сделать

dron@gnu:~/Рабочий-стол/test$ echo test > a.out 
bash: a.out: Текстовый файл занят
dron@gnu:~/Рабочий-стол/test$ 

Ура, я успел! Но… зачем разрешать по умолчанию перезаписывать исполняемый файл во время его работы? Не будут ли приложения семи себе BSS константы перезаписывать? Ну хрен знает, ну приспичит кому, при этом хеш суммы поедут и паранойя будет, мол а чёэто у меня debsumm у установленного пакета не может хеши проверить и всё, паника, паранойя, бутылка, алкоголизм, долгое лечение, развод и вся жизнь на смарку.

Ну, а если серьёзно зачем? Обновлять файл? Так ядро не запрещает удалять и подменять целиком исполняемый файл, применять при обновлении бинаря не его замену, а замену его части? Так в этом тоже смысла нет. Дописывать в конец работающего исполняемого файла данные? Зачем?

UDP:

• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853

Всё равно херня какая-то тут точно где-то есть и будут не очевидные грабли из за которых в следующей версии всё откатят. назад. Вот к гадалке не ходи. Что-то да случится. А уж какое раздолье для всяких нехороших программ ой мама не горюй.

Берёшь такой бинарь проверяешь его, в нём всё чисто и нет обращений к сети, запустил его, а он что-то модифицировал в себе и при следующем запуске уже делает запрос к сети. Весело, опять же вся инфраструктура основанная на хеш суммах поедет нахер, если теперь это будет фича, самоизменяемые бинари, во класс. Не, это прикольно и можно наверное делать что-то полезное, но если это станет популярно, ну а чё можно же! То это значит такой софт тупо будет падать на прошлых версиях ядра, и превратит /usr/bin в кажу из непонятно чего.

Вишенка на торте

Yes, someone in userspace could potentially be relying on this. It's not
completely out of the realm of possibility but let's find out if that's
actually the case and not guess

Буквально (не перевод, а смысл), давайте просто попробуем это сделать, авось прокатит. Мы понятия не имеем к чему это может привести, у нас мол даже цели никакой нет, просто вот. Живите теперь с этим, может быть у вас что-то отвалится, кек лол.

Так что вопрос «зачем?» остался, не зачем, а просто так. Но зачем просто так?

Надо новости вот так писать (и вообще всегда так писать, клин клином)

Вышел очередной релиз ядра Linux 6.11 написанного на языке Си с рядом значимых изменений преимущественно связанных с языком Си, важнейшие среди которых:

• Добавлена, в реализацию на языке Си, поддержка операций атомарной записи, на блочном уровне на языке Си, при которых на накопитель записывается, через механизмы языка Си, либо весь указанный набор блоков,реализованных на языке Си, либо ни один из блоков. Это может предотвратить ситуации, когда после сбоя оборудования или по иной причине записывается лишь часть блоков, а в другой части остаётся старая информация. Включение атомарного режима записи осуществляется системным вызовом pwritev() на языке Си в который добавлен флаг RWF_ATOMIC для языка Си. Снятие запрета на запись в исполняемые файлы, связанные с работающими процессами на языке Си и не только. Ранее при попытке записи в исполняемый файл запущенного процесса ядро выводило ошибку.
• Добавлена возможность разработки драйверов блочных устройств на языке Rust через привязки к языку Си. В качестве примера в ядро добавлен драйвер rnull, представляющий собой аналог драйвера null_blk на языке Си, написанный на языке Rust через привязки к языку Си. Также продолжен перенос изменений из ветки Rust-for-Linux (линукс написан на языке Си), связанных с использованием языка Rust в качестве второго языка (первый и главный это язык Си) для разработки драйверов и модулей ядра, через привязки к языку Си, (поддержка Rust не активна по умолчанию, и не приводит ко включению Rust в число обязательных сборочных зависимостей к ядру), при этом всё для языка Си есть из коробки.

Добавлена возможность разработки драйверов блочных устройств на языке Rust

Почему это «важнейшее изменение»? Какие конкретно корпы и разработчики хотели и могли писать драйвера на Rust, но им не хватало такой возможности именно в ядре Linux?

Снятие запрета на запись в исполняемые файлы...

похоже на внедрение в линукс зондов и прочих «за все хорошее против всех плохих».

В каком дистре выпустят 6.11 первым? Кто как думает?

В Арче есть в Core-Testing.
А deb xanmod я ещё вчера установил. 😀

А с чего бы это вдруг? Пишет в другой дескриптор, как и обычный файл.

Это как это А с чего бы это вдруг[2]?

Попробуй замаппить файл и понаписать в него что-нибудь из другого процесса. Запишется и будет видно из маппинга.

А в 6.11?

Не знаю, не проверял и не вчитывался :-)

А, если ты про MAP_PRIVATE, то в mmap(2) написано

It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region.

Надо полагать, с исполняемыми файлами тоже unspecified.

Нет, он резюмировал совсем другое. Он сказал, что (1) никакие атаки это никогда не предотвращало и не предотвращает, а (2) «не исключены, но давайте выясним на практике, так ли это» — это про прочие побочные эффекты (слом совместимости).

Снятие запрета на запись в исполняемые файлы, связанные с работающими процессами. Ранее при попытке записи в исполняемый файл запущенного процесса ядро выводило ошибку.

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

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

Это и раньше можно было, если хочешь защититься от этого, то сделай его readonly.

Так запись же один фик через ядро проходит - какие проблемы засунуть в память изменяемые сегменты перед их изменением?

Я даже не буду спекулировать на эту тему. Если ты уже в ядре, то проблем особо не видно (ну, с поправкой на синхронизацию), а снаружи есть защита памяти.

Или подпиши :)

Видимо описанная схема не актуальна.

Исполнямый файл не обязательно нативный бинарник, это и скрипт может быть.

MAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region.

Забыли добавить, что эта штука работает только если нижележащий слой это поддерживает.

Спрашивайте у чатгпт, если кому интересно найти такие девайсы, гугл про них не знает.