URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 128032
[ Назад ]

Исходное сообщение
"Уязвимость в ядре Linux, позволяющая обойти ограничения режима Lockdown"

Отправлено opennews , 21-Июл-22 10:33 
В ядре Linux выявлена уязвимость (CVE-2022-21505), позволяющая легко обойти механизм защиты  Lockdown, который ограничивает доступ пользователя root к ядру и блокирует пути обхода UEFI Secure Boot. Для обхода предлагается использовать подсистему ядра IMA (Integrity Measurement Architecture), предназначенную для проверки целостности компонентов операционной системы по цифровым подписям и хэшам...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=57534


Содержание

Сообщения в этом обсуждении
"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено АнонимкаРастуимка , 21-Июл-22 10:33 
Всё потому что ненараст

/всёпотомучтохочуминусов


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 10:44 
А вот если бы Аноним с опеннета был написан на раст, то и комментарии были бы качественными

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 10:49 
Rust — это уже прошлое, ядро нужно переписать на Project Verona.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено АнонимкаРастуимка , 21-Июл-22 10:49 
А он на раст?

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 11:13 
Он на C++, но когда-нибудь его перепишут на JS++.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено АнонимкаРастуимка , 21-Июл-22 12:29 
перепишут на JS++
<<
тогда и предлегай, че не по теме то?

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 10:54 
Project Verona ещё жив?

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 11:18 
Жив и "completely memory safe"!

https://www.zdnet.com/article/microsoft-heres-why-we-love-pr.../


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 12:43 
> completely memory safe

Решает NP полную задачу за полиномиальное время?


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Иноагент , 21-Июл-22 10:54 
Ненавязчивое пропихивание Secure Boot?

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 19:32 
Ох...я бы с радостью с ним бы работал, если бы была бы его настройка с линуксом более юзерфрендли и если был компании не начудили подписями. Самое грустно, этой проблеме более 5-7 лет и никто ничего с этим не хочет делать

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 09:49 
1) Сабж ортогонален секурбуту как таковой. Это режим усиленной безопасности системы, когда некоторые (изначально задуманные) ограничения не может обойти даже рут фокусами с патчингом ядра, дебажными фичами и доступом в физическую память или железо.
2) Сабж можно использовать и без секурбута. Если понимать некоторые моменты. Если атакующий вам кернел заменит на свой, где фича отключена, тогда смысла от фичи? :)
3) Новость гонит и к UEFI это вообще не относится. Кроме того момента что для signed ядер которые сватаются под секурбут логично это включать. Иначе любой с правами рута на секурбут влет забьет.
4) SecureBoot может быть и без UEFI, например, как в андроидах: их бутлоадеры ни разу не EFI но это не мешает им проверять подписи следующих ступеней лоадеров а потом и ядер до запуска.
5) Вероятно, фича продвигается в том числе и корпами делающими вон те андроиды из 4). Но может работать и для простого смертного. А если вы купили систему которую не контролируете - это уже вопрос к вам.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 09:39 
Полезность замка зависит от того у кого ключи. Я для себя это использую и вот так это секурити фича. Зарубающая некоторые направления взлома системы для того кто не owner. Пруфом owner'ства является ключ подписи модулей ядра и т.п.. - им же по моему и образ ядра для kexec можно подписать.

Без этого защита с подписями модулей и проч - немного декоративная: даже если root не может грузить подписаные модули, он может полностью перехватить систему через /dev/mem например, напрямую порулив железом или что-нибудь пропатчив. Или допустим сделав kexec на свое ядро, которое мы приперли и которое никаких подписей вообще не хочет.

Может ли корпорас использовать фичу для того чтобы вас выпереть из НеВашей системы? О, разумеется. И тут вопрос за кого вас держат в том или ином случае.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 11:29 
Ты еще расскажи, как подписываешь на изолированном от внешнего мира компьютере в подземном бункере.

А на деле окажется, что подкроватный локалхост - неуловимый джо, который никому не нужен.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 11:43 
> Ты еще расскажи, как подписываешь на изолированном от внешнего мира компьютере в
> подземном бункере.

