Dotaz: Automatické připojení šifrovaného oddílu

[Petr Fiedler]

@k3dAR:

- zapnes pc, Grub se zepta na heslo LUKS se systemem?

Ano.

- startuje a zepta se znovu na LUKS pro druhej_disk?

Ano. Jen se nejedná o disk, ale o oddíl na stejném disku.

- luks klic-soubor mas totozny pro oba LUKS disky?

Ano.

- luks klic-heslo mas totozny pro oba LUKS disky?

Ano.

- kdyz pro druhej_disk zakomentujes radky v fstab a crypttab a po restartu zkusis rucne odemknout pres jeho keyfile:

sudo cryptsetup luksOpen /dev/sdXY sdXY_open --key-file=/boot/crypto_keyfile.bin

odemkne se, je videt odemcenej nazev v mapper?

ls -l /dev/mapper/sdXY_open

Je tam tohle:

lrwxrwxrwx 1 root root 7 úno 26 15:56 /dev/mapper/sdXY_open -> ../dm-2

Když pak na ploše kliknu na ikonu "Počítač" a pak na ten oddíl, tak se mi to otevře, aniž bych musel zadávat heslo.

Když jsem instaloval systém, použil jsem tvůj skript a nastavil jsem jej tak, že instalátor ponechal většinu místa na disku volnou. Pak jsem na to volné misto dal LUKS, LVM jsem NEpoužil a naformátoval jsem to takto:

sudo mkfs.ext4 -L nazev_datoveho_oddilu /dev/mapper/nazev_datoveho_oddilu

Při nastavování automatického připojování jsem pak z následujícího použil do /etc/fstab druhou variantu:

# v pripade ze nad tim LUKS mas LVM
/dev/mapper/vgname-lvname 	 /kam/pripojit           ext4    defaults,noatime          0       2

# v pripade ze nad LUKS mas (nerozdelene) naprimo filesystem
/dev/mapper/nazev_pod_kterym_se_odemkne 	 /kam/pripojit           ext4    defaults,noatime          0       2

# v pripade ze nad LUKS mas vytvorenou mbr/gpt tabulku oddilu
/dev/mapper/nazev_pod_kterym_se_odemkneCISLOODDILU 	 /kam/pripojit           ext4    defaults,noatime          0       2

Neměl jsem náhodou použít tu třetí?

---

---

Odpovědi

[Petr Fiedler]

Když jsem pak ten oddíl, který jsem připojil tím tvým příkazem z terminálu chtěl zase odpojit, tak to po mě chtělo heslo, protože to "spustil jiný uživatel". Šlo by to nějak poladit, aby to nechtělo to heslo?

[k3dAR]

"druha varianta" je v poradku, protoze ty jak pises si odemcene primo formatoval, "treti varianta" by byla kdyby si misto toho udelal "sudo parted /dev/mapper/nazev_pod_kterym_se_odemkne" a vytvoril tabulku oddilu (mklabel) a jeden ci vice oddilu (mkpart)...

porad me nic nenapada(proc druhej_luks chce heslo v prubehu bootu), tim klic-soubor ti to rucne odemknout jde (takze je k LUKS prirazen ok), v /etc/crypttsetup predpokladam mas radek pro druhej_luks totoznej jako pro prvni_luks (ktere ti odemne ok to heslo zadane v grub a system z nej najede) krome UUID... doufam ze prvni slovo nemas pro oba luks, to je ten nazev_pod_kterym_se_odemkne a musi mit kazdej vymyslene jinej...
pak jeste me napada, (v puvodnim vlakne to nevidim), zda po uprave cryptsetup aktualizujes initramfs:

sudo update-initramfs -k all -u

pokud ne, tak v initramdisk o tom nevi a snazi se to autoodemknout az system, a v tu chvili uz neni klic /crypto_keyfile.bin (jako v pripade initramdisku), ale v /boot/crypto_keyfile.bin

[Petr Fiedler]

"druha varianta" je v poradku, protoze ty jak pises si odemcene primo formatoval, "treti varianta" by byla kdyby si misto toho udelal "sudo parted /dev/mapper/nazev_pod_kterym_se_odemkne" a vytvoril tabulku oddilu (mklabel) a jeden ci vice oddilu (mkpart)...

