Меню Рубрики

Linux mint uefi secure boot

Linux mint uefi secure boot

Здравствуйте!
Некий Rod Smith, (я полагаю все таки не футболист) накатал гениальную статью. http://www.rodsbooks.com/efi-bootloader . eboot.html Набрел на нее в Release Notes for Linux Mint 18.1 Xfce
В силу скромных познаний как в английском языке так и тонкостях работы электронных устройств прошу прокомментировать некоторые моменты.
В ходе установки Linux Mint 18.1 Xfce в режиме UEFI дабы установить пропиетарные драйвера инсталятор предложил отключить Secure Boot что я и сделал следуя инструкции (придумал пароль и ввел при загрузке), и теперь ноут грузится в boot in insecure mode
Хотелось бы выяснить я этими действиями теперь «прошил» ноут что вообще отключил Secure Boot для всех систем которые установлены на ноуте (в частности Win10) или только для линукса? Потому как в настройках биоса (даже не знаю как правильно называть базовые установки меню) в общем в базовых настройках ноута режимы UEFI и Secure Boot включены, но еще до загрузки меню GRUB на несколько секунд проскакивает строчка boot in insecure mode. Конечно приятно что теперь пропиетарные драйвера видеокарты установились и я теперь (вроде бы могу ) переключаться между режимами Intel и Ge force, но как то неприятно что ради этого я напрочь убил Secure Boot (если это действительно так), ибо я вряд ли буду играть в игры в линуксе и использовать возможности ускорителя.

В общем учитывая статью в особенности секцию Using the Shim Program подтвердите или опровергните мои опасения.

In early 2017, Secure Boot is a modest-to-major hassle for Linux users. Although Secure Boot has the potential to improve security, Linux has historically not been plagued by viruses, so it’s unclear that Secure Boot will be a benefit for Linux-only computers. If you dual-boot with Windows, though, you may want to keep Secure Boot enabled. Using the Shim program looks like the best way to do this for users of Fedora, OpenSUSE, Ubuntu, and other distributions that support Shim. If you’re using another distribution or are having trouble booting multiple distributions, disabling Secure Boot is the easiest way to deal with it. Signing your own boot loaders to use the native Secure Boot mechanism and your own key set is another alternative, and one that provides you with the greatest security and flexibility. This approach is the hardest one to implement, particularly if your computer’s firmware setup utility lacks the ability to add keys..

UEFI. Сделка с Secure Boot

UEFI. Сделка с Secure Boot

Похоже, что у Вас какая-то странная реализация UEFI (по крайней мере, впервые с таким сталкиваюсь), которая позволяет даже при включенном Secure Boot загружать неподписанные загрузчики. Иначе как Вы установили Минт (см. ниже)? Вообще, если он (Secure Boot) у Вас действительно работает так и это нельзя изменить, толку от него ноль.

Secure Boot работает следующим образом: у EFI-приложения (обычно это загрузчик ОС) проверяется цифровая подпись, и если она соответствует ключу из хранилища, то выполнение этого приложения разрешается. Таким образом исключается возможность загрузки недоверенных приложений и подмены доверенных.

Теперь о проблемах такого подхода. По умолчанию на всех компьютерах с Secure Boot в хранилище есть лишь ключ Microsoft, который используется для загрузки Windows.

И, наконец, о том, почему Secure Boot с ключом от Microsoft вас не защитит — он был взломан по их же неосторожности . Так что реальный толк от Secure Boot есть лишь в том случае, если поместить в хранилище свои собственные ключи и подписывать ими загрузчик и ядро. Это, однако, довольно сложная тема, поэтому расписывать её я не буду. У Рода Смита есть статьи на эту тему.

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

Подводя итог: обычному пользователю включенный Secure Boot ни к чему и будет только мешать. Если же пользователь — параноик и действительно заботится о безопасности своих данных, то доверять Майкрософту он не будет, а сгенерирует и установит свои ключи, удалив все остальные.

UEFI. Сделка с Secure Boot

nimms , Спасибо! Вы многое прояснили хотя кое какие вопросы остались. Я конечно параноик, но умеренный. Винда для игрушек и некоторых приложений которые не всегда корректно работают в виртуалбоксе, и стороннего антивируса на ней нет, только ее собственный Защитник (ноут покупался с Win8 но в своё время был обновлен до Win10 по ее назойливому предложению).
По поводу физического доступа понятно, но по поводу прав суперпользователя я из тех лентяев который в винде не пользуется ограниченной учеткой, единственный пользователь он же админ. Хотя UAC включен. Собственно ценности там на винде это только стим аккаунт, но и то стимгуардом защищен. Т.е. вероятность заражения винды минимальна даже с таким вот Insecure Mode?

Пара картинок.
то что у меня сейчас (слил в один файл я думаю понятно)

UEFI. Сделка с Secure Boot

Ptiza_Govorun , по поводу того, как Минт отключил Secure Boot при установке, ничего не могу сказать, я о такой опции даже не знал. В теории он вообще не смог бы загрузиться. Может, ошибаюсь. Проверять пока нет времени.

А по поводу возможности заражения… Я далеко не эксперт в области информационной безопасности, но некоторую ясность попытаюсь внести, исходя из своего опыта.