Как говорил заяц волку в анекдот - "а кайф - в том чтобы яйца вовремя с рельсов убрать". Самый кайф это когда некий IO есть а вот возможности получения вреда от него - минимизированы.

> А на деле окажется, что подкроватный локалхост - неуловимый джо, который никому не нужен.

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


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Ананоним , 21-Июл-22 11:17 
Надо было писать на Ada.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 11:24 
Ada устарела, переходите на ParaSail.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Массоны Рептилоиды , 21-Июл-22 11:43 
А можно ссылку на репозиторий? Ах да, забыл. Они же релизы на гуглодиске в zip-архивах держат

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 11:59 
наноядро?

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено microsoft , 21-Июл-22 11:30 
> механизм защиты Lockdown

Это не для защиты. Так что не баг а фича, и полезная.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 12:02 
вопрос немного не в тему: как собрать ядро минимального размера, с хорошей производительностью? zstd?

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноня , 21-Июл-22 12:23 
Что zstd? Это же метод сжатия, он не влияет.
Ищи конфиги, где порезано лишнее, zen-kernel например.

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


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 12:29 
для моего случая:
+ genkernel
  + по идее итак лишнее отсеивается (лишние модули)
+ в настройках включить:
  + оптимизация для размера (-O)
  + сильное сжатие ядра
+ удалить System.map

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 12:35 
> минимального размера

размер чего? образа на диске/флешке? потребляемой памяти при работе?

Обычно на настольных компьютерах, размер диска намного больше размера оперативной памяти. Сам можешь оценить смысл такой оптимизации/минимизации.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 12:54 
в общем да - размер ядра на разделе /boot довольно небольшой (9.2M), большой размер initramfs (208M)

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 21-Июл-22 12:57 
initramfs - это уже не ядро.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 13:34 
> initramfs

В котором glibc, coreuils, bash, lvm, весь набор существующих на свете драйверов, микрокоды ко всем процессорам и устройствам, и остальной ненужный хлам?

Но это не важно, initramfs выгружается после переключения на rootfs. Но это не точно.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 14:31 
Откуда столько? У нас на арче с любым ядром и сжатием zstd размер загрузочного образа метров 20. У меня так размер самого раздела /boot всего 200 метров, и это еще с лихвой выделено "про запас".

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 16:02 
gentoo: genkernel, lvm, luks, btrfs

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 21-Июл-22 12:56 
Размер монолитного образа ядра в оперативной памяти. Вопрос не про смысл, а про баланс.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 13:26 
Вопрос в чём? Ну, включил в монолитное ядро драйвер графики, который больше всего остального вместе взятого и в образе, и в памяти, и во время работы. Что оптимизировать, графику отключить?

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 21-Июл-22 13:33 
Сколько занимает драйвер графики в этих 9.2M, если он такой большой? Почему он такой большой? Что кроме графики отключить, чтобы стало меньше?

Вопрос в том, как собрать ядро минимального размера, с хорошей производительностью.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 13:56 
Оптимизационные задачи поиска (глобального) экстремума можно решать методом градиентного спуска (при определенных условиях).

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 21-Июл-22 14:27 
Жду опыт, а не советы.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 19:44 
Какой опыт, градиентный спуск?

Примерный план: делаешь шаг-действие (включаешь/отключаешь опцию) и смотришь результат. Если результат ближе к оптимальному/минимальному (идешь вниз), то ты на верном пути, дальше меняешь относительно этого более оптимального варианта. Если результат дальше от оптимального/минимального (идешь в гору), то ты на неправильном пути, откатываешь изменение, работаешь с предыдущего оптимального набора опций.

Так шаг за шагом добираешься до (локального) экстремума - спускаешься на дно.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 13:57 
Вы определитесь что нужнее - размер или производительность.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 21-Июл-22 14:30 
А что, есть опции? Минимизация - значит убрать лишнее, неиспользуемое, ненужное.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Michael Shigorin R7 , 21-Июл-22 19:00 
Телепаты в отпуске, а ТЗ не наблюдается.

Размер и производительность бывают связаны сложно, нередко противонаправленно.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 19:37 
Так сначала нужно понять, что Вы считаете "лишним"
Вообще непонятно для чего Вам нужна оптимизация, что Вы будете задействовать при работе

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Какаянахренразница , 22-Июл-22 03:40 
Чего непонятно-то? Аноним задал простой и естественный вопрос какпройтивбиблиотеку. Он даже повторил его два раза.