Díky za vysvětlení.

v /etc/crypttsetup predpokladam mas radek pro druhej_luks totoznej jako pro prvni_luks (ktere ti odemne ok to heslo zadane v grub a system z nej najede) krome UUID...

Přesně tak.

doufam ze prvni slovo nemas pro oba luks, to je ten nazev_pod_kterym_se_odemkne a musi mit kazdej vymyslene jinej...

Nemám. Systémový oddíl tam má "luks" viz. skript a ten datový oddíl jsem si pojmenoval jinak.

pak jeste me napada, (v puvodnim vlakne to nevidim), zda po uprave cryptsetup aktualizujes initramfs:

sudo update-initramfs -k all -u

Instaloval jsem nové jádro, takže update-initramfs IMHO proběhl, ale raději jsem to ještě zadal ručně, ale nepomohlo to.

porad me nic nenapada(proc druhej_luks chce heslo v prubehu bootu), tim klic-soubor ti to rucne odemknout jde (takze je k LUKS prirazen ok), v /etc/crypttsetup predpokladam mas radek pro druhej_luks totoznej jako pro prvni_luks (ktere ti odemne ok to heslo zadane v grub a system z nej najede) krome UUID... doufam ze prvni slovo nemas pro oba luks, to je ten nazev_pod_kterym_se_odemkne a musi mit kazdej vymyslene jinej...
pak jeste me napada, (v puvodnim vlakne to nevidim), zda po uprave cryptsetup aktualizujes initramfs:...

Obojí mělo patrně být crypttab, že jo?

Když při bootu zadám heslo pro odemčení datového oddílu, tak je po naběhnutí systému vše OK. Na ploše vydím ikonu připojeného oddílu. Kliknu na ní pravou myší a zvolím "odpojit". Po zadání hesla se odpojí. Když pak v Nemu kliknu na ikonu toho oddílu, aby se znovu připojil, skončí to touto chybou:

Failed to open file "/crypto_keyfile.bin": No such file or directory

A ještě doplním, že pro ruční připojování toho oddílu mám luks heslo uloženo v klíčence. Když ten oddíl připojuji, tak pak nemusím zadávat dlouhé luks heslo, ale kratší od té klíčenky. To by ale u automatického připojení u bootu vadit nemělo.

Pokud už tě tedy nic nenapadá, dej prosím vědět a já aplikuju luksRemoveKey na /boot/crypto_keyfile.bin a zkusím tohle.

[k3dAR]