Прежде всего стоит помнить, что ничто не случается просто так: пользователи сами, пусть и неосознанно, пускают вредоносов в систему. Например, открывают папки, музыку или видео с расширением .exe , которые им знакомый принёс на флешке. Или открывают вложение в письме с названием Отчет за 01.03.2017.vbs . Вредоносы, проникающие в систему с использованием какой-либо уязвимости без участия пользователя — очень редкие случаи, и, как правило, происходят тогда, когда пользователь отключает обновления. Таких почему-то немало и среди моих знакомых.

До сих пор я ни разу не видел вредоносов, которые подменяют загрузчик в UEFI, так как реализовать это при включенном Secure Boot даже с учётом утечки ключа сложновато. Во времена BIOS подменяли загрузочную запись в MBR, и сделать это было довольно просто, хотя толку немного. Так как личные данные для пользователей стоят на первом месте, сейчас чаще всего используют шифровальщики-вымогатели: файлы с определёнными расширениями (текст, документы Microsoft Office, изображения (фотографии) и т. п.) шифруются стойким алгоритмом, и у пользователя вымогают деньги, обещая после выплаты выдать программу для расшифровки. Так как подавляющее большинство пользователей не делает бэкапы, это, пожалуй, самые эффективные вредоносы на сегодняшний день. Таким образом, если где и подменяют загрузчик, то разве что на крупных серверах, встраивая туда rootkit. Обычным пользователям это не грозит, ведь написать руткит не так-то просто, а взять с них всё равно нечего. Заражают саму систему, как правило, для того, чтобы дёшево или вообще бесплатно собрать ботнет для DDoS-атак на крупные ресурсы. Для пользователя в таком случае из последствий лишь излишние нагрузка на процессор и сетевой трафик, но и только.

Другой пример. В Steam долгое время не было приложения-аутентификатора, и Steam Guard работал только через отправку сообщения на почту с кодом подтверждения. Сейчас, к счастью, такую возможность добавили. Но на тот момент, когда произошёл случай, о котором я сейчас расскажу, её не было.
Итак, одному моему знакомому (назовём его Вася) написал незнакомец. Долгое время втирался в доверие и, наконец, предложил вместе сыграть. Вася хотел созвониться по Скайпу, но тот человек отказался, настояв на использовании другой голосовухи. Точно уже не помню, какой, но малоизвестной. Собственно, дал ссылку на сайт и предложил скачать. Вася, ничего не подозревая, так и сделал, потому что сайт выглядел вполне серьёзным. При установке программа запросила права администратора (UAC), что вполне ожидаемо, ведь большая часть программ устанавливается общесистемно. Поэтому Вася дал разрешение. Однако, на деле ничего не установилось, и вскоре Вася заметил, что весь его инвентарь в Стиме бесследно исчез.

Теперь несколько подробнее. Тот незнакомец давно приметил богатый инвентарь Васи, поэтому и решил атаковать именно его. Втирание в доверие — это один из методов социальной инженерии (social engineering). Голосовуха, которую он упомянул, существует на самом деле, и ничего вредоносного в себе не несёт. Но сайт, ссылку на который он дал, был специально подготовлен для этого конкретного случая, и в точности копировал официальный сайт программы (а вскоре стал недоступен). Всё, что отличалось — это домен в другой зоне ( .net вместо .com ) и, собственно, ссылка на загрузку (она вела на Dropbox, чего Вася не заметил). После запуска установщик прочесал профиль браузера, где хранились запомненные пароли Васи в открытом виде. Так, кстати, во всех браузерах было на тот момент. Только Firefox позволял задать мастер-пароль, и тогда пароли в нём шифровались. Как обстоят дела сейчас — не знаю. Так вот, среди этих паролей были пароли от почты (Вася не использовал двухфакторную аутентификацию в Gmail) и Стима ( store.steampowered.com ). Поэтому взломщику легко было войти в Стим даже при включенном Steam Guard. Так он и сделал. Передал весь инвентарь на свой временный аккаунт, а уже с него — на настоящий. Отмечу, что всё это можно было сделать даже без прав администратора. Антивирус при этом молчал.

Последний пример, который упомяну — из недавнего. Почитать о нём можно, например, здесь . Просто чтобы подчеркнуть то, на какие хитрости идут взломщики.

Итог: заражение загрузчика — очень маловероятный сценарий. Лучший способ себя обезопасить — это быть внимательнее и никому не доверять вслепую (даже знакомым, ведь и их могут взломать). Антивирус — не панацея, UAC и ограниченная учётка — тоже. Они лишь уменьшают риск, но не убирают его полностью. Также очень желательно делать бэкапы во избежание потери данных и использовать двухфакторную аутентификацию, чтобы в случае угона пароля злоумышленник всё равно не мог войти в аккаунт.

UPD: чуть дополню. Многое из этого относится и к Линуксу тоже. Пусть даже он гораздо менее популярен, чем Винда, но никто не мешает использовать те же самые приёмы, если злоумышленник осведомлён о том, что целевой пользователь — линуксоид. К тому же, есть вредоносы, написанные так, что работают сразу под несколькими ОС. Так что это тоже не панацея.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Management studio sql mac os
  • Mamp mac os настройка
  • Makemusic finale mac os
  • Mailbox mac os x
  • Mail клиент для mac os