Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Czy ktoś się orientuje może w jaki sposób odbywa się montowanie zaszyfrowanych przy pomocy luksa partycji podczas startu systemu? Stworzyłem sobie drugi kontener, na takie samo hasło jak poprzedni, dodałem linijkę w /etc/crypttab:
# <target name> <source device> <key file> <options> sda2_crypt UUID=727fa348-8804-4773-ae3d-f3e176d12dac none luks crypt_leon UUID=dc7f4586-a33d-4707-98e9-8b55c559b0d2 none luks
ale podczas startu systemu jestem proszony o dwa hasła. Znalazłem skrypt, który jest dostarczony z pakietem cryptsetup i po przekonfigurowaniu drugiego voluminu oraz zmianie wpisów w /etc/crypttab , system potrzebuje tylko jednego hasła by odblokować oba dyski.
Tak wygląda obecnie mój crypttab:
# <target name> <source device> <key file> <options> sda2_crypt UUID=727fa348-8804-4773-ae3d-f3e176d12dac none luks crypt_leon UUID=dc7f4586-a33d-4707-98e9-8b55c559b0d2 sda2_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
Tak wygląda ten skrypt:
#!/bin/sh # WARNING: If you use the decrypt_derived keyscript for devices with # persistent data (i.e. not swap or temp devices), then you will lose # access to that data permanently if something damages the LUKS header # of the LUKS device you derive from. The same applies if you luksFormat # the device, even if you use the same passphrase(s). A LUKS header # backup, or better a backup of the data on the derived device may be # a good idea. See the Cryptsetup FAQ on how to do this right. countlines() { local IFS input count tmp input="$1" count=0 IFS=' ' for tmp in $input; do count=$(( $count + 1 )) done echo $count } if [ -z "$1" ]; then echo "$0: must be executed with a crypto device as argument" >&2 exit 1 fi if ! device=$(dmsetup --showkeys table 2>/dev/null | grep "^$1:"); then echo "$0: failed to find $1 in dmtable" >&2 exit 1 fi if [ -z "$device" ]; then echo "$0: device $1 doesn't exist" >&2 exit 1 fi count=$(countlines "$device") if [ $count -ne 1 ]; then echo "$0: more than one device match $1" >&2 exit 1 fi eval set -- $device type="$4" key="$6" if [ "$type" != "crypt" ]; then echo "$0: device $1 is not a crypto device" >&2 exit 1 fi echo -n "$key" exit 0
Z tego co zaobserwowałem to skrypt wyciąga 128 znakowy ciąg z wyniku polecenia:
# dmsetup table --showkeys
i jest to hasło w postaci szesnastkowej. Aby odblokować drugi kontener tym samym hasłem, potrzebne jest wprowadzenie tej 128 znakowej frazy do nagłówka zaszyfrowanej partycji, czyli podać drugie hasło tym razem 128znakowe.
Próbowałem też przepchnąć takie ustawienie partycji:
# <target name> <source device> <key file> <options> sda2_crypt UUID=727fa348-8804-4773-ae3d-f3e176d12dac none luks crypt_leon UUID=dc7f4586-a33d-4707-98e9-8b55c559b0d2 sda2_crypt luks
Ale to już wyrzuca ostry błąd o braku odpowiedniego klucza, choć to dziwne bo aktualnie w nagłówku tej partycji są zajęte dwa sloty, jedno jest na nomralne hasło i mogę otworzyć kontener z palca podając je, drugi zaś jest na ten 128 znakowy zapis hexalny, który też wpisany jako hasło otwiera kontener.
Domniemywam, że to 128znakowe hasło jest wprowadzane przy starcie systemu do drugiego kontenera z automatu. Jak to się dzieje, że w tym przypadku kontener jest odblokowywany automatycznie, a w przypadku podania normalnego hasła trzeba je podawać tyle razy ile jest kontenerów albo wręcz sypie błędem o złym kluczu? Czy cryptsetup nie może po prostu użyć normalnego hasła dla wszystkich voluminów po tym jak się je wpisze na starcie systemu? A może istnieje inna opcja w crypttab, której powinienem użyć?
Ostatnio edytowany przez morfik (2013-11-24 16:15:47)
Offline
morfik napisał(-a):
Czy cryptsetup nie może po prostu użyć normalnego hasła dla wszystkich voluminów po tym jak się je wpisze na starcie systemu?
W sumie dlaczego miałby to zrobić? Skoro to inny wolumin, to otwierany jest oddzielnie. Ten decrypt_derived chyba działa tak jakbyś dla woluminu mającego tego używać podawał keyfile a nie wpisywał ręcznie hasło, tyle że bierze to z wprowadzonego hasła. Przy czym to tylko tak na logikę na podstawie informacji z tego posta, nigdy tego nie używałem.
Offline
Obecnie mam 4 voluminy (lvm+3partycje) i wpisanie jednego hasła po dodaniu tego samego 128 znakowego kodu do każdej z tych 3 partycji otwiera je wszystkie na starcie, jeden po drugim. Tak to wygląda na bootcharcie:
Na dobrą sprawę to przecie nie ma tam żadnego keyfile zewnętrznego. Są zajęte dwa sloty, oba to hasła, jedno zwykłe, drugie ma 128 znaków. Czy on ten ciąg 128 znakowy traktuje jakoś inaczej? Ja nim mogę otworzyć kontener, kopiując go z dmsetup i wklejając gdy cryptsetup luksOpen prosi o hasło. Tak chyba nie działa keyfile? I trochę mnie to zastanawia, że jedno hasło wchodzi z automatu, a drugie nie.
Offline
Czasem nie chodzi tu o kombinację nagłówek sda2_crypt + ten Twój ciąg, a nie sam ciąg? W sumie bez sensu, że tak strzelam. ;) Ewentualnie spróbuję to porządnie ogarnąć albo będę siedział cicho już.
Offline
Strzały są dobre, entropia się przyda. xD
ArnVaker napisał(-a):
Czasem nie chodzi tu o kombinację nagłówek sda2_crypt + ten Twój ciąg, a nie sam ciąg?
Co dokładnie masz na myśli?
Doszukałem się info, że ten 128 znakowy ciąg to nie jest hasło w hexach tylko:
where <key> is a hexadecimal representation of the binary key.
Choć jest ona używana w drugim kontenerze jako hasło, chyba, że inaczej jest to traktowane.
Ostatnio edytowany przez morfik (2013-11-08 15:24:25)
Offline
Chyba powoli rozumiem zasadę działania tego mechanizmu. Ten drugi keyslot jest tworzony na wzór keyfile ale jak to z keyfile bywa, zwykle się go trzyma na zewnętrznym dysku (np. pendirve) i ktoś może go podejrzeć i zgrać. A tutaj ładuje się do pamięci jeden klucz szyfrujący który jest trzymany w hexalnej postaci przez dmsetup, ten ciąg zawsze będzie inny dla każdej zaszyfrowanej partycji, dlatego nadaje się na keyfile, do którego dostęp można uzyskać tylko po podaniu odpowiedniego hasła. Bez hasła nie będzie klucza, nie będzie ciągu i nie będzie można go wydobyć z dmsetup. Więc to działanie by było ok ale tylko w przypadku gdyby był zajęty jeden slot. Wtedy wszystkie partycje mające hexowy zapis klucza binarnego jako hasło byłyby zależne od nagłówka pierwszej partycji i wtedy jakby coś się stało z tym nagłówkiem, wszystkie inne partycje zależne od partycji pierwszej by były udupione. :] Ale póki istnieje drugie hasło w nagłówku, zawsze będzie można uzyskać dostęp do "zależnych" partycji i nadal nie rozumiem dlaczego nie można użyć normalnego hasła i przekazać go tak jak to robi truecrypt. Bo w nim, gdy się da auto montowanie partycji, to zamontuje on wszystkie, które mają takie samo hasło. Czyli można mieć 5 partycji, 3 na jedno hasło, 2 na drugie, i po podaniu jakiegoś hasła, o ile to jest prawidłowe, zostaną odszyfrowane 2 lub 3 partycje. Czemu czegoś takiego nie można z luksem zrobić?
To przypomina trochę odszyfrowanie jednego dysku przez prawdziwy keyfile, który jest fizycznie zlokalizowany np. w katalogu /root na zaszyfrowanym systemie. Wtedy po odszyfrowaniu systemu uzyskuje się dostęp do keyfile i można zamontować kontener przy jego pomocy. Można sprecyzować normalny keyfile w /etc/crypttab i na dobrą sprawę nie ma większej różnicy między jednym i drugim rozwiązaniem. No chyba, że się nada złe prawa do pliku, wtedy będzie można odczytać keyfile na działającej maszynie, zaś dostęp do tabeli z kluczami w dmsetup wymaga uprawnień roota.
Zastanawia mnie czy to był główny powód powstania tego skryptu.
Offline
Znalazłem w końcu to czego szukałem.
Jest inny skrypt -- /lib/cryptsetup/scripts/decrypt_keyctl on wymaga do prawidłowego działania pakietu keyutils . Trzeba też nieco inaczej napisać plik /etc/crypttab -- powinien wyglądać mniej więcej tak:
sda2_crypt UUID=727fa348-8804-4773-ae3d-f3e176d12dac haslo luks,keyscript=decrypt_keyctl crypt_leon UUID=dc7f4586-a33d-4707-98e9-8b55c559b0d2 haslo luks,keyscript=decrypt_keyctl
W tym przypadku hasło nie jest hasłem ani keyfile tylko identyfikatorem, który wskazuje na to jakie kontenery mają używać tego samego hasła. Czyli jeśli by dać każdemu ze zdefiniowanych kontenerów indetyfikator np. hasło, po wpisaniu hasła do pierwszego z nich, reszta zostanie odblokowana automatycznie przy użyciu tego hasła, które będzie trzymane w pamięci przez 60s od jego wprowadzenia. Póki co nie da rady dostosować tego czasu, być może kiedyś się da. W każdym razie po uzupełnieniu /etc/crypttab trzeba jeszcze wygenerować initramfs przy pomocy:
update-initramfs -u -k all
I to w zasadzie tyle. Efekt jest dokładnie taki sam jak w przypadku decrypt_derived tyle, że nie trzeba się bawić nagłówkami voluminów i dodawać nowych kluczy.
Offline
Strony: 1