Част от притеснението, че искате ядрото да се справи със защитеното зареждане на ниско ниво, е, че ключовете на Microsoft могат да бъдат използвани за хакване на системата и ако това се случи, те се страхуват, че Microsoft ще деактивира ключа и следователно Linux компютри. стартирайте с този ключ (и никой не иска това).
Всичко започна с искане за изтегляне от Дейвид Хауелс, което позволи на двоичните ключове, подписани от Microsoft, да се зареждат динамично в ядрото, работещо в режим на защитено зареждане. Този с одеялото смяташе, че е глупост и че би било по-добре да подобри парсера X.509. Матю Гарет отговаря, че има само един орган за подписване и че те подписват само PE двоични файлове (преносими изпълними файлове). И тук Линус пуска острия си език и казва:
Момчета, това не е конкурс за смучене на петел. Ако искате да анализирате PE двоични файлове, продължете. Ако Red Hat иска да ви попита garganta profunda за Microsoft, това е * вашият * проблем. Няма нищо общо с ядрото, което поддържам. За вас е тривиално да имате машина за подписване, която анализира двоичния файл PE, проверява подписите и подписва получените ключове със собствен ключ. Те вече са написали кода, боже, той е в този проклет ред. Защо трябва да ми пука? Защо на ядрото трябва да му пука като "подписваме само PE двоични файлове"? Ние поддържаме X.509, което е стандарт за подписване. Направете го от страна на потребителя на надеждна машина. Няма извинение да го направите в ядрото.
Матю отговаря:
Продавачите искат да носят ключове, подписани от доверено трето лице. Сега единственият, който измерва, е Microsoft, защото очевидно единственото нещо, което продавачите обичат повече от скапания фърмуер, е да спазва спецификациите на Microsoft. Еквивалентът не е просто Red Hat (или каквото и да е) да преподписва тези ключове програмно, той преподписва тези ключове с доверен ключ от ядрото нагоре по веригата. Бихте ли искали да носите надежден ключ по подразбиране, ако член на довереното общество е домакин на услуга за повторно подписване? Или предполагаме, че всеки, който иска да стартира външни модули, е идиот и заслужава да бъде нещастен?
Линус отговаря, че се съмнява, че някой го е грижа. Че вече е глупаво да подписвате модули на ядрото с ключ на Microsoft. Плюс Red Hat ЩЕ подпише двоичните модули NVIDIA и AMD. Питър Джоунс казва не, че Red Hat няма да подпише нито един модул, построен от друг. Гарет добавя, че RHEL в крайна сметка ще разчита на ключовете от NVIDIA и AMD и че е много вероятно те да се базират на услугата за подписване на Microsoft.
И тук правя пауза и обобщавам частично и брутално за тези, които не искат да навлизат в технически подробности:
Цялото развитие около сигурното зареждане е полудяло, но тъй като производителите на хардуер (най-малкото най-големият) все още искат да погълнат Microsoft.
Затова Линус реши да направи следните предложения, така че те престават да се чукат ...
Прекъснете го с плашещи действия.
Това е, което бих предложил и на което се основава ИСТИНСКА БЕЗОПАСНОСТ и ПОСТАВЕТЕ ПЪРВО ПОТРЕБИТЕЛЯ вместо подхода му „нека се отдадем на Microsoft, като правим глупости“.
Така че, вместо да харесаме Microsoft, нека се опитаме да видим как наистина можем да добавим сигурност:
- дистрибуторът трябва да подписва свои собствени модули И НИЩО ПОВЕЧЕ по подразбиране. И не бива да позволява на който и да е друг модул да се зарежда по подразбиране, защото защо, по дяволите? И какво, по дяволите, има дадена фирма на Microsoft с нещо друго?
- преди да заредите други модули на трети страни, уверете се попитайте потребителя за разрешение. На конзолата. Без използване на ключове. Нищо от това. Ключовете ще бъдат компрометирани. Опитайте се да ограничите щетите, но по-важното е да оставите потребителя да има контрол.
- Анимирайте неща като произволни ключове на хост - с глупави UEFI проверки деактивирани, ако е необходимо. Те почти определено ще бъдат по-сигурни, така че разчитат на някакъв луд корен на доверие, основан на голяма компания, като органите за подписване се доверяват на всеки с кредитна карта. Опитайте се да научите тези неща на хората. Насърчавайте хората да правят свои собствени (произволни) ключове и да ги добавят към своите настройки на UEFI (или не: всичко за UEFI е по-скоро за контрол, отколкото за сигурност) и се стремете да правите неща като еднократно подписване с изхвърлен частен ключ. С други думи, опитайте да анимирате този вид сигурност като „ние задължително питаме потребителя изрично с големи предупреждения и създаваме свой собствен ключ за този конкретен модул“. Истинска сигурност, а не сигурност "ние контролираме потребителя."
Разбира се, потребителите също ще я прецакат. Те ще искат да заредят двоични модули на NVIDIA и всички тези глупости. Но нека бъде SU решение и под SU контрол, вместо да казва на света как това трябва да бъде благословено от Microsoft.
Защото тук не трябва да става дума за благословии на МС, а за потребителят благославя модулите на ядрото.
Честно казано, вие сте това, от което се страхуват лудите анти-ключови хора. Продавате шит "контрол, а не сигурност". Всичко "MS притежава вашата машина" е просто грешен начин за използване на пароли.
Оттам нататък нишката се успокои ... и не си струва да се следва.
Приятели на DesdeLinux. Днес празнувам първата си годишнина като писател в Linux блог, въпреки че не съм дебютирал като такъв тук, а в блога на Frannoe, който тогава се нарича Ubuntu Cosillas и който днес е LMDE Cosillas. И там беше на 2 март, когато написах първата глава от тази сага за фърмуера, която след това продължих тук. Бих искал да благодаря на всички, които ме четат и ме четат, особено на Frannoe и целия персонал на Desdelinux, че ми направиха място. Ако не бях направил курса за усъвършенствано функционално програмиране и колега, който ми предложи да използвам linux за работа с ghc, със сигурност щях да импортирам 3 краставици изцяло linux.
Ще завърша с това изречение: „Ако не извикате невежеството си, никой няма да излезе да ви поправи и следователно ще сте прави, като грешите“
Съответни публикации от списъка на пощата на ядрото:
https://lkml.org/lkml/2013/2/21/196
https://lkml.org/lkml/2013/2/21/228
https://lkml.org/lkml/2013/2/21/275
https://lkml.org/lkml/2013/2/25/487