sice me ted nic noveho nenapada, ale ten "tohle" postup dela v podstate to same, resp. neresi system v luks, ale jen to co ty, ten dalsi...
rozdil tam vidim 2, prvni povazuju za nepodstatnej, to ze v /etc/crypttab (ano spatne sem pretim napsal cryptsetup nema na konci ",keyscript=/bin/cat" (pokud by to ale byl tvuj problem, tak se neodemkne ani systemovej luks(jen je mozne ze uz to neni treba tam uvedet(coz psal uz i lerimir)))...
druhej a to urcite souvisi s tim tvojim "Failed to open file "/crypto_keyfile.bin": No such file or directory" ze klic nema v initramdisku, ale v systemovem oddilu v /etc/luks-keys (ten adresar je v podstate jedno, jen musis pak totozne uvest u klice v crypttab), pro systemovej to musi byt v initramfs (muj skript ho dava do /boot ale z toho ho nepouziva, ale kopiruje do initramdisku / pri update-initramdisk), nicmene pri nabehlem systemu uz v / neni, takze aby si nemel tuhle hlasku, tak zkus:

sudo cp -a /boot/crypto_keyfile.bin /

kdy je mozne ze initramdisk odemkne jen to prvni, a system se pak snazi odemknout zbyle ale nemel klic v ceste /

[Petr Fiedler]

Víš co teda Keďo? Asi od toho upustím. Prostě ten datový oddíl budu odemykat ručně. Je podle tebe dobrý nápad uložit si do /home/user/Dokumenty texťák s heslem od klíčenky a udělat si spouštěč na ploše a před odemykáním toho oddílu otevřít ten texťák, to heslo zkopírovat do schránky a pak je vložit do dialogu pro odemčení (klíčenka)?

A ještě mi prosím tě řekni, jestli je podle tebe v pořádku uložit na ten šifrovaný oddíl s daty i textový dokument, který obsahuje veškerá moje hesla? Docházelo by totiž k tomu, že ten oddíl bude samozřejmě odemčen když budu používat systém. Např. budu na síti.

[k3dAR]

texťák s heslem od klíčenky a udělat si spouštěč na ploše a před odemykáním toho oddílu otevřít ten texťák, to heslo zkopírovat do schránky a pak je vložit do dialogu pro odemčení (klíčenka)?

zalezi na: 1. zda se nekdo (komu neduverujes) muze dostat fyzicky k prilogovanemu systemu
2. zda je sance ze pouzijes/pouzivas nejaky sw kterej bude/ma bug ze utocnik (pres www?) ziska pristup do systemu
3. zda pouzivas do internetu otevrenou sluzby na PC/NB a/nebo routeru

kazdopadne pokud usoudis ze nic z toho nehrozi, nebo tak malo ze netreba resit, misto ulozeni hesla do textoveho souboru a kopirovani pres schranku, muzes rovnou pro klicenku heslo zrusit, klicenka pak bude mit sva hesla ulozena nesifrovane, ale nebude se pri pozadavku aplikace na predani hesla v klicence, dotazovat na heslo do klicenky

[k3dAR]

btw: tohle bych nenazval resenim, bylo to jen v ramci hledani problemu, popis cisteho reseni je spis

tady

[k3dAR]

edit: tady

[Petr Fiedler]

1) K neuzamknutému pc se fyzicky nikdo nedostane, takže dobrý.

2) To nedokážu posoudit. Používám jen aplikace z repozitáře. Měl jsem sice přidána 2 PPA (UKUU a Grub Customizer), ale aplikace jsem odinstaloval a PPA odebral.
Ta tvá rada ohledně tohoto budu se týká jen síťových aplikací, např. Firefox, nebo FileZilla, nebo všech aplikací? Protože aktualizace ze síťě si stahuje valstně každá aplikace.

3) Vůbec nevím o čem je řeč. A Google mi taky nepomohl. Tipnu: např. SSH?

Jak to mám udělat, aby ta klíčenka nechtěla heslo? Používám tu, co je v Mintu default.

[k3dAR]

2) obecne aplikaci, sice aktualizaci si netahaji aplikace, ale taha jim je "spravce aktualizaci" (apt), ten mel nedavno zrovna chybu, ale i tak nestivova aplikace kterou by si stahl s neduveryhodneho zdroje muzu po siti samozrejme komunikovat... jinak osobne tohle neresim (ani zda je to dobre nebo spatne), takze mozna nejaky security expert by k tomu rekl vice a/nebo lepe

3) jj treba SSH, WWW, atd, kdyz to povolis na NB a zaroven povolis na routeru a ta sluzba by byla blbbe nastavena (u SSH treba slabe heslo, misto klice... u WWW treba spatne opravneni) a/nebo v ni byl bug... to plati i pro router jako takovej, kdyz bys povolil v nem jeho spravu z internetu a byla v nem dira ke zneuziti...

klicenka bez hesla - nainsalujes balicek "seahorse" (~= spravce (nejen) klicenky) a v nem das pravou mys nad "Vychozi klicenka", vyberes "Zmenit heslo", zadas aktualni heslo a pri zadani noveho ho nechas prazdne a potvrdit, myslim ze to zarve "Pozor, pri nenastaveni hesla klicenky bude seznam hesel ulozen nesifrovane"...

[Petr Fiedler]

Dík

[Petr Fiedler]

Četl jsem si tvoji reakci ještě jednou a pochybuji, že si rozumíme. Já to s tím "tohle" postupem myslel tak, že bych systémový oddíl odemykal stejně, jako doposud. Tak, jak to udělal ten skript. A k tomu bych vytvořil dle toho postupu další soubor (klíč), kterým bych odemykal ten datový oddíl. Pomohlo by to?

Vím, že bych to mohl místo ptaní se zkusit, ale bojím se, že bych skončil v "Emergency" a pak bych těžko z flešky odemykal nadvakrát zamčený systémový oddíl. Tak se raději ptám.