> как собрать ядро минимального размера,
> с хорошей производительностью.

Какая буква вам непонятна? Так отвечайте на его вопрос.

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

Если ещё будут вопросы, ты спрашивай, не стесняйся.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 22-Июл-22 07:13 
Вот спасибки, ну хоть беседу поддержать и то хорошо.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 12:48 
>Обычно на настольных компьютерах, размер диска намного больше размера оперативной памяти.

И в эмбедете тоже много памяти? Мой роутер находится в категории 4/32 и его выпилили из openwrt за то что современный линукс слишком жирный что суда влезть!


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 17:10 
> И в эмбедете тоже много памяти? Мой роутер находится в категории 4/32
> и его выпилили из openwrt за то что современный линукс слишком
> жирный что суда влезть!

Вообще, 32 мегов RAM нормально. А вот в 4 мега не лезет разжиревшая Люся. Урезанный образ без гуя до сих пор реально сделать, но места там впритык. Если делать нехрен и флешка SPI'ная, ее можно при сильном желании перепаять, 8 пинов не особо утомительно. Параллельную ну нафиг - гиморнее.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено fuggy , 22-Июл-22 03:08 
Использовать ядро версии 2.6

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 10:11 
> вопрос немного не в тему: как собрать ядро минимального размера, с хорошей
> производительностью?

Использовать мозг!

Самый очевидный способ: отпилить все что лично вам не надо в именно ваших системах.
Pros: более 9000 дров для ненужно, фич которые вы не юзаете и обвес для них пойдет в пень.
Cons: неуниверсально, если все же понадобится пойдете пересобирать кернел. Надо хорошо знать что потребно для старта именно ваших систем, иначе вас ждет много горя.

Улучшение идеи: запихать то что совсем жалко выпиливать но раз в полгода надо в модули.
Pros: ядро по прежнему мелкое.
Cons: а вот модулей уже не так мелко и при билде потребуется время на их сборку

Бонус к этому: модули тоже можно сжимать. Либо сжатием в ФС, либо ядро может сжатые модули грузить.
Pros: модули займут меньше места.
Cons: грузиться при старте системы они будут несколько медленнее

Сбилдить с -Os (в настройках ядра).
Pros: весь код ядра и модулей станет заметно меньше.
Cons: тормознее vs -O2 он тоже станет, увы.
Hint: потуги с -O3 не имеют смысла, часто скорость даже хуже а код сильно жирнее O2.

Плотное сжатие: если размер ядра любой ценой, выбрать сжатие xz или lzma. Это мощнее zstd.
Pros: уменьшение размера файла ядра нахаляву.
Cons: распаковка не быстрая, можно получить пару секунд при загрузке на анпак ядра. Однако после этого скорость ничем не отличается.

Если важна скорость, билдить с HZ = 100.
Pros: несколько % скорости нашару.
Cons: латенси системы пробьет дно - вариант для нагруженного сервера, а не десктопа. В остальных случаях - смотря что оно делает.

Вырубить mitigations!
Pros: скорость прибавится
Cons: это ценой не совсем очевидных но неприятных вулнов на процах с спекулятивщиной (топовые ARM, почти все x86 кроме атомов).

Есть еще более 9000 способов твикать в ту или другую сторону. По мере желания и копания в фичах найдете. Ну или если совсем не едет,

> zstd?

Агаблин, серебряные пули использовать. Он не рекордсмен по степени сжатия, но хорош по соотношению плотности сжатия к скорости распаковки. Сольет на несколько процентов lzma и xz (xz это вариант lzma по смыслу + некие стероиды). Зато распаковка в несколько РАЗ быстрее. Разницу между 2 и 0.5 секунды на распаковку ядра при загрузке вполне можно ощутить. На скорость работы ядра все это никак не влияет.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 24-Июл-22 13:42 
>более 9000 дров для ненужно

Списочек можно? Какие дрова типично выкидываются для десктопного применения.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 25-Июл-22 14:27 
> Списочек можно? Какие дрова типично выкидываются для десктопного применения.

