| 1.4, Аноним (4), 12:48, 08/04/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Единственный дистр где поддержка Secure Boot действительно оправдана.
| | |
| |
| 2.9, gogo (?), 13:23, 08/04/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Все было бы идеально, вот только их ключи для secure boot в мамки не завезли...
Так что это глумление, если загрузчик "секюрной" ОС подписан чужими ключами.
| | |
| |
| 3.12, Вася (??), 14:15, 08/04/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Вообще то во всех нормальных серверных и десктопных системах есть custom enroll своих ключей, подписал загрузчик утилитой mokutil и воткнул свои ключи в db, а все другие убрал.
Просто так и скажите "лень вникать и разбираться"
Что может быть плохого в валидации чексуммы загружаемых на ранних стадиях bin-блобах? Это только плюс. Хотя и не гарантия, что вы не цепанете в онлайне эксплойт который исполнит malware прошивку, для этого надо посложнее заморочиться (во первых есть модуль ядра от поляков который делает превентивную эвристическую защиту от всех известных в общем плане подходов к arbitrary code и обрубает их, ну или вот решение недавние от ms для Линукс или его альтернативы.
В хромось это реализовано из коробки
| | |
|
|
| |
| 2.13, Вася (??), 14:19, 08/04/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Да что там арч! Clear блять Linux за N лет до сих пор не поддерживает Secure Boot из коробки... Это чтоб вы понимали это Linux от Intel созданный под флагом "secure by design" и не поддерживающий секьюре технологию придуманную в Intel... мир сошел с ума (с)
| | |
| |
| 3.15, Аноним (15), 15:04, 08/04/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Пора бы уже осознать, что Clear Linux -- это пет проект по фану, единственная цель его существования -- унижать конкурирующие компиляторы в попугаеметрах. По-моему, он никогда и не позиционировался как дистрибутив для пользователей. Может там с alpine поконкурирует ещё.
| | |
|
|
| 1.7, Аноним (6), 13:04, 08/04/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Дело не в одном secureboot.
Загрузка должна быть полностью верифицирована. Включая не только первый этап - загрузчик. А также ядро, init, ВСЕ программы, библиотеки, настройки.
| | |
| |
| |
| 3.18, Аноним (18), 08:15, 09/04/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Так же не допустима загрузка без онлайн проверки самого верификатора
Это шутка? Несмешно. Хочешь чтобы тебя все майоры *рочили еще во время загрузки?
| | |
| |
| 4.24, Аноним (24), 12:39, 09/04/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Вы что все обкурились?
Какая проверка через интернет сертификатов используемых в Integrity?
Вас Бил Гейц с товарищем майором всех покусали?
| | |
| 4.25, Аноним (25), 09:56, 11/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Так же не допустима загрузка без онлайн проверки самого верификатора
> Через https и Летсенкрипт
В системе Integrity каждый админ должен для своей сети/компа лично выступать удостоверяющим центром! ЛИЧНО выпустить СВОЙ корневой сертификат CA для подписи других СВОИХ сертификатов используемых в Integrity.
Публичная часть этого корневого сертификата CA грузится в CONFIG_SYSTEM_TRUSTED_KEYS="путь"
и этим сертификатом удостоверяюца другие, созданные исключительно вами, сертификаты для проверки Integrity, публичная часть которого подгружается например в CONFIG_EVM_X509_PATH="путь". Поддержку других сертификатов в ядре можно отключить, как и возможность добавления новых. Все эти сертификаты ядерные и способны подписывать даже модули ядра.
Приватной части сертификатов ядра Linux в рабочей системе физически быть не должно в любом виде!
Доверять чужомым сертификатам для системы Integrity нельзя. Даже если это фирма с непорочной репутацией как M$. Админа который в подсистему Integrity добавляет чужой, не созданный им самим, сертификат можно уволить как не соответствующего к требованиям занимаемой должности!!!
| | |
|
|
| |
| 3.23, Аноним (24), 12:35, 09/04/2020 [^] [^^] [^^^] [ответить]
| +/– | |
https://www.opennet.dev/openforum/vsluhforumID3/120270.html#135
Использую Integrity очень давно, в том числе при доступе. У меня проблем в юзерспейсе не было и нет!
Какие, конкретно ты, проблемы испытуешь при верификации всего начиная с init? Здесь даже внедрение systemd не должно стать помехой, хоть я его и не использую.
Проблем нет:
1. Создал пару секретный/публичный ключ.
2. Публичный подгрузил в ядро.
3. Секретным подписал хеши, атрибуты и далеко упрятал.
4. При загрузке в параметры ядру передал проверять. Все!!!
Даже сам Потеринг в этой цепочке не способен что-то испортить. За дело взялся M$...
| | |
|
|
|