[k3dAR]

nepomohlo, rozumel sem, jde o to ze ten postup dela jinak jen 2 veci co sem popsal, a mit oddelenej klic je jedno, dulezite je ze ten klic mas spravne sparovanej, protoze ti to jde pres soubor-klic odemknout rucne...

udelal si "sudo cp -a /boot/crypto_keyfile.bin /" ? jak sem psal, pak je mozne ze se ti odemkne a je urcite ze nebude rvat "failed to open file..."

[Petr Fiedler]

sudo cp -a /boot/crypto_keyfile.bin /

Člověče, představ si, že po aplikaci tohoto příkazu mi funguje automatické připojování toho oddílu, aniž bych při bootu musel zadávat to heslo Haluuuuz

Keďo, prosím tě, přesto, že mi to už funguje, odpověz mi na obě tyhle otázky.

[k3dAR]

tak je to jak sem myslel, ze datovej se snazil odemknout az v ramci systemu a ten v / klic uz nemel, vice sem se rozepsal tu

[lertimir]

Když při bootu zadám heslo pro odemčení datového oddílu, tak je po naběhnutí systému vše OK. Na ploše vydím ikonu připojeného oddílu. Kliknu na ní pravou myší a zvolím "odpojit". Po zadání hesla se odpojí. Když pak v Nemu kliknu na ikonu toho oddílu, aby se znovu připojil, skončí to touto chybou:

Failed to open file "/crypto_keyfile.bin": No such file or directory

A ještě doplním, že pro ruční připojování toho oddílu mám luks heslo uloženo v klíčence. Když ten oddíl připojuji, tak pak nemusím zadávat dlouhé luks heslo, ale kratší od té klíčenky. To by ale u automatického připojení u bootu vadit nemělo.

Pokud už tě tedy nic nenapadá, dej prosím vědět a já aplikuju luksRemoveKey na /boot/crypto_keyfile.bin a zkusím tohle.

Petře, kde je ten klíč? "Fail to open" je zpráva že ho hledá v rootu a ty ho odstraňuješ z adresáře /boot.

[Petr Fiedler]

Čau lertimire

Failed to open file "/crypto_keyfile.bin": No such file or directory

Takhle se mi to chová, jen pokud mám nastaveno automatické připojování toho datového oddílu při startu systému. Problém je v tom, že musím při startu zadávat docela dlouhé heslo k tomu oddílu a to se mi nelíbí. Je pro mne snažší upustit od automountu toho oddílu a zadávat kratší heslo do té klíčenky. Pak mi znovupřipojení po předešlém odpojení toho oddílu nedělá problémy. Takže tohle není třeba řešit, pokud nebude funkční automount toho oddílu při startu, aniž bych musel zadávat to dlouhé heslo. Pokud se to totiž nepodaří vyřešit, tak od toho raději upustím.

Petře, kde je ten klíč? "Fail to open" je zpráva že ho hledá v rootu a ty ho odstraňuješ z adresáře /boot.

Ten klíč je v /boot viz druhá polovina Keďovi reakce.

[lertimir]

Čau. A co máš nastaveno v /etc/crypttab? Moc nechápu kdo ti tu "Failed to open" hlášku píše? Nějak co máš tomu furt nerozumím.

Vůbec není potřeba mít jeden klíč pro oba disky. Pokud druhý klíč máš na zašifrovaném disku je to stejně bezpečné jako odmykat s jedním klíčem. Já mám v crypttab

cat /etc/crypttab 
# Configuration for encrypted block devices.
# See crypttab(5) for details.
moje            /dev/disk/by-id/ata-ST3000DM001-1CH166_Z1FXXXX                 /etc/keys/klic1
archiv          /dev/disk/by-id/ata-ST4000DM000-2AE166_WDHXXXX                 /etc/keys/klic1
osmira          UUID=afc70aac-24aa-4143-9382-f05xxxxxxxx                       /etc/keys/klic1

Takže můj klíč na odemykání dalších disků je prostě někde v adresáři, který jsem si na klíče vytvořil. Jen je potřeba mít v crypttab správnou cestu. Potom v /etc/fstab je odpovídající.