Врядли у вас на десктопе есть что-нибудь с infiniband или иное откровенно датацентровое и энтерпрайзное за много денег. Или вооооон тот сенсор давления на SPI - откуда он в десктопе? Там и SPI скорее всего нет (в планшетных уродцах даже на x86 он таки может быть).

А так зазырить свои lsmod, builtin модули и dmesg - даст некое понимание чего активно вообще и почему. Вот это придется собирать, иначе работать не будет. Модули файлух тоже лучше все же собрать, невозможность подцепить ту или иную ФС все же обидна. Хотя есть серьезный шанс что NILFS2 вы на жизненном пути не встретите. Как и JFS. И так далее.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Анончик , 24-Июл-22 13:47 
Или для серверов без экзотического железа, некоторой степени выдержки (максимально стандартного железа).

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Anybody , 22-Июл-22 14:41 
>как собрать ядро

Какое ядро? Учебники собирай, мамкин собиратель.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 12:28 
> To defeat lockdown, boot without Secure Boot and add ima_appraise=log to the kernel command line

Ясно.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Alladin , 21-Июл-22 12:45 
Придумали защиту защитную для многих только мешающую.

А потом хоба защиту ломанули, но никто не заметил ее.. так как мало кто включает:)


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 10:17 
> А потом хоба защиту ломанули, но никто не заметил ее.. так как
> мало кто включает:)

А все потому что 95% далеко не гроссмейстеры и на их системах творится помойка. Хотя корпы вам фич и без этого на каком-нибудь андроиде включат, потому что если вы не хозяин в системе и так решено - то уж не хозяин.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено ИмяХ , 21-Июл-22 15:52 
>>ограничивает доступ пользователя root

А как этого пользователя зовут? SYSTEM? Или TrustedInstaller?


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 16:31 
Внезапно, его зовут root...

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 10:59 
> А как этого пользователя зовут? SYSTEM? Или TrustedInstaller?

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


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 21-Июл-22 16:45 
И снова чтобы получить рут нужен рут. Обожаю уязвимости в Линуксе.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 10:15 
У каждой новости есть заказчик.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 10:53 
> И снова чтобы получить рут нужен рут.

Идея сабжа в том чтобы на рута все же применялись некоторые ограничения. А CVE в том что на эти ограничения рут как оказалось все же может забить. Хоть это и не было частью плана.



"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Skullnet , 21-Июл-22 16:45 
> блокирует пути обхода UEFI Secure Boot

И так отключен, поэтому пофиг)


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 10:51 
> И так отключен, поэтому пофиг)

Skullnet решил блеснуть системной экспертизой на двоих с переводчиком новости... впрочем от того кто сисчитает иксы чем-то хорошим иного и не ожидалось.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Skullnet , 23-Июл-22 00:41 
Для глупых, secure boot нужен, чтобы зафорсить винду. На этом его полезность заканчивается.

"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 25-Июл-22 14:45 
> Для глупых, secure boot нужен, чтобы зафорсить винду. На этом его полезность
> заканчивается.

ORLY? А я то им пользуюсь для того чтобы я мог грузить мои системные компоненты, а левые васи - нет. Кстати на вон тех ARM винда и так то не загрузится, хотя-бы потому что "драйверов нету, бжад!!!111". При этом lockdown оказывается очень в тему. Иначе можно легко отменить эти ограничения, сделав kexec() или сменив ядро на вариант не требующий подписи модулей.

То-есть, это уже опровергает тезис "На этом его полезность заканчивается". Что я про системную экспертизу говорил? Если вы не умеете фичами пользоваться во свое благо - блин, да вы даже в барак с замком у надсмотрщика по сути добровольно заходите. А можно - только подумайте - вообще не ходить в барак с надсмотрщиком. За это даже не будет ничего, единственный минус - надсмотрщик не притащит баланду, не предоставит хату, придется как-то канителиться самому уже со всем этим.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 07:48 
"уязвимость (CVE-2022-21505), позволяющая легко обойти механизм защиты Lockdown, который ограничивает доступ пользователя root к ядру и блокирует пути обхода UEFI Secure Boot"

