Уже год одна фирма пытается заставить ФСТЭК вести базу данных прошивок различного IoT-оборудования и прочей электроники. Пока безуспешно, насколько вижу.
Системные компоненты естественно с перезагрузкой. При А/B обновлении у вас две копии ОС, и обновления устанавливаются в ту, которая на текущий момент не запущена.
Прочитайте статью по моей ссылке выше, она разъяснит все моменты.
Ключ сейчас по умолчанию только один — Майкрософтовский. На части материнских плат есть еще ключи от Red Hat, Canonical. Они хранятся в HSM (аппаратном хранилище), украсть их нетривиально, просто так утечь не могут.
Чтобы отозвать работу Linux-ПО в UEFI, достаточно отозвать всё до определённой версии через SBAT.
Или вы про rootfs, если поставщик будет его подписывать, и этот ключ утечёт? Можно, чтобы локальный ключ пользователя дополнительно подписывал цепочку загрузки, но не видел, чтобы такое реализовывали (что-то похожее на подписи локально компилируемых DKMS-модулей должно быть, наверное).
Их в любой момент можно отключить, не удаляя из системы, при необходимости отладки. И это не отдельные пакеты, а немногочисленные логические группы (наборы) ПО, которые, например, можно откатить на предыдущую версию единым целым, а не отдельными библиотеками и пакетами.
Атомарно обновляемые системы можно реализовать разными способами, сейчас все пытаются придумать наиболее удобные сочетания. Посмотрим, какой из них в итоге обретёт наибольшую популярность.
Вы про Secure Boot? Эту проблему решили в shim'е специальным маркером версии под названием SBAT: https://github.com/rhboot/shim/blob/main/SBAT.md Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
Это разные инструменты. Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива). В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.
На практике с этим подходом также применяют A/B-обновления: новые данные записываются в другой слот, и следующая перезагрузка загрузит обновлённую версию. А если что-то пошло не так, автоматика это поймёт и загрузит предыдущий, старый и рабочий слот.
rootfs поставляется производителем дистрибутива в минимальном виде, вместе со всеми метаданными и чексуммами (CAS; dm-verity/fs-verity, заверенный ключом поставщика), обновляется единым целым;
по сети передаётся минимум данных благодаря Content‑Addressable Store (CAS): сначала ваш существующий rootfs хешируется маленькими блоками, а затем с сервера скачивается только разница между новым rootfs и существующим, поблочно (блоки могут быть в разных местах, главное совпадение хеша);
все немногочисленные дополнительные системные пакеты переустанавливаются при каждом обновлении, формируя доп. слой поверх rootfs (почти как docker build);
Вы всегда видите разницу (можете сделать diff) между эталонным образом и вашими изменениями (dev-слоя, например). Если что-то сломалось, можете отбросить dev-слой и загрузиться в неизменённую систему. Dev-слоев может быть несколько (и в глубь, и в ширь), можете безопасно экспериментировать с системой, нужны в переустановке не возникнет никогда, потому что снизу у вас эталонный неизменяемый образ.
Сейчас в подавляющем большинстве дистрибутивов у вас нет понятия эталонной файловой системы, вы не можете посмотреть только ваши изменения поверх ФС, не можете легко их откатить.
При этом rootfs-образ может быть изначально оптимизирован под порядок чтения с него (блоки расположены в том порядке, в котором система к ним обращается во время загрузки, из-за чего с диска производится быстрое последовательное чтение вместо медленного случайного), сжат. Преимуществ много.
Если вы не специалист по безопасности и не отслеживаете индустрию, со стороны здраво оценить состояние дел не представляется возможным: многие критические уязвимости просто не попадают в поле зрения технических СМИ, а другие не расписываются понятным для обычного человека языком, и становятся информационным шумом, а не полезной новостью, на которую можно отреагировать осмысленным действием.
Security-журналистика, нацеленная на простых смертных, мертва. Не уверен, что она вообще существовала.
Вы переусложнением считаете что-то конкретное? В Embedded-индустрии применяется многое, о чём он пишет, да и разрабатываемые, но ещё не мейнстримные дистрибутивы Fedora Atomic / Ubuntu Core Desktop реализуют большинство из описываемого.
Linux в плане безопасности (и удобства использования подсистем безопасности) отстает на годы от конкурентов, увы.
Классические дистрибутивы Linux теряют свою консистентность в общем смысле сразу после установки на файловую систему.
Современные дистрибутивы стремятся так или иначе перенять подход мобильных систем: чтобы был некий rootfs, поставляемый дистрибутивом, который монтируется в неизменяемом виде, поверх него при необходимости монтируются overlay-файловые системы (с драйверами и другими системными изменениями), либо же «разработческий» слой при необходимости внесения изменений в rootfs.
Приложения все устанавливаются в пользовательские директории. Конфигурационные файлы хранятся на отдельной ФС (покрывающей /etc и /var), либо же у пользователя.
Преимущества: возможность нормального аудита, возможность сброса настроек как на телефонах, атомарные обновления, понимание состояния/консистентности системы.
В моей деревне были таксофоны а-ля АМТ 69 (не уверен, что именно эта модель), модернизированные под карту, без монетоприёмника.
Абсолютно все, кого я знаю, звонили с них бесплатно, сначала набирая 01/02/03, а затем опуская рычаг трубки не до конца (или очень быстро), чтобы линия сбросилась, а мозги таксофона это не обнаружили.
Похожий трюк, только ровно наоборот, я делал позже на вот таком: опусканием рычажка не до конца сбрасывал мозги телефона, но не линию, и набирал номер сбросом целиком (у нас везде был импульсный набор). Еще у него голосом проговаривался остаток минут на карте, и если его прогличить, можно было заставить его произнести: «остаток: 4 миллиарда, 294 миллиона…» (но звонить всё равно не получалось).
Вопреки всем задокументированным публично ресурсам, которые утверждают, что связь через человека-коммутатора исчезла в восьмидесятых-начале девяностых, в другом посёлке такая связь сохранялась как минимум до начала нулевых.
Какие для вас деньги — деньги, и насколько быстрыми они должны быть? Когда жил в Москве, у меня было ощущение, что деньги отовсюду рекой льются, успевай только руки подставлять. Подработки по 4-5 часов по субботам 1-2 раза в месяц, приносящие +60-120 тысяч, были в порядке вещей. Если чуть мыслить out-of-the-box, разумно анализировать индустрию в целом и потребности людей в тех областях, в чём разбираешься, и ставить целью заработок, думаю, можно было делать +300 тысяч к основной зарплате не сильно напрягаясь, а рвя зад и миллион в месяц по ощущениям был реален. Для меня мои подработки были существенными и быстрыми (в смысле затрачиваемого времени) деньгами. Речь про 2021-2022 годы.
Ходил, к слову, через патрики на работу каждый день, и угорал с местной богемы :D Тем не менее, там было много интересных людей.
Уже год одна фирма пытается заставить ФСТЭК вести базу данных прошивок различного IoT-оборудования и прочей электроники. Пока безуспешно, насколько вижу.
А зачем:
https://4pda.to/forum/index.php?showtopic=1074858&view=findpost&p=138757647
https://4pda.to/forum/index.php?showtopic=1074858&view=findpost&p=138761715
https://www.ferra.ru/news/tv/umnye-televizory-yandeksa-stali-aktivnee-zakhvatyvat-khakery-v-botnety-22-12-2024.htm
Системные компоненты естественно с перезагрузкой.
При А/B обновлении у вас две копии ОС, и обновления устанавливаются в ту, которая на текущий момент не запущена.
Прочитайте статью по моей ссылке выше, она разъяснит все моменты.
Ключ сейчас по умолчанию только один — Майкрософтовский. На части материнских плат есть еще ключи от Red Hat, Canonical.
Они хранятся в HSM (аппаратном хранилище), украсть их нетривиально, просто так утечь не могут.
Чтобы отозвать работу Linux-ПО в UEFI, достаточно отозвать всё до определённой версии через SBAT.
Или вы про rootfs, если поставщик будет его подписывать, и этот ключ утечёт? Можно, чтобы локальный ключ пользователя дополнительно подписывал цепочку загрузки, но не видел, чтобы такое реализовывали (что-то похожее на подписи локально компилируемых DKMS-модулей должно быть, наверное).
Их в любой момент можно отключить, не удаляя из системы, при необходимости отладки. И это не отдельные пакеты, а немногочисленные логические группы (наборы) ПО, которые, например, можно откатить на предыдущую версию единым целым, а не отдельными библиотеками и пакетами.
Атомарно обновляемые системы можно реализовать разными способами, сейчас все пытаются придумать наиболее удобные сочетания. Посмотрим, какой из них в итоге обретёт наибольшую популярность.
Вы про Secure Boot?
Эту проблему решили в shim'е специальным маркером версии под названием SBAT: https://github.com/rhboot/shim/blob/main/SBAT.md
Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
Это системный компонент, поэтому нет. Полагаю, он будет в составе слоя "такой-то-desktop", который монтируется поверх rootfs.
Ubuntu'вский Snap подходит и для системных компонентов (он может «добавлять» симлинки в /usr/bin и подобные системные директории на свои snap'ы)
Это пользовательское ПО и оно устанавливается в домашнюю директорию (или какую-то общую директорию с ПО), а не в систему.
В Ubuntu Core это Snap'ы.
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
Это разные инструменты.
Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива).
В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.
Десктопы: macOS, Windows (в плане защиты ядра). Смартфонные Android и iOS давно впереди любой десктопной ОС, про них и говорить не стоит.
На практике с этим подходом также применяют A/B-обновления: новые данные записываются в другой слот, и следующая перезагрузка загрузит обновлённую версию. А если что-то пошло не так, автоматика это поймёт и загрузит предыдущий, старый и рабочий слот.
rootfs поставляется производителем дистрибутива в минимальном виде, вместе со всеми метаданными и чексуммами (CAS; dm-verity/fs-verity, заверенный ключом поставщика), обновляется единым целым;
по сети передаётся минимум данных благодаря Content‑Addressable Store (CAS): сначала ваш существующий rootfs хешируется маленькими блоками, а затем с сервера скачивается только разница между новым rootfs и существующим, поблочно (блоки могут быть в разных местах, главное совпадение хеша);
все немногочисленные дополнительные системные пакеты переустанавливаются при каждом обновлении, формируя доп. слой поверх rootfs (почти как docker build);
Вы всегда видите разницу (можете сделать diff) между эталонным образом и вашими изменениями (dev-слоя, например). Если что-то сломалось, можете отбросить dev-слой и загрузиться в неизменённую систему. Dev-слоев может быть несколько (и в глубь, и в ширь), можете безопасно экспериментировать с системой, нужны в переустановке не возникнет никогда, потому что снизу у вас эталонный неизменяемый образ.
Сейчас в подавляющем большинстве дистрибутивов у вас нет понятия эталонной файловой системы, вы не можете посмотреть только ваши изменения поверх ФС, не можете легко их откатить.
При этом rootfs-образ может быть изначально оптимизирован под порядок чтения с него (блоки расположены в том порядке, в котором система к ним обращается во время загрузки, из-за чего с диска производится быстрое последовательное чтение вместо медленного случайного), сжат. Преимуществ много.
Если вы не специалист по безопасности и не отслеживаете индустрию, со стороны здраво оценить состояние дел не представляется возможным: многие критические уязвимости просто не попадают в поле зрения технических СМИ, а другие не расписываются понятным для обычного человека языком, и становятся информационным шумом, а не полезной новостью, на которую можно отреагировать осмысленным действием.
Security-журналистика, нацеленная на простых смертных, мертва. Не уверен, что она вообще существовала.
Вы переусложнением считаете что-то конкретное?
В Embedded-индустрии применяется многое, о чём он пишет, да и разрабатываемые, но ещё не мейнстримные дистрибутивы Fedora Atomic / Ubuntu Core Desktop реализуют большинство из описываемого.
Linux в плане безопасности (и удобства использования подсистем безопасности) отстает на годы от конкурентов, увы.
Классические дистрибутивы Linux теряют свою консистентность в общем смысле сразу после установки на файловую систему.
Современные дистрибутивы стремятся так или иначе перенять подход мобильных систем: чтобы был некий rootfs, поставляемый дистрибутивом, который монтируется в неизменяемом виде, поверх него при необходимости монтируются overlay-файловые системы (с драйверами и другими системными изменениями), либо же «разработческий» слой при необходимости внесения изменений в rootfs.
Приложения все устанавливаются в пользовательские директории. Конфигурационные файлы хранятся на отдельной ФС (покрывающей /etc и /var), либо же у пользователя.
Преимущества: возможность нормального аудита, возможность сброса настроек как на телефонах, атомарные обновления, понимание состояния/консистентности системы.
Самое толковое видение, что я читал — у Леннарта Поттеринга, разрабтчика systemd: https://0pointer.net/blog/fitting-everything-together.html
Да вроде прямо с классическим был, уже не помню. Либо с цифровым по 3 в ряд, но точно не с этим.
В моей деревне были таксофоны а-ля АМТ 69 (не уверен, что именно эта модель), модернизированные под карту, без монетоприёмника.
Абсолютно все, кого я знаю, звонили с них бесплатно, сначала набирая 01/02/03, а затем опуская рычаг трубки не до конца (или очень быстро), чтобы линия сбросилась, а мозги таксофона это не обнаружили.
Похожий трюк, только ровно наоборот, я делал позже на вот таком: опусканием рычажка не до конца сбрасывал мозги телефона, но не линию, и набирал номер сбросом целиком (у нас везде был импульсный набор). Еще у него голосом проговаривался остаток минут на карте, и если его прогличить, можно было заставить его произнести: «остаток: 4 миллиарда, 294 миллиона…» (но звонить всё равно не получалось).
Вопреки всем задокументированным публично ресурсам, которые утверждают, что связь через человека-коммутатора исчезла в восьмидесятых-начале девяностых, в другом посёлке такая связь сохранялась как минимум до начала нулевых.
Какие для вас деньги — деньги, и насколько быстрыми они должны быть?
Когда жил в Москве, у меня было ощущение, что деньги отовсюду рекой льются, успевай только руки подставлять. Подработки по 4-5 часов по субботам 1-2 раза в месяц, приносящие +60-120 тысяч, были в порядке вещей. Если чуть мыслить out-of-the-box, разумно анализировать индустрию в целом и потребности людей в тех областях, в чём разбираешься, и ставить целью заработок, думаю, можно было делать +300 тысяч к основной зарплате не сильно напрягаясь, а рвя зад и миллион в месяц по ощущениям был реален.
Для меня мои подработки были существенными и быстрыми (в смысле затрачиваемого времени) деньгами. Речь про 2021-2022 годы.
Ходил, к слову, через патрики на работу каждый день, и угорал с местной богемы :D
Тем не менее, там было много интересных людей.
Ничего себе как корейцы свободно из музыки в it входят
Я на бизнес-тарифе с оплатой по количеству мест, не знаю, какая сейчас стоимость с оплатой по факту использования api/токенов у Anthropic.