at /etc/fstab 
# 
# /etc/fstab: static file system information
#
/dev/mapper/moje                                /mnt/disky/moje               btrfs   commit=100,defaults 0 0
/dev/mapper/archiv                              /mnt/disky/archiv             btrfs   commit=100,defaults 0 0
/dev/mapper/osmira                              /mnt/disky/osmira             btrfs   commit=100,defaults 0 0

nic jiného a disky je mountnou při startu.

Start bylo trochu více práce protože mám zašifrovaný i /boot a bylo potřeba nastavit podle archu aby nebylo potřeba psát dvakrát heslo.

[k3dAR]

btw: start z LUKS kde ma /boot vyresenej ma pres tenhle installacni skript

[Petr Fiedler]

Díky za informace.

Řešit to dál už asi nemá cenu, protože mi pomohla aplikace tohoto příkazu. Pokud by tě ale něco kvůli pochopení problému zajímalo, zodpovím ti, na co se zeptáš.

[lertimir]

No na to jsem se tě před dvěma otazkami ptal. Co klíč hledá v root a píše chybu? někde máš nastavené, že klíč je v root a jinde, že je v /boot/. Proto jsem se ptal kdo ti tu chybu hlási a v tom místě stačí změnit konfiguraci. Samozřejmě jde také to nakopírovat na obě místa a nebo místo kopie to spíše hardliknout, ale v zásadě je to jedno.

[k3dAR]

na to sem ti "odpovidal" ve skriptu to mam reseno tak ze v /boot je klic jen uschovan a pri update-initrfams se z nej automaticky kopiruje do / v initramfs diky pridanemu initramfs-tools hooku:

#!/bin/sh
cp /boot/crypto_keyfile.bin "${DESTDIR}"

/boot ma nastavene prava 700, crypto_keyfile.bin prava 000...
klic se cte z /etc/crypttab kde je uvedena cesta / , to ve (pred) chvili odemceni LUKS systemoveho oddilu je cesta v initramfs, jak uz sem psal Petrovi nahore, pravdepodobne se odemmkne jen systemovej LUKS v initramfs a druhej LUKS se mu snazil odemknout az v ramci startu systemu a ten tedy stale hledal klic v / kde uz (v rootfs) nebyl...
tim ze ho zkopiroval (a psal sem mu cp s -a aby zachovalo "zadne opravneni") se to potvrdilo, takze ted jak GUI odemceni tak pri startu klic ma v /, resenim mi samozrejme bylo i to pro druhej disk uvest v crypttab uvest cestu ke klici /boot, nebo tim hookem kopirovat klic do initramfs do cesty /boot a v crypttab uvest pro oba LUKS cestu /boot (prvni by bral /boot v initramfs, druhej /boot v rootfs)

[Petr Fiedler]

Čau Keďo,
nepřehlédl jsi tohle?
Už mi to tedy funguje, ale (asi) protože se při kopírování toho klíče s parametrem -a zachovala ta práva, tak při odpojování musím zadávat heslo. Když jsem to připojoval ručně, tak jsem zase musel zadávat heslo od klíčenky, ale při odpojování jsem nic zadávat nemusel. Nešlo by to nějak přenastavit, abych to heslo při odpojování nemusel zadávat? Ale aby to bylo bezpečné. Bezpečí preferuji.

[Petr Fiedler]

Dobrý.

[Petr Fiedler]

Míněno ve vztahu k přehlédnutí mé reakce.

[lertimir]

Fakt si myslíš Radku, že Petr rozumí, co se mu tam děje? Proto preferuji přímočará řešení, které i nepřiliš zkušený uživatel chápe. Ale hlavně že se dostal do stavu, že mu to funguje.

[Petr Fiedler]

No já to právě nechápu vůbec, respektive trošku ano, ale moc ne . Raději bych to nastavil nějak "systémověji", ale nevím jak. A hlavně abych při odpojování nemusel zadávat to root heslo.

[k3dAR]

