tl;dr ale vypada to na ne moc velky rozdil meze mit kernel plus ramdisk v pristupnem oddilu a zakladni soubory grubu na pristupnem oddilu.
tady nejaky expert to vylepsil s TPM https://github.com/morbitzer/linux-luks-tpm-boot
fyi, openbsd pac nepouziva ramdisk, tak svuj zavadec upravili tak, ze umi "odemknout" zasifrovany oddil, pac vi, kde presne najde metadata pro crypto softraid a dalsi cast bootloaderu a pak spusti kernel.
Máte pravdu, můj původní postup nefunguje hlavně proto, že je potřeba vyrobit nový grub. Na starém ubuntu 17.04 mi pořád skripty fungují.
Dnešní grub má v některých verzích už potřebné patche zakompilované - o to těžší je dělat úpravy pro konkrétní distribuce.
Asi by to chtělo na to znovu mrknout - já jsem na tom s časem špatně, ale pokusím se odpovědět na e-maily, které mi k tomuto dorazily (byly asi dva).
Už jsem to vyřešil. GRUB z Core Os očividně Vaše patche integruje. Je tam trochu drbání s jeho kompilací, ale nic neřešitelného.
Pak jsem se ještě dost dlouho drbal s tím, že na jednom mém notebooku TPM nefunguje správně když se bootuje přes BIOS, s UEFI ano, ale zase bootuje divně UEFI jako takové (notebook má pouze uváděnou pouze experimentální podporu...)
V celku bych řekl, že to nemám zatím hotové, ale postupně se v tom posouvám. Časem jsem si říkal, že bych o tom někde něco sepsal, nicméně bych Vás ještě v takovém případě rád komtaktoval, přeci jen je to Vaše práce.
Na Solaris a na OpenIndiana OK, ale na linuxu jsem mel se ZFS jen a jen problemy.
Poskozeny filesystem na solaris (vadne bloky atp) nebyl problem opravit,
na linuxu pro ten svazek konecna.
Obdobne poskozeni dat na lunu ze SAN, s cim si Solaris poradil, tam Linux kernel
obvykle vytuhl. Zkouseli jsme menit verze jadra i ZFS, ale rozdil tam je, a podstatny.
Takze ZFS je super, ale na linux mi nesmi, a do produkce ta kombinace obou taky ne.
Já jsem příznivcem klasických a ověřených řešení. Souborový systém je pro mě natolik kritický prvek, že preferuji konzervativní a maximálně spolehlivé řešení. Zrovna před týdnem přišel kolega s Btrfs o data, z neznámého důvodu se mu to celé neopravitelně sesypalo.
Ovšem ať si každý do toho šifrovaného oddílu nasadí cokoliv, ten návod není přímo závislý na LVM ani ext4. Důležité je to šifrování kolem, jestli je uvnitř ZFS nebo Brtfs, je jedno.
@j to platilo u LegacyBIOS, kdy zavadec byl v MBR a mohl byt jen 1, tedy kdyz GRUB, tak ho Windows nahradil za svuj... u UEFI je ale zavadecu mozne libovolne mnozstvi, jde jen o efi binarku na efi oddilu..., takze vedle windows efi binarky je tam grub efi binarka a v BIOSU/SETUPU/UEFI si pro BootPrioritu nevybiras disk ale konkretni EFI binarku z nalezenejch ne EFI oddilu...
Ja akurát teraz riešim problém, že dátové disky sú šifrované celé a nad crypto vrstvou je obyčajná GPT partícia. Pripojenie šifrovanej vrstvy prebehne po štarte ok, ale už neprebehne rozpoznanie partícii nad tým. Ručné spustenie partprobe ich rozpozná, ale rád by som aby to šlo samo.
Jaka narocnost? Kdyz instalujes ubuntu tak proste jen zaskrtnes, ze chces vsechno zasifrovat, ostatni nechas default a docilis skoro stejneho vysledku, akorat holt nebudes mit zasifrovany /boot. Tohle svym zpusobem advanced a bezneho BFU ani nenapadne, ze by neco takoveho vubec mohl chtit.
Aaaano, tak určitě:
https://www.root.cz/clanky/sifrovani-ssd-lze-prolomit-ani-bitlocker-neni-v-bezpeci/
A nejnověji:
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-8566
Výtečné zabezpečení od MS, opět nezklamali!
Tak určitě. Obě chyby jsou naprosto fatální "design error" z dílny MS. Ten blackbox krám věc vůbec nedělá to, co by dělat měl, přičemž uživatel to nemá žádnou možnost zjistit.
1/ Bitlocker vůbec nemá spoléhat na to, že disk něco zašifruje, nikdo se ho o to neprosil (ani to nikomu neráčil sdělit při zapnutí).
2/ Vypnout šifrování při vypínání počítače je opravdu výtečný nápad, svědčící o tom, že návrháři toho "šifrovacího" nástroje asi použili nějaké "mozkové myšlení".
mozna, ale pristup verim nekomu jinemu a verim, ze to dela spravne je to, co uzivatelum Windows zbyva. nemaji zdrojaky, nevi presne, jak technologie delajici sifrovani funguji atp... IMO clovek, ktery sifruje na Windows s defaultni MS nastroji je naivni, stejne naivni je clovek, ktery si mysli, ze data na disku, ktery sifruje v hw, jsou OK.
Nasadit nesifrovanej disk je uplne stene jednoduchy a vysledek je exaktne stejnej jako pozivat bitlocker. Viz https://www.root.cz/clanky/sifrovani-ssd-lze-prolomit-ani-bitlocker-neni-v-bezpeci/
Takhle to mám na notebooku, protože to někdo kdysi asi zrovna tady na rootu doporučil v diskuzi a na první pohled se mi to zdálo jako dobrý nápad. A asi pokud by byl celý grub načítán secure bootem by to mohlo být i bezpečnější, ale tak to nemám.
Tohle má ovšem jedno omezení, kvůli kterému jsem to nedal na stolní počítač v práci. Chci totiž mít možnost udělat z domova WOL na počítač v práci a nabootovat ho vzdáleně. Na to stačí v Debianu doinstalovat dropbear, který je automaticky zahrnut do ramdisku a máte možnost po načtení ramdisku udělat ssh na dropbear ssh-daemona, zadat příkaz cryptsetup-unlock, zadat heslo a systém dokončí boot. Mimochodem, zrovna jsem měl teď chvíli problém v Debianu testing, že systemd nenahodilo po bootu sshd, tak se hodí proklínané AMT :-). Mohl jsem ze serveru na LAN udělat amtterm na ten desktop a po sériové konzoli sshd pořešit.
Prostě začínám být líný tahat notebook na zádech a tak syncuju data mezi notebookem doma a PC v práci a vychutnat si jízdu na kole bez obtěžkání batohem s noťasem ;-). Pravda dneska jsem po pohledu z okna kolo už vzdal. :-D
tak to medium muze byt treba v sejfu a brat ho muzou treba jenom 2 lide ktery budou odemykat system spolu... podobne to v nekterych systemech funguje, tudiz dotaz je validni... pridal bych mozna dotaz jak to rozchodit s klicem na smart karte nebo na usb tokenu (treba yubico)?
Ja to s yubikey udelal jednoduse - heslo k rozsifrovani se zadava z klavesnice. Prvni pulku mam v hlave a naklepu ji osobne, druha pulka je pevne dany string na yubikey, ktery ji odesila do USB jako by byl druha klavesnice.
Zdaleka to z yubikey nepouzije vsechny jeho schopnosti, ale pomer narocnost/bezpeci je pro me potreby solidni.
U hardwarového šifrování bylo v mnoha produktech prokázáno, že obsahuje chyby a je obtížně auditovatelné. Z hlediska uživatele může být velmi lákavé a pohodlné, ale já mu osobně nevěřím.
trochu upresnim...
je to o tom ze GRUB2 umi po zadani hesla uzivatelem LUKS odemknout a nacist s neho zbyle GRUB moduly, GRUB configuraci a po vybrani v menu prislusne jadro a initrd a po inicializaci jadra je LUKS opet zamcen(/zapomenuto_odemknutiu), nasledne tek klic ze sifrovaneho oddilu nenacita GRUB, ale initrd, pokud by tam nebyl klic v souboru (a veci okolo) tak by se initramfs zeptal na LUKS heslo tak jak se to deje pri bezne s LUKS instalaci
Hmm, hezky. Akorat v macOS se to cele da udelat klikem na jedno tlacitko.
https://s22908.pcdn.co/internet-privacy/wp-content/uploads/sites/2/2015/06/filevault1.jpg
Ano, jak již bylo řečeno, MS to má tak odladěné, že šifrování jako by tam nebylo...
Jak řešíte šifrovaný Dual boot? Mám šifrovanou Fedoru i Win a řeším problém s přístupem k datům, viz níže:
Pokud natáhnu Linux, tak nemám problém s přístupem na bitlocker-enabled win oddíly (dislocker-fuse se postará), ale obráceně (z Windows na šifrovaný Linux oddíl) to dost skřípe. Nepřišel jsem na jiné skutečně funkční řešení, než ve Virtualboxu nainstalovat Linux, kterému je předhozena fyzická Linux parition. Tu tento virtuál namountuje a já si ji ve Windows zpřístupním jako další písmeno přes Sambu. Jde to jednodušeji? Díky. :-) Málem bych zapomněl: Linux je zašifrován klasicky přes LUKS a oddíl je ext4.
I na Debianu existuje Dracut (původně z Fedory). Ten lze jedině doporučit pro všechny případy konfigurace disků kromě triviálních; hledání kořenového filesystému je pak spolehlivé a člověk se nemusí zabývat tím, zda má či nemá LVM, kolik různých vrstev do sebe vnoří, jestli je někde potřeba ošklivá Debian-only berlička zvaná "noearly" atd. atp. Implicitní skripty pro práci s filesystémy při bootu a s initramdiskem jsou bohužel v Debianu naprostá bída s nouzí, která vypadá jako z roku 1995. Dost se divím, že tam Dracut nezavedli už dávno jako implicitní volbu.
„Neblabol, getmail je aplikace a jako takovy ji je naprosto lautr hovno do toho, co fs dela nebo nedela a jakej je nebo neni. To je vec systemu.“ https://www.root.cz/zpravicky/dropbox-vydal-novou-verzi-ktera-v-linuxu-vyzaduje-nesifrovany-ext4
Je fajn že už to chápeš ;-)
Tohle je teď problém třeba i u Dropboxu, ale v článku popisovaného případu se to netýká. Tam má software přímo přístup na souborový systém a šifrování je „pod ním“ a aplikace o něm neví. Problém může nastat jen v případě, že jsou vrstvy obráceně – tedy aplikace přistupuje k nějaké šifrovací vrstvě, pod kterou je původní souborový systém. Tady to tak není.
tohle reseni pouzivam uz nejakou dobu take, s *buntu, navic delam i hibridni podporu Legacy a UEFI, v GPT rozzdeleni pridat bios_grub oddil a nainstalovat grub s target i386-pc i x86_64-efi...
pred casem sem radil s postupem nekomu na abclinuxu jak na komplet sifrovanou usb flash s hibridnim bootem, nakonec z toho vzesel skript co dela vse sam (po upraveni zvolenych velikosti disku atd na jeho pocatku), otestovan v *buntu a Mint, pusti se Live Vyzkouset (ne primo instalace), pusti se skript, ten pripravi disk, pusti instalaci bez instalovani zavadece, po dokonceni instalaci script dokonci, doinstaluje zavadec (oba targety), udela hook pro initramfs atd... pro info, je to tady:
https://www.abclinuxu.cz/poradna/linux/show/436429#124
Nemám zkušenosti se šifrováním disků, takže budu asi za vola, ale chtěl bych položit začátečnické dotazy:
1. Nepostřehl jsem v článku místo, kde se nastavuje heslo, které potom při bootování požaduje grub. A co když ho chci později změnit, kde se to udělá?
2. Co když mi zdechne počítač - např. odejde základní deska, a já chci přendat HDD do jiného počítače a přečíst svá data. Dejme tomu, že na tom druhém počítači také běží Debian 9.6, co musím udělat, aby se šifrované partition na HDD připojily?
Děkuji ;-)
PS: Zatím mě moc netrápilo, že by někdo mohl ukrást můj počítač a z něho má data. Více mne trápilo, že když se něco pokazí, tak se ke svým datům nedostanu ani já. A zdá se mi, že šifrování zvyšuje pravděpodobnost toho druhého...
ad 1. v clanku to zminene neni, ale zepta se te instalator v prubehu rozdelovani disku, viz: "Můžeme si disk v průvodci rozdělit podle svého, ale můžeme také použít vestavěnou variantu „asistované rozdělení se šifrováním a LVM“
zmenit muzes pomoci:
sudo cryptsetup luksChangeKey /dev/sdXY (kde sdXY je tvuj sifrovanej(NEodemknutej) oddil)
ad 2. kdyz chcipne deska, muzes HDD v jine desce (pres SATA nebo USB=>SATA redukci) totozne primo nastartovat z nej system (je mu jedno ze pujde o jinej HW (az na vyjimku u closedsource/binarnim Nvidia ovladaci)), nebo kdyz ho budes mit pripojene jako druhej disk, tak jednoduse tuknes na plose na ikonu Sifrovany Disk a zadas heslo do dialogu co na tebe vyzkoci, nasledne se automaticky detekuje LVM a pripoji vsechny jeho LV "oddily" ;-)
+ je moznost opet pomoci cryptsetup:
sudo cryptsetup luksOpen /dev/sdXY sdXY_open
Děkuji za vysvětlení. Nebyl jsem si jistý, jak namontovat ten zašifrovaný HDD jako druhý disk, neboť jsem se domníval, že jeho hlavní partition je zašifrovaná klíčem, uloženým v initramfs, který je také zašifrovaný... Prostě se v tom ztrácím. Musím si to někdy vyzkoušet, abych to pochopil.
Po siti je princip stejnej, pouze keyfile nebude v initramfa, ale pridas to initrd ssh klienta, ssh klic a ten keyfile nejddriv stahnes....
Akorat v takovem pripade, nemuzes mit sifrovanej /boot, kterej odemykas pres grub, tzn ze i ten initrd by byl na nesifrovanej /boot, takze kdokoliv s pristupem fyzickym by ho mohl upravit, tzn mohl by ti szizit jak ten priv ssh klic, tak ten luks klic na serveru, nebo tam pridal dalsi funkce pro nej, jako keyloger atd...
Castecne se to da resit tak, ze do initrd nedas ssh klienta a priv ssh klic, ale ssh server a public ssh klic, pak muzes bud rucne odemknout vzdakene, nebo to automatizovat, ze server bude v intervalu kontrolovat zda ten sifrovanej stroj neceka v initu...
Porad ale plati ze by initrd byl na nesifrovanem boot a nekdo by ho mohl upravit... pouze se timto znemozni ziskani ssh klice..
Aby to nikdo nemohl upravit, musel bys jadro a initrd dat na server a tahat je pres PXE, pak odemknout timto druhym zpusobem
V podstate by to jit melo, Slax je na Debiany zalozen, ale (pokud se to nezmenilo) pouziva syslinux zavadec, muael bys tedy nahradit za Grub2, pak si nejsem jist initramfs, jednak zda nema odebranou podporu pro luks a pak zda se s update-initramfs da regenerovan, v nejhorsim by to byli proste vice rucni prace s upravou...
Asi unikla část článku začínající
Poté nám instalátor vyhubuje, že se mu nepodařilo v takové konfiguraci nainstalovat Grub a váš systém nebude bootovat. Nevadí, je čas na ruční práci. Přepneme se pomocí Alt-F2 do druhé konzole a připravíme si zbytek.
a končící
To je vše, teď se pomocí Alt+F1 vrátíme na instalační terminál a dokončíme instalaci přesně od místa, kde předtím skončila. Instalátor už nebude křičet, že zavaděč není na svém místě, protože jsme mu ho tam dali. Proběhne pár poinstalačních kroků a systém je připraven rebootovat.
:-P
to Lol Phirae:
díky za odpověď, ale asi jsme se nepochopili nebo je špatně obrázek v článku. V článku je napsáno, že odebereme oddíl /boot ... a v další kapitole se: Přepneme do čerstvě nainstalovaného systému .....
Můj problém spočívá v tom, že bez /boot mi instalátor nedovolí dokončit ani rozdělení disku, natož pak něco instalovat. Navíc, Grub se instaluje až po instalaci systému, téměř na konci celého instalačního procesu a z tohoto kroku by měl být obrázek s červeným pozadím. Takže ještě jednou: Jak obejdu instalátor abych nemusel mít na disku samostatný nešifrovaný /boot a mohl dokončit rozdělení disku a pokračovat v instalaci? Děkuji.