Так это уязвимость дле проталкивателей Secure boot, для нормальных людей - это фича!


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 10:52 
> Так это уязвимость дле проталкивателей Secure boot, для нормальных людей - это фича!

Secure boot можно и для себя использовать так то. Вплоть до обладания мастер ключом платформы. Тогда это лишь инструмент безопасности.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Мимокрокодилъ , 22-Июл-22 11:04 
>> Так это уязвимость дле проталкивателей Secure boot, для нормальных людей - это фича!
> Secure boot можно и для себя использовать так то. Вплоть до обладания
> мастер ключом платформы. Тогда это лишь инструмент безопасности.

Можно, но не нужно. Переусложнение системы, где без этого можно обойтись, это верная дорога к дополнительным потенциальным проблемам. Чем сложнее механизм, тем больше "точек отказа".
А в случае с Secure boot, так это вообще механизм вендорлока by design, поводок ещё не затянули, но он уже наброшен, а скоро и намордник подоспеет.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 11:52 
> Можно, но не нужно.

А с чего вы будете за всех рещать что и кому нужно? Я вот фичой пользуюсь. Если вам не надо - не включайте ее в системе сборки да и делов. Но тогда и смысл в подписях допустим ядра и модулей нулевой. И в целом - любой прорубившийся до рута в этой системе - бог, и может вас вертеть на всем чем посчитает нужным, подменяя абстракции на свои произвольным образом.

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

Конкретно сабж не такой уж сложный и лишь зарубает некоторые откровенно провальные операции при своей активации, позволяющие перехватить контроль над системой не имеючи валидного ключа которым подписаны модули, etc. CVE состоит в том что путем вон того финта ушами это удалось обойти.

> А в случае с Secure boot, так это вообще механизм вендорлока by design,

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

> поводок ещё не затянули, но он уже наброшен, а скоро и намордник подоспеет.

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

Возможно, вы хотели сказать что не надо покупать лоченое железо где вас вендор за лоха держит? Да, но это немного другая формулировка. Замок в двери - фича, если запирает хату от воров. И баг, если не дает выйти мне из хаты когда я этого захочу.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Иван Васильевич , 23-Июл-22 11:38 
>> Можно, но не нужно.
> А с чего вы будете за всех рещать что и кому нужно?
> Я вот фичой пользуюсь. Если вам не надо - не включайте
> ее в системе сборки да и делов.

Вы о чём вообще? Речь про механизм Secure boot на уровне недобиоса, причём тут система сборки?!
И потом, "а с чего это вы будете решать за всех", нужно ли оно во всём железе, может быть те, кому это надо, будут покупать это опицонально устанавливать в своё железо? Ах уже почти нигде нельзя, потому что почти везде оно есть уже дефолтно, а что так, любители под свою любимую ОС, компания-производитель которой держит за гениталии все эти ключи, имея "одно кольцо, чтобы управлять всеми" может значит решать за всех, так получается?!

Претензия не к подписям, а к поводку, который by design реализован таким образом, что он для вендорлока, а не для какой-то там "защиты", хотя, если для "защиты", от потенциальных конкурентов, то да.
C Pluton'ом же тоже будет защита, от ...нежелательного конкурента, но вы продолжайте верить в "галактико опасносте"


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 25-Июл-22 14:58 
> Вы о чём вообще? Речь про механизм Secure boot на уровне недобиоса,

Secure Boot можно делать по разному. И BIOS'ом вон тот бутлоадер может и не являться, в том смысле что никакого IO он никому не обеспечивает, только кернел пинает. Ну или не пинает, если подпись, вот, не совпала.

Сабжевой фиче вообще класть активен ли на платформе секурбут и уж тем более как он там реализован. Есть патформы где секурбут есть а никаких EFI и BIOS вообще нет. Скажем ведроиды многочисленные. И таки да, kexec() это один из популярных способов обхода секурбута.

> причём тут система сборки?!

При том что компилять ли вообще САБЖ и если да, то активировать ли его по дефолту - выбирается там.

> И потом, "а с чего это вы будете решать за всех", нужно ли оно во всём железе,
> может быть те, кому это надо,будут покупать это опицонально устанавливать в своё железо?

Так я примерно это и делаю.

