abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 04:11 | Nová verze

    Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 1
    včera 22:22 | Bezpečnostní upozornění

    Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].

    Ladislav Hagara | Komentářů: 4
    včera 21:11 | Zajímavý článek

    V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.

    Ladislav Hagara | Komentářů: 12
    včera 14:33 | Pozvánky

    O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.

    Ladislav Hagara | Komentářů: 0
    8.5. 21:55 | Nová verze

    Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.

    Ladislav Hagara | Komentářů: 27
    8.5. 20:22 | IT novinky

    Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.

    Ladislav Hagara | Komentářů: 6
    8.5. 12:55 | Nová verze

    Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.

    JZD | Komentářů: 1
    7.5. 18:55 | IT novinky

    Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).

    Ladislav Hagara | Komentářů: 10
    7.5. 18:33 | IT novinky

    Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.

    Ladislav Hagara | Komentářů: 4
    7.5. 17:11 | Nová verze

    Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.

    Ladislav Hagara | Komentářů: 0
    Podle hypotézy Mrtvý Internet mj. tvoří většinu online interakcí boti.
     (63%)
     (8%)
     (13%)
     (16%)
    Celkem 148 hlasů
     Komentářů: 10, poslední 8.5. 17:35
    Rozcestník

    Dotaz: arch sifrovany

    5.4.2019 16:06 tom
    arch sifrovany
    Přečteno: 640×
    Příloha:
    Dobry den,

    Snazim sa z ucebnych dovodov nainstalovat vo virtualboxe plne sifrovany Arch vratane /boot.Postupoval som podla nasledujuceho navodu >

    https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#fn:1

    Skusal som aj ine postupy, no po reboote sa zaseknem v grub-rescue.

    Neviete poradit ako to vyriesit?Asi to bude nejaka drobnost, ale neviem si rady.

    Dakujem

    Odpovědi

    5.4.2019 17:58 Peter Golis | skóre: 64 | blog: Bežné záležitosti | Bratislava
    Rozbalit Rozbalit vše Re: arch sifrovany
    A dal si načítať tie dva moduly teda?
    Jendа avatar 5.4.2019 19:34 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: arch sifrovany
    grub-install spouštět s -v, podívat se, jaké moduly požaduje po grub-mkimage.
    k3dAR avatar 5.4.2019 23:30 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    sice slo o Debian10, ale mozne ten problem nove verze Grubu mas i v Archu, zkoukni tohle, pripadne zkus zda to odemknes z Grub Rescue rucne...
    jinak howto od Pavel Kogan povazuju za spravne, opet sem sice pouzil jen jeho novejsi zapisek pro *buntu/Mint, ale aspon o sem videl tak jine navody (i pro Arch(vcetne ArchWiki)) z jeho zapisku (=tvuj link) vychazeji... jedine nejake ty zmeny novych verzi (napr. ten Grub)
    porad nemam telo, ale uz mam hlavu... nobody
    7.4.2019 05:08 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: arch sifrovany

    Co takhle podívat se do howto speciálně pro Arch? Nějaká stránka z roku 2014 nemusí vůbec odpovídat dnešní realitě.

    Máš tam nainstalované potřebné moduly? Nezapomněl jsi na GRUB_ENABLE_CRYPTODISK=y v /etc/default/grub nebo něco takového? Generuješ /boot/(efi/)?grub/grub.cfg automaticky, nebo se ho snažíš nějak sesmolit ručně?

    Na všech mých strojích se GRUB k šifrovanému filesystému dostává přibližně takto:
    insmod part_gpt
    insmod cryptodisk
    insmod luks
    insmod gcry_rijndael
    insmod gcry_rijndael
    insmod gcry_sha256
    insmod btrfs
    cryptomount -u <magické číslo>
    set root='cryptouuid/<magické číslo>'
    

    To magické číslo je UUID příslušného LUKS oddílu, zapsané bez pomlček. Je to totéž UUID, které máš například v /etc/crypttab pro ten oddíl. Nebo se dá zjistit pomocí blkid, lsblk -f a podobných příkazů.

    Ale bacha, je tam pár nepříjemností, se kterými musíš počítat:

    • GRUB zatím nepodporuje LUKS2. Aby to fungovalo, musí to být původní LUKS. To není žádný zásadní problém a původní LUKS bude ještě dlouho podporovaný. Jenom je potřeba o tom vědět a nesnažit se v cryptsetup luksFormat o nějaké super hyper moderní nastavení. LUKS2 je bezva, řeší spoustu nedostatků původního LUKS, ale prostě teď v tuhle chvíli ho GRUB ještě nedovede číst.
    • Pozor na --iter-time! To je parametr cryptsetup, který se zadává u luksFormat a luksAddKey. Nechce se mi zacházet do podrobností, co dělá, takže stručně: Delší --iter-time znamená lepší zabezpečení v případě slabého hesla, ale odpovídajícím způsobem delší dobu pro dešifrování master klíče. Proč to u GRUBu vadí a jinde ne? Protože GRUB nepoužívá hardwarovou akceleraci šifrování (AES-NI). Takže něco, co se později v userspace spočítá třeba za sekundu, může v GRUBu trvat třeba 10 sekund. A GRUB má pevně stanovený timeout pro odemčení LUKS slotu, který je kolem 10–15 sekund nebo tak. Takže na běžném slabém notebookovém procesoru (a ve virtualizaci také!) se může klidně stát, že GRUB nestihne vypočítat master klíč do vypršení té své interní lhůty a prostě to vzdá.
      • Co s tím? Nepoužívat --iter-time 2000, který je momentálně implicitní, ale zkusit třeba starší implicitní volbu 500. Se silným heslem nebo s náhodným dlouhým klíčem v souboru to nemá absolutně žádný vliv na bezpečnost. Se slabým heslem je to samozřejmě jiná věc.
      • Jak změnit --iter-time u již existujícího LUKS oddílu? To lze pomocí luksAddKey, luksKillSlot a luksDump (pro výpis seznamu slotů). Pozor, doba potřebná pro dešifrování master klíče disku se řídí podle slotu s nejdelším --iter-time. Takže --iter-time je třeba zkrátit všude; jinými slovy, je třeba napřed přidat pomocí luksAddKey sloty s kratším --iter-time (a se stejnými hesly nebo klíči, které už tam jednou jsou) a poté pomocí luksKillSlot odstranit původní sloty s delším --iter-time. Jinak se GRUB toho master klíče nedobere včas.
    k3dAR avatar 7.4.2019 11:06 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    Jak sem psal, z tveho linku:
    Instructions at Pavel Kogan's blog show how to encrypt the /boot partition while keeping it on the main LUKS partition when using GRUB
    Postup na ArchWiki vidim totoznej, jen klic v /root a Kogan v / s tim ze mu nastavuje 000, a jeste vidim druhej rozdil ze v mkinitcpio.conf ma ArchWiki cestu v zavorce...
    porad nemam telo, ale uz mam hlavu... nobody
    7.4.2019 13:19 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: arch sifrovany

    Závorka podle mě nehraje roli. Je to Bash a ten skript, který to celé interpretuje, je uzpůsobený tak, že se dají používat jak pole, tak i tokeny ve stringu. Konkrétně je tam toto (tedy všechno nakonec skončí jako pole):

    arrayize_config() {
        set -f
        [[ ${MODULES@a} != *a* ]] && MODULES=($MODULES)
        [[ ${BINARIES@a} != *a* ]] && BINARIES=($BINARIES)
        [[ ${FILES@a} != *a* ]] && FILES=($FILES)
        [[ ${HOOKS@a} != *a* ]] && HOOKS=($HOOKS)
        [[ ${COMPRESSION_OPTIONS@a} != *a* ]] && COMPRESSION_OPTIONS=($COMPRESSION_OPTIONS)
        set +f
    }
    

    Jinak ta zmínka o /boot partition je silně zavádějící; nemá žádný smysl mít oddělený /boot oddíl a na svých strojích nic takového nemám. K takovému dělení není důvod a ušetří to navíc obrovskou spoustu vrásek třeba v situaci, kdy se chrootnu do kořenového oddílu, chci tam něco poupravit — třeba po změně typu virtualizačního kontejneru nebo tak — a zapomenu namountovat ten /boot, protože jsem zvyklý na x-systemd.automount, který v chrootu nenastane. Inu, bez odděleného /boot oddílu celý tento nesmysl odpadá a bootuje se z běžného "hlavního" filesystému.

    7.4.2019 17:20 tom
    Rozbalit Rozbalit vše Re: arch sifrovany
    Dakujem pani,

    Na Wiki stranke sa pise,ze je podporovany len LUKS1-teda stary.Luks2 este nie je podporovany.Skusil som pri vytvarani particie zadat --type luks1 a znovu nainstaloval.A zda sa,ze to ide, musim sice 2x zadavat heslo, ale to nevadi.Este si instalaciu zopakujem aspon 2x aspon aby som sa lepsie zorientoval. Este raz dakujem.
    k3dAR avatar 7.4.2019 18:00 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    spis si jeste 2x precti ten tvuj link, protoze tam samozrejme resi i to aby jsi zadaval heslo jen 1x do Grubu...
    to ze ho zadavas 2x je to ze system uz nevi, ze jsi to predtim odemknul (resp. natazene jadro uz to odemcene zas nema), a druhe zadavani LUKS hesla je do initramdisku, to se prave obejte tim, ze pripravis keyfile, pridas ho do LUKS slotu jako dalsi "klic" a nastavis aby initramdisk timto keyfilem odemykal automaticky... celej postup tam je, bud si vynechal celou cast o keyfile, nebo treba jen jednu vec z ni a proto to po tobe chce to druhe heslo ;-)
    porad nemam telo, ale uz mam hlavu... nobody
    7.4.2019 18:43 tom
    Rozbalit Rozbalit vše Re: arch sifrovany
    Ja viem, cital som to dokonca.S tym klucom to skusim neskor.Teraz mi islo hlavne o to sifrovanie. Este raz dakujem, ak budu problemy ozvem sa.
    7.4.2019 19:08 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: arch sifrovany

    S heslem není žádný velký problém. LUKS kontejner má (jestli se nepletu) nějakých 8 slotů a v každém může být heslo nebo klíč. Aby se heslo zadávalo jenom jednou, stačí využít 2 sloty a princip je tento:

    1. Vytvoří se dva sloty, jeden s heslem (při vytváření LUKS oddílu), druhý s klíčem ze souboru (pomocí luksAddKey).
    2. Soubor s klíčem se uloží někam do adresáře /root nebo zkrátka tam, kam běžní uživatelé příliš nemůžou.
    3. Do /etc/crypttab se přidá záznam, který odemyká příslušný LUKS oddíl pomocí toho souboru s klíčem, tedy bez nutnosti interakce s uživatelem.
    4. Soubor s klíčem se přidá do initcpio (a pochopitelně skončí ve stejném adresáři, v jakém je na běžném filesystému).
    5. Pak stačí zkontrolovat, jestli soubor s klíčem i /etc/crypttab jsou v initcpio archivu a jestli náhodou initcpio archiv není čitelný pro někoho jiného než roota.
    6. A nezapomenout přidat sd-encrypt do pole HOOKS v /etc/mkinitcpio.conf; typy a pořadí hooků jsou popsané zde. Právě tento hook zajišťuje přidání programu cryptsetup a souboru /etc/crypttab. Soubor s klíčem je třeba přidat ručně v poli FILES.

    Bootování funguje takto:

    1. GRUB se zeptá uživatele na heslo.
    2. GRUB z šifrovaného hlavního oddílu rozluští master klíč, pak dešifruje a načte kernel a jeho initcpio.
    3. Kernel začne bootovat se svým initcpio filesystémem v RAM, kde najde /etc/crypttab a také soubor s klíčem.
    4. Během initcpio fáze se hook sd-encrypt postará — na základě souboru s klíčem a /etc/crypttab, které jsou v initcpio dostupné — o regulérní otevření LUKS oddílu kernelem, aby se objevil v /dev/mapper/<zařyzeňy>.
    5. Kernel (resp. systemd v tom initramdisku) je pak schopen podle UUID filesystému (které je už známé, protože LUKS kontejner je otevřený a filesystém v něm je vidět) namountovat kořenový filesystém, přemountovat z initcpio na běžný filesystém a je vyhráno.

    Není to žádná věda; jen je třeba mít jasno v tom, co se tam děje a kde a proč.

    7.4.2019 23:15 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: arch sifrovany
    No, nejsem si jistý, jak to s použitím záznamu v /etc/crypttab je. V Archu píší, že se crypttab čte až systém nabootuje (druhý odstavec). A v tvém odkazu na Arch hned následující část popisuje, že klíč dáš do konfigurace mkinitcpio a do příkazové řádky grubu. Já mám v /etc/cryptab pouze další disky ne root oddíl.
    8.4.2019 01:58 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: arch sifrovany

    Klíč v příkazové řádce GRUBu nemám.

    Tady jsou detaily o crypttab.

    26.5.2019 22:18 tom
    Rozbalit Rozbalit vše Re: arch sifrovany
    Dobry vecer,

    Rad by som si nainstaloval sifrovane niekolko distribucii.Chcem sa spytat,ci je mozne zdielanie swap particie medzi niekolkymi linuxami. Cital som,ze by to mohlo sposobit chaos,ak by bol jeden linux hibernovany a zaroven by nabehol iny,druhy linux?

    Za odpovede dakujem.
    k3dAR avatar 26.5.2019 23:39 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    nezavisle na sifrovani, sdilet swap mezi distribucema POKUD je chces hibernovat je urcite blbost, ani me to nikdy nenapadlo zkouset, tak nevim zda by system poznal ze to neni jeho hibernace a smazal ji, nebo zda by se pokousel o obnovu coz by zkolobavalo...
    pokud bys nechtel hibernovat, tak "sdilet" swap neni problem...
    porad nemam telo, ale uz mam hlavu... nobody
    27.5.2019 06:28 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: arch sifrovany
    Chcem sa spytat,ci je mozne zdielanie swap particie medzi niekolkymi linuxami.

    Toto jsou dva nesmysly v jednom.

    1. Máme rok 2019. Swap je soubor, ne oddíl. Oddíl to byl v minulém desetiletí, když ještě většina souborových systémů neuměla swapovací soubory. Nevýhoda oddílu je, nepříliš překvapivě, že místo je vyčleněné předem a nedá se využít k jiným účelům, když se swap nepoužívá.
    2. Swap určený k původnímu účelu (tedy k jinému než uspávání počítače) je úplně passé a zbytečný. Pokud máš pocit, že potřebuješ swap, kup si místo toho víc RAM. Pokud máš stále pocit, že potřegbuješ swap, asi něco děláš špatně. Jasně, můžeš mít pro každou distribuci oddělený swapovací soubor, což prináší spoustu flexibility, ale já osobně bych si na jednom filesystému netrofl uspat jednu distribuci a pak ze swapovacího souboru probutit jinou. Jako jo, třeba by to fungovalo, čistě zázrakem, ale zkoušet bych to nechtěl. Nemá to smysl.
    k3dAR avatar 27.5.2019 06:59 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    ad 1. v jeho pripade by to znamenalo ze pro kazdy system bude mit zvlast swapfile, tedy kazdy oddil pro kazdy system bude muset byt pripraven vetsi o pripadnou velikost swapfile (osobne bych si netroufl mit vice systemu na jednom btrfs oddilu)

    ad 2. nevim jak swapfile (nepouzivam a mel sem za to ze nelze(tedy asi se to zmenilo) pouzit pro uspani-na-disk), ale s swap oddilama nevim proc by mel byt problem uspat system1 do swap1 a probudit uspanej system2 z swap2... jedine teoreticke problemy co me napadaji by teoreticky stejne tak nastaly kdyz by byl uspanej jen 1 system a na oddil(y) pouzivane tim systemem by se vlezlo napr. z USBLive... tedy ze by byl uspan proces co zapisuje(/stahuje) na disk dlouhej soubor a ja(nebo nejaka aplikace) mu z jineho systemu ten soubor smazal
    porad nemam telo, ale uz mam hlavu... nobody
    27.5.2019 16:13 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: arch sifrovany
    Andreji, jen otázka jak to vlastně myslíš. Souhlas s tebou, že na systém patří btrfs, ale na druhou stranu btrfs nemá rádo swap. A také velikost swapu při současných kapacitách medií není tak kritická abych ji nealokoval celou. A také v oddíle mě nikdy nenastane fragmentace (ale souhlas u SSD a NVMe je to jedno).
    k3dAR avatar 27.5.2019 19:16 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    Andrej zije v jinem HW svete, pro jeho 512GB RAM by na 2TB systemovem disku zbytecne zabral 25%... netusi ze normalni clovek ma 8-16GB RAM a vyhrazenej oddil na 256-512GB SSD neni zadnej problem ;-)
    porad nemam telo, ale uz mam hlavu... nobody
    27.5.2019 16:10 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: arch sifrovany
    No myslím, že by sis měl rozvážit, co vlastně chceš. Připomínky k téhle myšlence:
    1. Je naprostá pitomost sdílet cokoliv, swap, systémové oddíly, datové oddíly, pokud jeden ze sdílených systému je hibernován. Sdílený swap je totálka, protože v při hibernaci v něm je obraz operační paměti a pokud se do něj zasáhne hibernovaný systém to z největší pravděpodobností nenajede. Diskové systémy taková hrůza není, protože s pomocí journalovacích FS se z nekonzistentního stavu obvykle dostanou, ale někdy něco nemusí vyjít. Při vypnutí systému dostaneš vše na discích do konzistentního stavu.
    2. Swap:
      • je naprosto zbytečný na rotačních discích. Jejich rychlost a seek time jsou při současné kapacitě pamětí nedostatečné. (čistě pro porovnání. V roce 95 pamět u pracovních stanic cca 64MB (u normál PC 2MB) a rychlost SCSI rozhraní a disků cca 10-20MB/s, tedy přenos paměti na disk za cca 4-8sec max, nyní 8GB paměti do rotačního disku při rychlosti 150MB/s dostaneme tak za minutu, nemluvě o tom, že mnoho lidí má mnohem více operační paměti.)
      • V zásadě použití může mít swap na NVMe.
      • Swap na hibernaci může mít smysl na notebooku, ale při současných spotřebách myslím, že zcela stačí uspání do RAM, notebook v uspání do ram spotřebuje tak cca 7-8% baterie za den a mezitím se ke zdroji uživatel dostane.
    3. Hrát si s mnoha distribucemi v šifrovaném režimu považuji za zbytečné a spíše škodlivé. Vzhledem k otázkám máš znalostní deficit a v šifrovaném režimu můžeš více věci pokazit. Pokud potřebuješ distribuční turistiku, tak ji udělat na běžné instalaci a pokud navíc mám i nějaké obavy o data, tak třeba zašifrovat /home, nemít swap a /tmp mít v tmpfs na dobu, než se rozhodneš pro distribuci. A po rozhodnutí pro distribuci udělat solidní trvalou instalaci s šifrováním všeho, co potřebuješ. A vždy platí první bezpečnostní zásada: Definovat proti čemu obranu buduji.
    27.5.2019 18:29 tom
    Rozbalit Rozbalit vše Re: arch sifrovany
    Ahoj,

    Suhlasim, ze sa v tomto moc neorientujem.Len si potvrdil, co som sa docital.Teda,ze je zdielanie jednej swap particie hlupost. Samozrejme si dam poradit. Na jednom PC mam devuan a tam je swapfile, to ma za nasledok, ze uspanie funguje, no hibernacia nie. Ja som videl nejaku prezentaciu p. Celetku a tam bol slide, v ktorom mal rozlozenie asi taketo> Jeden LUKS oddiel a tom niekolko roznych distribucii
    k3dAR avatar 27.5.2019 23:46 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    sdilet swap pro hibernace je nemozne, ale sdilat swap kdyz bys nehibernoval lze...

    nezkousel sem, ale tady mas postup pro Debian jak zprovoznit hibernaci s swapfile a to i vcetne toho kdyz je ulozen na sifrovanem oddilu

    zalezi na tobe, muzed mit GPT rozdelenej disk kde (krome EFI oddilu a/nebo GRUBLegacy oddilu) budes mit oddil nad kterym bude LUKS, nad nim LVM, v nem lv pro system1, home1, swap1, pak pro system2, home2, swap2 atd.., nevyhoda je ze jakmile ten LUKS odemknes, z tech systemu bude root pristup do vsech ostatnich systemu a/nebo kdyz bys neco s LUKS podelal, ze se nedostanes k zadnemu systemu...
    nebo muzes mit oddil LUKS1 (na nem LVM a lv system1, home1, swap1), dalsi oddil s LUKS2 (na nem LVM a lv system2, home2, swap2) atd, vyhoda je opak tech predchozich nevyhod, nevyhoda neni zadna, tedy pokud pouzijes GPT rozdeleni, pokud bys chtel (neni duvod ani pro BIOS/Legacy boot) mit MBR/MSDOS rozdeleni, tak bys tam byl omezen poctem moznych oddilu...
    porad nemam telo, ale uz mam hlavu... nobody
    k3dAR avatar 27.5.2019 19:13 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    ad 1.) sdilet systemove oddily mezi systemama? to by melo jakej vyznam? ze kdyz budu chtit SystemA tak ho budu startovat z OddiluB? :-) sdilet datovej oddil nevim co by bylo za problem, viz

    ad 2.) swap na rotacnim disku pro hibernaci neni problem, kdyz by mel tazatel rotacni disk a chtel swap i na odswapovani, pokud by tim nechtel "rozsirit RAM", ale chtel to jako zachranu aby system nezabil procesy kdyz by z nejakeho duvodu dosla RAM ma stale vyznam, sice se pri odswapovani na chvili zasekne, ale pak ma moznost sam zvolit ktere aplikace zavre a neprijit o ty co potrebuje bezet...
    (samozrejme nepopiram ze SSD pri dnesnich cenach neni problem poridit (SATAIII 500GB za ~1600))
    problem s uspanim do ram je ze LUKS zustava odemcenej, lze to sice obejit ale neni to podporovana vec distrem a nevim zda muzou pri tom (odpojovani rootfs, zamceni luks, prepnuti na rootfs z initramfs pred uspanim) nastat zbytecne problemy, pri uspani na disk (do sifrovaneho swapu) je to bezproblemove...

    ad 3.) vice sifrovanych dister neni zbytecne - pokud chce vsechny zkouset/pouzivat, budou ve vsech nejaka osobni data tak proc je nesifrovat vsechny? ani skodlive - pokud by byla obava ze neco podela, neni problem mit pro kazde distro 1 oddil a zvlast LUKS na kazdem, takze nemuze jeden "rozbitej LUKS" ovlivnit dalsi distra...
    porad nemam telo, ale uz mam hlavu... nobody
    27.5.2019 22:50 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: arch sifrovany
    Ad 1 ze systému by mohl mít sdílené /etc. A problém s datovým oddílem muže nastat ve chvili kdy má hibernováno a jiný systém s datovým oddílem pracuje. Ad 2. pak jsi to zdůvodnil, že při současných cenách SSD mít cokoliv s brutálním random přístupem na rotačním disku blbost. Ano souhlasím že cold boot attack se na uspaný komp provést dá. Ad 3. Ty vážně si myslíš, že více dister provozovat na jednom hw způsobem tím způsobem, že si s nimi uživatel hraje má smysl šifrovat? Ano pokud šifrování je součásti zkoušení, ale pokud je cilem toho provozování vybrat si distro, které funkcionalitou, správou, repozitáři a UI tazateli vyhovuje tak to celé projít způsobem, kdy otestuji to co považuji za důležité a pak po výbšru provedu konečné nastavení.
    k3dAR avatar 27.5.2019 23:33 k3dAR | skóre: 62
    Rozbalit Rozbalit vše Re: arch sifrovany
    ad 1) dobre, sdilet etc urcite neni dobrej napad, pokud by to snad nekoho opravdu napadlo :-)
    kdyz mi systemA zapisuje na datovy-disk soubor1 a ja ho hibernuju, tak se syncne zapis na disk, pouze nebude soubor zatim celej, kdyz pak pustim systemB a budu pristupovat(cist/zapisovat) na stejnej datovy-disk, nemuzu preci nic ohrozit, dokud by me nenapadlo pristupovat k tomu rozkopirovanemu souboru1 pred hibernovanim systemuA... ale to jake bloky jsou volne/obsazene preci po pro buzeni z hibernace bude systemA resp. filesystem na datovy-disk zjistovat az pri pokracovani zapisu, nema nejakou cache v hibernacnim oddilu/souboru kde by mel zapamatovane jake bloky byli volne pred zacatkem zapisovani, to by znamenalo ze by na datovy-disk nezavisle na (ne/)hibernaci slo zapisovat vzdy jen max 1 soubor najednou :-)

    ad 2) zduvodnil sem ze nakup SSD je prirozena volba, pokud ale z jakehokoliv duvodu je stavajici HDD chteno/potreba/nutno/to_je_jedno pouzit, plati co sem psal o nezbytecnosti swapu na rotacnim disku
    nejde jen o cold boot attack, muze jit o proste vyuziti diry v sporici/lockeru/sluzby/atd... v tom probuzenem_z_ram/bezizim_systemu/s_odemcenym_luks

    ad 3) vazne v tom nevidim problem, naopak nesifrovat vsechny ty distra bych chapal jen v pripade, ze by k tomu sendul doma v patek vecer, a do nedele vecer prosel (treba) 10 dister a jedno si vybral, ale jakmile si bude chtit nainstalovat na NB 10 dister a par mesicu je postupne/na_preskacku skouset, s tim ze samozrejme bude prenaset NB, nekde ho (vypnutej) nechavat, zapinat/vypinat, restartovat do dalsiho systemu podle nalady atd, tak proc to vse nesifrovat? nenapada me jedinej problem kterej by mohl nastat (obzvlast pokud by jak sem psal mel kazdej system svuj vlastni LUKS)
    porad nemam telo, ale uz mam hlavu... nobody
    28.5.2019 01:29 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: arch sifrovany
    Ad1. co a kdy se syncne to závisí na aplikaci. Pokud máš rozeditorovaný soubor na aplikaci záleží co má v paměti a kdy zavolá zápis do disku. A když do toho souboru zasáhneš z jiného systému ve chvili kdy je rozeditován tak máš problém, a přiom jsi už mohl na to že máš rozeditováno zapomenout. Nebo jinak řečeno, uřídit to samozřejmě jde, ale klade to vyšší nárok na uživatele. Další věcí je, že ti tam může jet nějaká databáze v uživatelském prostoru. Třeba díky tomu, že uživatel zaškrtl automatickou indexaci. Další vec na sdílení uživatelského prostoru může být neshoda UID, díky tomu, že různá distra začínají uživatelům přiřazovat od jiného základu (potkal jsem kromě obvyklejšího od 1000 i od 500), nebo že udělam jeden virtuál pro přítelkyni, ale zapomenu na to, že když ji udělám jako prvního uživatele bude mít stejné UID jako já v jiném virtuálu.

    ad3. No myslím si, že nainstalovat 10 dister není správná cesta na výběr, protože se v tom utopí a na druhou stranu ani cesta mít několik dister pár měsíců je také špatná cesta.

    Rozumější mít etapový výběr. 1. jak aktuální chce mít distribuci (od rolling distra až k dlouhé periodě jako debian s 2 lety) 2. jaké grafické prostředí a to lze vyzkoušet na jednom distru. 3 jestli ho přitahuje nějaká specifická věc. např. ubuntu/mint přístup, integrovaný yast v opensuse apod. 4. pokud ještě je ve výběru více než 1-2 distribuce tak rozsah repozitářů. (první krok je čistě intelektuální bez instalace, druhý je skoro jedno na čem se provede. Třetí začne s tím jak mám dobře grafické prostředí integrované do distra a jak se o něj starají.)

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.