cemu nerozumis? co je initramfs(=>je to pidi system kterej se natahuje spolecne s jadrem a pripravi "podminky" pro prepnuti na hlavni_system), rootfs(=>hlavni_system, neboli system, neboli to co v nabehlem mas v /) , proc jednou je klic v /(protoze sem to v skriptu tak udelal a je to v initramfs), pak v /boot(protoze tam sem ho "schoval") a musel si ho zkopirovat(protoze ASI datovej LUKS pripojuje az system)? neboli crypttab myslim muzes upravit takto:

# tohle se otevira v initramfs kde je klic umisten v /
tve_jmeno_systemoveho_luks_odemceneho UUID=uuid_tveho_oddilu_s_luks_kde_je_system /crypto_keyfile.bin luks,keyscript=/bin/cat
# tohle se otevira v systemu kde je klic umisten v /boot
tve_jmeno_datoveho_luks_odemceneho UUID=uuid_tveho_oddilu_s_luks_kde_jsou_data /boot/crypto_keyfile.bin luks,keyscript=/bin/cat

a ten klic z / v nabehlem systemu kam si ho zkopiroval smazat:

sudo rm /crypto_keyfile.bin

odpojenim myslis presne co/kdy/jak?

[Petr Fiedler]

Díky za vysvětlení, už to chápu :)

Udělal jsem vše co jsi napsal a datový oddíl je po naběhnutí systému automaticky odemčen a připojen. Když jej ale chci odpojit (pravá myš na ikonu na ploše > odpojit), tak to nejdříve chce jednou heslo, protože:

"Pro odpojení /dev/mapper/nazev_disku, připojeného jiným uživatelem, je nutná autentizace."

Pak to chce podruhé heslo, protože:

"Pro zamknutí šifrovaného zařízení Samsung SSD 850 EVO 500GB (/dev/sdXY), které odemkl jiný uživatel, je nutná autentizace."

Když pak kliknu ve správci souborů na ikonu toho datového oddílu, aby se znovu připojil, skončí to chybou:

"Nelze připojit umístění - operace není povolena."

Když bych ale ten datový oddíl neodemykal a nepřipojoval automaticky, ale ručně, tak při jeho odpojování to žádné heslo chtít nebude a po odpojení a půjde opět bez problémů připojit a dokonce ani nemusím zadávat heslo.
Takže bych chtěl, abych nemusel při odpojování a uzamykání toho automaticky odemčeného a připojeného oddílu zadávat dvakrát root heslo a taky bych chtěl, aby to bez rebootu opět šlo bez problémů připojit.

[lertimir]

No hlavně si ujasni co je pro tebe primární. Pro automatické připojování jsou dvě možnosti.

1. Připojuje systém. To znamená root. To je jak to máš teď. Konfigurace je v /etc/crypttab a /etc/fstab. Nicméně proto, že ti to připojil root, tak ty (pod účtem bežného uživatele) se s tím nemůžeš jen tak piplat. Pro operace musíš dát heslo na oprávnění, že to můžeš udělat (odpojit). Systémové připojení celkem neočekává, že jako uživatel chceš oddíl dynamicky připojovat a odpojovat.
2. Druhá možnost je, že po startu systému se nic připojovat nebude. Ale pokud bys chtěl, tak vše se připojí jen pro tebe automaticky při tvém zalogování. To se dělá jinak a klíčový modul, který je v činnosti je pam_mount konfigurace v /etc/security/pam_mount.conf.xml popřípadě ~/.pam_mount.conf.xml.

[Petr Fiedler]

Nevěděl jsem, že je více možností. Já bych určitě chtěl tu druhou, ale otázka je, jestli to v mém případě půjde. Nepřihlašuji se totiž. Jsem na pc jediný uživatel a mám nastaveno, abych se nemusel přihlašovat. Šlo by to tedy v mém případě nějak nastavit, aby se mi ten oddíl automaticky odemykal a připojoval?

[lertimir]

No to asi tedy také není pro tebe cesta, protože to odemykání se v podstatě děje uvedením hesla k účtu, které se pomocí modulu pam_mount přenese na odemčení šifrovaného disku. To že konfiguraci nikde nemáš není nic divného. Zatím jsi pouze modul nepoužíval. A pam modulů je hodně. Popis a fungování byť trochu starší je zde. Vidíš kolik těch modulů je.