> Ах уже почти нигде нельзя, потому что почти везде оно есть уже дефолтно, а
> что так, любители под свою любимую ОС, компания-производитель которой держит за
> гениталии все эти ключи, имея "одно кольцо, чтобы управлять всеми" может
> значит решать за всех, так получается?!

Немного не угадали. Я просто решил что раз пошла такая пьянка, нехило бы стать сам себе OEM'ом слегка. И все. А на будущее покупать железо которое я контролирую реально, а не так что добрый белый человек принес клевое одеяло, оказавшееся на поверку тифозным.

И вот в таких парадигмах сабж таки фича. А то что пожирателей кактсусов отимеют - их что так имеют, что этак. Какая разница?

> Претензия не к подписям, а к поводку, который by design реализован таким образом,
> что он для вендорлока, а не для какой-то там "защиты",

Сабжевая фича - как замок. Может запирать мой дом. А может и запираться снаружи, надсмотрщиком. И цель тут, очевидно, не оказаться в том бараке. Если вы все же туда попадаете, с аргументом "зато попу рвать в поисках жилья не надо" - ну, э, на что жалуетесь? Вам очень понятно показывают чьи это системы и кто рулит банкетом. До вас медленно доходит? Или вы надеетесь переть против воли system implementer'а? Второе тяжко и не очень эффективно, новые версии будут фиксить любые баги которые вы найдете, и если system implementer решил вас в стойло - значит, в стойло. Единственный разумный вариант - быть разборчивым в покупке железа.

> C Pluton'ом же тоже будет защита, от ...нежелательного конкурента, но вы продолжайте
> верить в "галактико опасносте"

У меня просто не будет ни одной системы с плутоном. Это я вам обещаю. На этой планете хренова куча чипов всех мастей и направлений, на мой век SoC и процессоров явно хватит. Даже если для их поиска и придется посуетиться чуть больше чем покупка мутной пакости в ближайшем ларьке.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 11:18 
> Вплоть до обладания мастер ключом платформы.

Ключом-секретом является информация, которая недоступна недоверенному лицу. Блоб - это недоступная тебе информация, это тоже ключ-секрет, которым ты не обладаешь.

Например, я удалили корневой ключ от ms в secureboot, но он все равно светится в efivars. Что с ним делает чужой блоб?


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 22-Июл-22 11:54 
> Ключом-секретом является информация, которая недоступна недоверенному лицу. Блоб - это
> недоступная тебе информация, это тоже ключ-секрет, которым ты не обладаешь.

Спасибо Капитан Очевидность.

> Например, я удалили корневой ключ от ms в secureboot, но он все
> равно светится в efivars. Что с ним делает чужой блоб?

Я не знаю о чем вы и как это относится к именно сабжу или тому коменту. У вас какой-то вклин на конкретных взбрыках какого-то UEFI с какими-то мудасофтскими ключами. И все это круто, но не понятно при чем тут я.


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено pavlinux , 25-Июл-22 10:57 
> ограничивается доступ к /dev/mem, /dev/kmem, /dev/port, /proc/kcore, debugfs,
> отладочному режиму kprobes, mmiotrace, tracefs, BPF, PCMCIA CIS, некоторым
> интерфейсам ACPI и MSR-регистрам CPU, блокируются вызовы kexec_file и
> kexec_load, запрещается переход в спящий режим, лимитируется использование DMA
> для PCI-устройств, запрещается импорт кода ACPI из переменных EFI, не  
> допускаются манипуляции с портами ввода/вывода, в том числе изменение
> номера прерывания и порта ввода/вывода для последовательного порта.

Вот, бл.., скажите, кто оставляет в ядре всю эту шнягу, на том серваке, где можно ждать атак?    


"Уязвимость в ядре Linux, позволяющая обойти ограничения режи..."
Отправлено Аноним , 25-Июл-22 15:04 
Дистры линукса, лол. Кроме того - ну, э, /dev/mem так то штатная фича линуха. А то что тебе через него можно всю систему развандалить, имея рут, ну... такой вот интерфейс, рут же изначально супербог. Проблема в том что поимение рута в такой парадигме ведет к полному и необратимому взъ#$у системы, к тому же не детектированному так изначально.