Názory k článku
Nový bezpečnostní problém v Linuxu při použití LUKS
-
-
Hmmm... zajímalo by mě, jestli to v praxi na Fedoře skutečně zkoušeli. Teď jsem si to schválně vyzkoušel a po třech neúspěšných pokusech mě to hodilo do konzole, kde nemůžu dělat prakticky nic. Takže ta chyba tam možná je, ale v praxi s výchozími nastaveními se ta podmínka 30 neúspěšných pokusů podle mé zkušenosti nikdy nesplní.
-
-
klubko (neregistrovaný)
Ahoj.
Chyba tam neni. Povodne najdena chyba je specificka pre Debian. Myslim, ze researcher predpoklada, ze z toho shellu sa zrovna da viac nez "prakticky nic": napriklad nahradit intird trojanom, ktory ukradne heslo k disku, alebo jadro zabackdoorovanou verziou. Ako relevantny je k tomuto Secure Boot necham na posudenie kazdemu; ja neviem.
Kazdopadne, dracut trapne do debug shellu ked sa nepodari primountovat root a neni pritomna optiona rd.shell=0 (default je 1, byt to z dracut.cmdline manualu neni uplne zrejme). Instalator prida rd.shell=0 ked nastavis heslo v bootloaderi.
Cize: ked mas heslo v bootloaderi, tak sa k shellu nedostanes. Ked heslo v bootloaderi nemas, vies sa k shellu dostat pohodlnejsie nez timeoutom v initrd.
Podciarknute & zhrnute: vo Fedore sa nejedna o security problem.
Lubo
-
FíkZlatý podporovatelDobře napsané :)
Ještě mám otázku, jak je to ve Fedoře se šifrovaným /boot? Je to standard? Musí se heslo dávat dvakrát jednou grubu a jednou dracutu?
viz: http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/
-
nobody (neregistrovaný)
sice ne ve Fedore, ale v Xubuntu, ale resil sem stejnej problem ze pri sifrovani celeho disku vcetne boot bylo potreba zadavat 2x heslo (poprve v grub, podruhe v initrd), vyresene to mam tak ze v initrd je navic klic v souboru kterym to pridanej script v initrd pak odemkne automaticky...
viz pro Arch: http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
viz pro *buntu/Mint/Debian(?): http://www.pavelkogan.com/2015/01/25/linux-mint-encryption/ -
nobody (neregistrovaný)
vykousel sem s Xubuntu 14.04.5... po 6tem pokusu do skoci do shellu, ale jak uz bylo psano vedle, neni to o nic "lepsi" shell, nez kdyz bych startoval po pridani "init=/bin/sh rootdelay=1" kdy to tam skoci rovnou, nebo kdyz bych startoval vychozi dostupnou recovery polozku...
na dulezitejsim zarizeni mam ovsem sifrovanej i boot, takze tam ani jedno mozne neni :) -
Mickey (neregistrovaný)
A proto rozumní lidé mají šifrovanou boot partition a bootloader pro jistotu ještě chráněný UEFI Secure Bootem s vlastními klíči.
Je to přitom docela jednoduché, viz projekt: cryptboot
Evil maids pak nemají šanci, pokud rovnou neimplantují hardwarový keylogger nebo nevymění desku ;-) Ovšem tomu se dá vcelku úspěšně bránit fyzickými prostředky.
ČLÁNKY DO MAILU