No a já tedy považuji za přirozené a funkční jednak mít na systému více účtů. Byť třeba jeden nebo dva jsou testovací, kdy si třeba zkusím konfiguraci grafiky dříve než bych si rozbil hlavní účet a nebo naopak účet s žádnými změnami v konfiguraci, pro otestování jestli dané chování jsem si udělal na účtu sám lokální konfigurací a nebo je to celosystémová záležitost. A za druhé, na všech účtech mít hesla jednak proto že nežiji sám a mám skutečně rád, když mám systém pod kontrolou a jednak se k němu připojuji zvenčí. Takže mě nevadí psát heslo, když se notebook uspí nebo obrazovka zamkne a samozřejmě i když sysétm startuje. Jedno máster heslo na disky a druhé na účet.

[Petr Fiedler]

No tak těch modulů je fakt požehnaně.

Já to mám nastaveno tak, abych nemusel při startu zadávat heslo od účtu, protože mi to přije zbytečné. Když už zadávám heslo k odemčení LUKS. PC mám nastaven tak, že se po nějaké době nečinnosti spustí spořič obrazovky a chvíli na to se monitor vypne úplně. Když pak přijdu k pc, tak jen ťuknu do mezerníku a hotovo. Kdyby tu ale byla návštěva ve kterou nemám plnou důvěru a potřeboval bych od pc odejít, tak jej zamknu ("odhlásit"). Nebo kdybych šel na chvíli pryč, tak pc uspím a v takovém případě by po probuzení taky bylo požadováno heslo. Takhle mi to maximálně vyhovuje. Až tedy na ten datový oddíl. :(

Na testování budu mít stejný systém jako používám ve virtuálu. A taky jsem si nechal volné místo na externím disku na pokusnou instalaci. Takže když bude potřeba něco zkoušet na železe, tak není problém. Do budoucna se snad naučím snapshotovat a bude klid.

Pořád to někdo říká a začínám to vidět i já, jak si můžeš Linux krásně přiohnout. To je fakt paráda. O tom lidé na Windows nemají ani potuchy.

[lertimir]

Totiž není žádný důvod k tomu disk odpojovat. žádnou další bezpečnost tím nezískáš. Máš zašifrovaný root a na něm klíče k datovému disku. Po bootu se odšifruje root a připojí datový disk, a odpojovat se bude když počitač vypínáš. Když to vezmeme jednoduše tak máš 4 situace

1. Útočník nemá fyzický přístup k počítači a zařízení je vypnuté. Nic nehrozí.
2. Útočník nemá přístup k počítači a zařízení je zapnuté. Bezpečnost je na kvalitě síťového nastavení. (kvalitní heslo, přístup jen přes ssh klíče, aktualizované programy, pouze nutné služby, nastavení firewalu).
3. Útočník má fyzický přístup k počítači a zařízení je vypnuté. Veškerá bezpečnost je v zásadě v kvalitě vstupního hesla do rootu. Jak se přes ně útočník dostane, dostane se i do datového disku.
4. Útočník má fyzický přístup k zařízení a zařízení je zapnuté. Pak záleží na zdrojích útočníka, pokud je to amatér či profesionál s omezenými zdroji, tak primárně záleží na kvalitě hesla k účtu roota. Na rozdíl od bodu dva, který lze nastavit takže, že pomocí hesla se vstoupit nedá, tady přístup přes heslo je vždy. Pokud je profesionál, dostatečně zkušený, motivovaný a s dostatečnými zdroji, tak se k datům dostane. Existuje popsaný a vícekrát ověřený útok zvaný "cold boot attack", kdy se počítač rozebere, na paměti za provozu naleje tekutý dusík, tím se zamrazí v nich paměťový stav, který vydrží vyndání z napájení a přendání do jiného stroje, ve kterém útočník následně z pamětí vyčte data a zvláště najde master šifrovací klíč k disku. Pak má přístup ke všemu. Pokud tvoje záměry jsou ochrana i proti takovému typu útoku, tak musíš zajistit, aby se k zapnutému stroji nikdo nedostal. Což jsou v zásadě režimová opatření, jako např nepřenášet mimo fyzicky chráněný prostor uspaný notebook

Nic nerozhoduje v bezpečnosti o tom jestli máš nebo nemáš zrovna připojený datový disk. To nač by se útočilo jsou data(klíče) na rootu.

[Petr Fiedler]

Asi máš pravdu, že není žádný důvod ten oddíl odpojovat. Hesla mám velmi silná, pravidělně aktualizuji, chovám se bezpečně a nikdo k pc přístup nemá. Nebudu paranoidní a nechám jej stále připojený. Mimochodem, i mě to chvíli před tím, než si to napsal napadlo. Takže hotovo a dík :)

[Petr Fiedler]

Když o tom nad tvou reakcí tak přemýšlím, tak cesta pro mě by asi byla v tom opustit automount toho oddílu a jen nastavit, aby klíčenka nechtěla heslo. Pak bych disk mountoval na dva kliky: Na ploše na ikonu "Počíta" > "Datový oddíl". A bylo by to. Jenže bez pomoci tu klíčenku nenastavím. Nevěděl bys jak na to? Možná ještě třeba Keďa poradí. Nebo možná jej napadne ještě něco lepšího. Uvidíme.

[Josef Kufner]

Pokud při bootu nezadáváš heslo, tak šifrování je zbytečné, neboť se k datům každý dostane prostým zapnutím počítače. Buď šifruj celý disk a pak budeš heslo zadávat úplně na začátku, aby systém vůbec naběhl, nebo použij pam_mount a heslem pro přihlášení současně odemkni i domovský adresář toho uživatele. Druhá možnost však ponechává docela hodně prostoru pro Evil Maid.

[Petr Fiedler]

Já po zapnutí pc heslo zadávám, ale ne k účtu, ale "pouze" k odemčení LUKS.

[Josef Kufner]

Pak můžeš na ten šifrovaný oddíl, který už teď odemykáš, umístit soubory s klíči k ostatním šifrovaným oddílům. V /etc/crypttab pak jen uvedeš cestu k němu (3. sloupec).

[Petr Fiedler]

To já takhle mám, ale problém je v tom, že se ten oddíl odemyká a připojuje při zavádění systému. Ne po přihlášení na můj účet u kterého mám stejně nastaveno, abych po startu pc nemusel zadávat heslo ke svému účtu, protože heslo k LUKS stačí. Po naběhnutí systému je na ploše vidět ikona odemčeného a připojeného datového oddílu. Když ten oddíl ale pak chci odpojit a dám na té ikoně pravou myš > "odpojit", tak to chce poprvé root heslo pro odpojení, protože to připojoval jiný uživatel a podruhé to chce root heslo pro uzamknutí, protože to odemykal taky jiný uživatal. IMHO root. Navíc když pak chci ten oddíl zase připojit, tak to skončí chybou a oddíl se mi připojí až po rebootu. Kdybych ale vypnul automount a odemykal a připojoval ten oddíl ručně, tak to pak při jeho odpojování žádné heslo chtít nebude a kdykoliv půjde bez problémů znovu připojit, aniž bych musel rebootovat. Čili, jak docílit toho, abych při odpojování a zamykání automaticky připojeného datového oddílu nemusel zadávat ta hesla a aby ten oddíl pak šel kdykoliv připojit bez rebootu?
Nebo by mi stačilo nastavit, abych nemusel zadávat heslo do klíčenky, když oddíl připojuji ručně. Na plochu bych si udělal spouštěč (nějak nevím jak) a bylo by to taky dobré. Ovšem nevím, do jaké míry bezpečné. Já to asi nedokážu posoudit.

[Josef Kufner]

V /etc/fstab můžeš přidat volbu user. Pak budou uživatelé smět připojovat a odpojovat daný disk bez zvláštních práv. Nicméně odpojení disku neřeší deaktivaci Luks a zahození klíčů z paměti. Na to pozor.

[Petr Fiedler]

Ne Josefe, to nefunguje. Přidal jsem to tam, rebootoval a stejně to při odpojování chtělo root heslo.

[Petr Fiedler]

V /etc/security/ nemám pam_mount.conf.xml, ale jen pam_env.conf.

A pokud ~/.pam_mount.conf.xml znamená skrytý soubor pam_mount.conf.xml v /home/user, tak ten tam taky nemám.