Създаване, управление и използване на LUKS дялове

Защитата на информацията върху информационни носители от кражба е дефакто задължителна за всеки, който работи с чувствителна информация. Скандалите с изгубване на лични данни върху служебни лаптопи станаха твърде чести, а щетите от тях са огромни. При това достояние на обществеността стават само някои от случаите на загуба или кражба на данни. Други или не са оповестени или дори не са установени, защото информацията е била открадната чрез копиране. Особено опасни са кражбите на носители с данни, представляващи финансова и военна тайна. Въпреки казаното по-горе, е масова практика чувствителна и дори строго секретна информация да се разнася в явен и некриптиран вид или до нея да има безпрепятстван и несанкциониран достъп. Настоящата документация има за цел да предложи на всички заинтересовани (особено на държавните и финансови институции) документация за защитата на информация върху носители чрез използването на LUKS дялове. LUKS е съкращение от Linux Unified Key Setup. Повече информация би могла да бъде намерена на официалната страница на проекта или в Wikipedia.

LUKS дяловете всъщност не са истински дялове, а тип файлова система, но функционират като дялове, поради което за тях ще бъде използвана точно тази терминология. Целта на LUKS дяла е да скрие файловата система в него от неоторизиран достъп чрез криптиране. Често пъти за такива файлови системи се използва понятието "криптирани файлови системи" ("encrypted file systems"), което поне за случая на LUKS не е съвсем коректно. Причината е, че не се криптира файловата система, а дяла, в който тя е разположена. Освен това в LUKS дяла могат да се съдържат структури от по-ниско ниво на файлова система: софтуререн RAID и LVM.

Настоящата документация показва целия процес на създаване на LUKS дялове и използването им, като в добавка представя в детайли инсталационния процес на Fedora върху криптирани дялове. Обхватът е разширен чрез приложения, които да дадат допълнителна, макар и несвързана с LUKS информация, която може да е полезна на потребителя за разбиране на някои основни постановки в изложението.

Документацията е предназначена за сравнително напреднали потребители на дистрибуциите Fedora и Red Hat Enterprise Linux 5 (и дериватите му). Авторът не носи никаква гаранция за причинена загуба на информация или други щети, възникнали в хода на прилагане на описаните по-долу методики и операции.

2. Приложимост

Съдържанието на тази документация е приложимо единствено и само за тези Linux дистрибуции, които използват мениджър за управление на устройствата udev (ядра 2.6) и имат поддръжка на dm-crypt в ядрата си. Приведените по-долу конкретни примери касаят дистрибуциите Fedora (поддържани към момента на написването на тази документация верси) и Red Hat Enterprise Linux (версии 5 и по-високи), както и техни деривати.

Udev е задължителен във Fedora и Red Hat Enterprise Linux 5 и дериватите му. Тази особеност е отчетена в дистрибутивния инсталатор Anaconda, който инсталира RPM пакета udev по подразбиране, тъй като той е част от съвременната архитектура на разработваните и поддържани от Red Hat Inc. дистрибуции.

За да се провери дали RPM пакета udev е инсталиран в системата, може да се изпълни следния команден ред:

Ако инсталирането бъде потвърдено, ще бъде изведена информация от вида:

В случай, че подобна информация не бъде изведена, това означава, че или версията на дистрибуцията е прекалено стара, или в конкретната система е извършена модификация, чрез която е отстранен пакета udev. Без значение кой от двата изброени случая е налице, прилагането на документацията в този случай е непрепоръчително.

Ако се използва текуща версия на Fedora и Red Hat Enterprise Linux (или негов дериват), то почти сигурно е, че дистрибутивното ядро има поддържка за dm-crypt. Тя е зареждаема динамично чрез модула dm_crypt, чието наличие в текущото ядро може да установи така:

Ако модулът е наличен, ще се изведе съобщение подобно на следното:

Ако не бъде изведена подобна информация, най-вероятно търсеният модул не присъства в текущо използваното ядро и тази документация не е приложима в този случай.

Инструментариумът за създаване на криптирани файлови системи и манипулации с тях, е част от пакета cryptsetup-luks. Този пакет внася в системата инструмента cryptsetup и динамичната библиотека libcryptsetup.so.0. Той задължително трябва да присъства в системата. Макар, че се инсталира по подразбиране от инсталатора Anaconda, е добре да провери за наличието му:

Ако след изпълнението на този команден ред се получи резултат от вида:

то пакетът присъства в системата. При липсата на подобен резултат обаче, трябва да се прибегне до инсталация:

Абсолютно задължително е използването на вграденият в дистрибуцията инструментариум за актуализация на пакетите, а самото актуализиране трябва да се извършва в минимален срок след публикуването на актуализираните пакети в дистрибутивното хранилище. Добрата практика по поддържане на сигурни системи изисква инсталиране на пакети само и единствено от дистрибутивните хранилища. Използването на хранилища от външни разработчици не се препоръчва, макар в някои случаи да е допустимо. Използването на дистрибуции с изтекъл жизнен цикъл обезмисля изграждането на тяхна основа на криптирани файлови системи.

3. Инсталиране на Fedora върху LUKS базирани дялове

3.1. Предварителна информация

Инсталаторът на дистрибуциите Fedora и Red Hat Enterprise Linux (и дериватите му) е Anaconda. Към момента на написването на това ръководство, Anaconda може да инсталира върху LUKS дялове само дистрибуцията Fedora (текущи версии 9 и 10). Що се касае до Red Hat Enterprise Linux 5, версията на инсталатора в тази дистрибуция не поддържа подобен тип инсталация (а зареждането на LUKS дяла за / не се поддържа и от дистрибутивната конструкция на initrd). Очаква се, че такава поддръжка ще има в Red Hat Enterprise Linux 6. Нужно е да се има предвид, че подобна липса не е технически недостатък, а е продиктувана от консервативността на Red Hat Enterprise Linux, която се изразява в това, че в рамките на жизнения цикъл на дистрибуцията не може да има мажорни скокове във версиите на включения в нея софтуер. Това важи и за производните (дериватите) CentOS и Scientific Linux.

Добрата практика показва, че най-мащабируемият тип инсталация на дистрибуцията е върху LVM2 структура. Единственото изключение е дяла за файловата система /boot, който не може да се намира върху LVM2 (не може и да бъде LUKS). В Приложение II са посочени преимуществата на LVM2, използван в Linux ядра 2.6 (това е мажорната версия на ядрата в текущите версии на Fedora и в Red Hat Enterprise Linux 5). Всички примери за инсталиране на Fedora върху LUKS дялове, показани по-долу, са обвързани с използването на LVM2, имено заради спазването на споменатата добра практика.

3.2. Инсталиране върху криптиран LVM2 дял

Това е най-масовият случай на инсталация на Fedora и обикновено касае лаптопи и работни станции с един твърд диск. Той се разширява и за случаите, в които дисковото пространство на системата е организирано в хардуерно реализиран RAID масив (на базата на RAID контролер), който може да се разглежда от системата като един твърд диск. При този тип инсталация се създава един некриптиран дял с файлова система (най-често ext3), която се монтира като /boot и един LUKS дял, в който се изгражда LVM2 структура и в нея се създават swap, дял за / и файловите системи в тях.

ВНИМАНИЕ! По подразбиране Anaconda извършва криптирането на LUKS дяловете с алгоритъм AES и 128 битов ключ. В текущите версии на инсталатора няма меню за указване на алгоритъма за криптиране и дължината на използвания ключ. Ако в определени случаи подразбиращото се ниво на сигурност е недостатъчно, по-долу е показано как да се извърши криптиране на LUKS дяловете с алгоритъм AES и 256 битов ключ и последващото инсталиране на дистрибуцията.

Инсталаторът се стартира в графичен режим и в интерактивен режим се изпълняват последователните стъпки на инсталацията. Когато Anaconda отвори менюто за определяне на режима за създаване на дялове и файлови системи:

се указва криптиране на дяловете на системата (за които това е възможно) и преглед на разделянето им и създадените в тях файлови системи:

След натискане на бутона "Next" се извършва автоматично създаване на дисковата структура и тя се визуализира в менюто за управление на дялове и файлови системи:

За да се продължи с инсталацията се натиска бутона "Next" и ще се появи прозорец за въвеждане на паролата, с която ще се криптира създадения LUKS дял:

Паролата се въвежда двукратно (втория път за потвърждение):

и ако и в двете полета е въведена една и съща комбинация от символи, след натискане на бутона "OK" ще се форматират създадените файлови системи и Anaconda ще отвори менюто за избор на пакети за инсталация.

3.3. Инсталиране върху криптиран LVM2 дял с използване на AES256

Инсталаторът Anaconda не предоставя (засега) избор на параметрите за криптиране на LUKS дяла и използва един криптиращ алгоритъм (AES) и една дължина на ключа (128). В този раздел е показано как може да се достигне максималното достижимо ниво на сигурност в дистрибуцията - криптиращ алгоритъм AES с 256 битов ключ. Всеки, който извършва описаните по-долу операции трябва да има познания по създаване на дялове с fdisk и процедурата по маркирането им като съдържащи LVM2 структура (Linux LVM).

Изтегля се LiveCD дистрибутива на Fedora (за последната финална версия на дистрибуцията). Записва се на CD или DVD носител и се зарежда. Върху твърдия диск трябва да се създадат поне два дяла - един с ext2 файлова система (изградена с mkfs.ext2) с точка на монтиране /boot и капацитет не повече от 256 MB (за примера са 196 MB) и един за LVM2 структурата с капацитет достатъчен за разполагане на swap и / дялове в нея. За целта могат да бъдат използвани вече създадени дялове или такива да се създадат с някой от предназначените за това инструменти (напр. fdisk). По-долу в изложението ще се предполага, че дялът с ext2 файловата система има физически път в системата /dev/sda1, а този съдържащ LVM2 структурата е достъпен като /dev/sda2. Допълнително върху дяла /dev/sda1 трябва да бъде установен "boot" флаг. След това се отваря теминал и се придобиват права на супер потребител (root):

Първо се форматира дялът /dev/sda1 чрез инструмента mkfs.ext2:

и се поставя етикет "/boot" върху файловата система:

Дялът /dev/sda2 се форматира като LUKS с 256 битов ключ (алгоритъмът AES е подразбиращ се и не се указва) чрез командния ред:

След изпълнението му ще се изведе диалогово меню, в което трябва да се потвърди желанието за форматиране на дяла:

Ако наистина дялът трябва да се форматира, се въвежда с главни букви символния низ "YES":

след което се натиска "Enter". Следва диалог за двукратното въвеждане на паролата за криптиране на LUKS дяла (при въвеждането й върху екрана не се изписват никакви символи):

Ако тя бъде въведена и потвърдена, ще се извърши форматиране на LUKS дяла и при успешен изход от операцията, ще бъде изведено съобщението:

След това системата се рестартира и се зарежда инсталационния носител (CD, DVD) на дистрибуцията. Стартира се инсталация в графичен режим и в прозореца за задаването на паролата на root, след натискането на бутона "Next", инсталаторът ще сканира дяловете върху твърдия диск, ще намери създадения LUKS дял и ще изведе прозорец за въвеждане на паролата за декриптирането му (тази парола е същата, въведена при форматирането на дяла с инструмента cryptsetup):

След правилното й въвеждане се появява прозореца, в който се определя режима на създаване на дялове и файлови системи:

и се натиска бутона "Next". Отваря се прозореца с менюто за управление на дялове и файлови системи, в което са видими създадените до момента дялове. В него се маркира дяла, в който ще бъде създадена файловата система за /boot:

и се натиска бутона "Edit". Това довежда до извикване на прозорец за редакция на избрания дял:

в който се указва точката на монтиране на файловата система (в случая /boot):

след което се натиска бутона "OK" за връщане в основното меню за управление на дяловете и файловите системи. В него дялът /dev/sda1 ще бъде асоцииран като точка на монтиране /boot във файловата система:

Пристъпва се към изграждане на LVM2 структурата в дяла /dev/sda2. За целта се натиска бутона "LVM" и по този начин се създава LVM груптата с име "VolGroup00" (името може да се смени), съпроводено с отварянето на прозорец за създаване и редактиране на логическите дялове в нея:

В тази група трябва да се създадат минимум два дяла. Първият е swap дял:

а втория е дяла за файловата система с точка на монтиране /:

Ако създаването на тези два логически дяла е преминало успешно, те ще се появят в списъка с логически дялове на групата "VolGroup00":

След натискане на бутона "OK" отново ще се премине в главното меню за създаване и управление на дялове и файлови системи, като в него ще бъде изведена информация за създадените логически дялове и файлови системи:

С това специфичната част на инсталацията, свързана с преминаване към LUKS дял криптиран с AES и 256 битов ключ, е приключена и може да се премине към форматиране на създадените файлови системи и избор на пакетите за инсталация с натискане на бутона "Next".

3.4. Инсталиране върху LUKS базиран софтуерен RAID1

Софтуерно реализираният RAID1 масив е евтин и сравнително стабилен начин за репликация в съотношение 1:1 на съдържанието на системен дял в реално време. Повече информация за реализирането на софтуерни RAID масиви в Linux може да бъде намерена в Приложение I.

При инсталирането на Fedora върху LUKS базиран софтуерен RAID1 се използва следната схема. Създават се два дяла (по един върху двата твърди диска) с големина не повече от 260 MB, които не се криптират. Чрез съответните менюта в Anaconda те се асемблират в един RAID1 масив и в него се създава дял и ext2 файлова система, която ще бъде монтирана като /boot. На втора стъпка се създават други два дяла (по един върху двата твърди диска), но и двата LUKS (паролата за криптирането се изисква в прозорец на инсталатора). След това се асемблират в RAID1 масив и върху него се създава LVM2 дял, който съдържа най-малко два дяла - swap и дял за кореновата файлова система /. Накрая се инсталират пакетите, извършват се постинсталационните процедури и се инсталира зареждащата програма GRUB.

При инсталиране на Fedora върху софтуерен RAID1, инсталационният процес не протича докрай. Причината е проблем в текущите версии на инсталатора Anaconda. Той се състои в това, че при определени условия (които се постигат при следваната тук процедура), не е възможно автоматично да се намери списъка с устройства, върху които да се инсталира GRUB. Поради наличието на този проблем инсталацията на дистрибуцията се извършва на два етапа. Първият включва създаването на LUKS дяловете на софтуерния RAID1 масив, създаването на LVM2 структурата върху масива, и инсталация на пакетите, и завършва в момента, в който инсталатора върне съобщение за грешка при опит да инсталира GRUB. Хронологично погледнато, съобщението за грешка се появява след като завърши инсталацията на всички избрани пакети и се премине към постинстаналионния процес, в хода на който се инсталира GRUB. Вторият етап включва стартиране на "rescue" дистрибутив на Fedora и ръчно инсталиране на зареждащата програма GRUB.

ВНИМАНИЕ! Ако изграждането на LUKS дяловете за софтуерния RAID1 масив, се извършва от Anaconda, ще бъде използван криптиращ алгоритъм AES с дължина на криптиращия ключ 128 бита. Ако такова ниво на сигурност е недостатъчно, може да се използва 256 битово криптиране, но в този случай RAID1 масива следва да се създаде преди инсталацията, например с помощта на LiveCD дистрибутива на Fedora. След като бъде създаден се стартира отново процедурата по инсталация на дистрибуцията и инсталаторът ще прочете и декриптира готовите LUKS дялове. След това на тяхна основа ще сглоби RAID1 масива, ще създаде LVM2 структура върху него и логическите дялове в нея, ще изгради файловите системи и ще инсталира пакетите.

Инсталаторът се стартира в графичен режим. В началото на процедурата за разделяне на дисковото пространство и създаването на файловите системи:

Нужно е да се отбележи, че за примера са избрани два твърди диска с различен капацитет. Когато се създават дяловете за RAID1 масивите трябва да се отчете, че максималното използваемо пространство е равно на капацитета на по-малкия диск! Конкретно за даденият пример това означава, че максималното използваемо пространство за създаване на RAID1 масиви е 19069 MB.

С натискане на бутона "Next" се влиза в менюто за създаване и управление на дялове и файлови системи. Ако върху достъпните два твърди диска няма създадени дялове, те би трябвало да се виждат в това меню по следния начин:

Първо се създава дял за RAID1 масива, в който ще се намира дяла с файловата система за /boot. Както бе споменато по-горе, капацитетът на този дял не бива да надхвърля 260 MB. Първо се създава LUKS дял с големина 260 MB върху твърдия диск /dev/sda. За целта се натиска бутона "New" и в отворения прозорец се прави следното описание на създавания дял:

След завършване на операцията (натискане на бутона "OK"), тя се повтаря и за втория диск (/dev/sdb):

След натискане на бутона "OK" двата необходими дяла за създаване на първия RAID1 масив са налични и може да се пристъпи към асемблирането му. То се извършва след натискане на бутона "RAID" в менюто за управление на дяловете и фалови системи. Като следствие от това се отваря прозорец, в който се посочва пътя до устройството на масива (в случая /dev/md0):

Създаването се извършва след натискане на бутона "OK" (Anaconda го използва към описанието на RAID масиви, което ще бъда налично след инсталацията във файла /etc/mdadm.conf). Следва появата на прозорец, в който да се декларира ниво на RAID масива (в случая RAID1), дял, тип на файловата система в дяла (ext2 за случая) и точка на монтиране след инсталацията (/boot):

С натискането на бутона "OK" изграждането на първият RAID1 масив завършва и може да започне изграждането на втория. Отново в менюто за създаване и управление на дялове и файлови системи се натиска бутона "New" в отворения прозорец се указва създаването на софтуерен RAID дял с капцитет равен на оставащото свободно пространство в по-малкия от двата твърди диска (в случая 18810 MB). В този случай обаче дялът ще бъде LUKS:

Ако се инсталира Fedora 9, при натискане на бутона "OK" ще бъде изискано двукратното въвеждане на паролата за криптиране на LUKS дяла. При Fedora 10 тя ще бъде изискана чак при преминаване към следващия етап от инсталацията.

Същата процедура се прилага и за създаване на LUKS дял за софтуерен RAID върху диска /dev/sdb:

След успешното създаване на двата LUKS дяла за софтуерен RAID, се преминава към асемблирането им. Натиска се бутона "RAID" и Anaconda ще асоциира устройството /dev/md1 към новосъздавания масив (устройството /dev/md0 е използвано вече за RAID1 масив за файловата система /boot):

Потвърждението на асоциацията се извършва с натискане на бутона "OK" и това води до отваряне на прозорец, в който да се декларира ниво на RAID масива (в случая RAID1), дял и LVM2 структурата в него:

Отново, за потвърждение на тези зададени опции се използва бутона "OK" и Anaconda ще отрази създадения LVM2 дял в менюто за създаване и управление на дялове и файлови системи. Също там се натиска бутона "LVM" за да се изградят групите и логическите дялове (както бе споменато вече това са swap дяла и този за кореновата файлова система с точка на монтиране /). Това довежда да отваряне на прозорец с менюта за указване или редакция на името на групата и създаване или промяна на логическите дялове в нея:

Оттук нататък следва да се декларират логически дялове, най-малко за swap и файловата система с точка на монтиране /. За да стане това за всеки един дял се натиска бутона "Add" от прозореца с менюта за указване или редакция на името на групата и създаване или промяна на логическите дялове в нея. Swap дяла обикновено се декларира пръв и той трябва да заема пространство равняващо се на удвоения капацитет на оперативната памет (за примера капацитета на оперативната памет е 1024 MB, следователно swap дяла ще има капацитет 2048 MB):

Натиска се бутона "OK" и създаденият логически дял ще се появи в списъка с дяловете на LVM2 групата VolGroup00:

Подобна на горната операция се извършва и за създаване на дяла за кореновата файлова система с точка на монтиране /:

и ако тя завърши успешно, създадения дял ще се появи в списъка с дялове за LVM2 групата VolGroup00:

С натискане на бутона "OK" става връщане към менюто за създаване и управление на дялове и файлови системи в Anaconda, като в списъка с дялове и файлови системи ще бъдат включени всички създадени с описаните по-горе операции:

Чрез натискане на бутона "Next" ще се продължи към следващите етапи на инстация. При инсталиране на Fedora 10, след натискането на "Next" ще се появи прозореца за въвеждане на паролата за криптиране на създадените от инсталатора LUKS дялове (при Fedora 9 той се появява в процеса на указване на създаване на такива):

След като в следващите етапи на инсталацията бъдат инсталирани пакетите на дистрибуцията и се стигне до инсталиране на зареждащата програма на операционната система (GRUB), ще се изведе съобщение за грешка:

3.5. Инсталиране върху LUKS базиран софтуерен RAID1 с използване на AES256

Описаният по-горе метод за инсталиране на Fedora върху софтуерен RAID1 масив използва подразбиращи се криптиращ алгоритъм (AES) и дължина на ключа (128 бита). По-долу е описан метод за инсталиране на Fedora върху софтуерен RAID1 масив, чиито съставящи LUKS дялове са криптирани с алгоритъм AES, но с дължина на ключа 256 бита, което е максимално достижимото ниво на сигурност за момента.

Тъй като Anaconda използва само споменатите по-горе подразбиращи се стойности за криптиращ алгоритъм и ключ, става ясно, че тя не може да създаде съставящите LUKS дялове и те трябва да се създадат с друг инструментариум преди инсталацията на дистрибуцията. Най-удобно за целта е използването на LiveCD дистрибутив на Fedora (задължително в последната официална версия). След като дистрибуцията от него се зареди, се пристъпва към създаването на LUKS дяловете. Този, който ги създава следва да има познания в използването на инструмента fdisk или други подобни за създаване на дялове върху твърд диск. С инструмента fdisk се създават четири дяла от тип "software RAID". Два от тях ще бъдат асемблирани впоследствие в дял за нуждите на файловата система с точка на монтиране /boot. Те трябва да са равни по размер, като за случай като този той е обикновено 256 MB. Останалите два дяла ще са с по-голям размер (който зависи от капацитета на твърдия диск). За примера ще се предполага, че дяловете, които ще се форматират като LUKS, са /dev/sda2 и /dev/sdb2. След като дяловете върху твърдия диск са изградени, се стартира терминал и се придобиват права на супер потребител (root):

Дялът /dev/sda2 се форматира като LUKS чрез командния ред:

след което същата процедура се повтаря за /dev/sdb2:

И в двата случая след изпълнение на командния ред ще се изведе диалогово меню, в което трябва да се потвърди желанието за форматиране на дяла:

Ако наистина дялът трябва да се форматира, се въвежда с главни букви символния низ "YES":

след което, ще се извърши форматиране на съответния LUKS дял и при успешнен изход от операцията, ще бъде изведено съобщението:

След успешното приключване на гореописаните операции, може да се премине към инсталационния процес. Системата се рестартира и вместо LiveCD носителя (CD, DVD) се поставя инсталационния и Anaconda се зарежда в графичен режим. В хода на инсталационния процес, след задаването на паролата за root, ще се детектира наличието на LUKS дялове и бъде изведен прозорец за въвеждането на паролата за декриптирането им:

Такъв прозорец би следвало да се изведе за всеки от наличните в системата LUKS дялове. Ако те са криптирани с една и съща парола, може да се маркира опцията "This is a global passphrase":

и подобно многократно и затрудняващо въвеждане на една и съща парола няма да бъде изисквано. В началото на процедурата за разделяне на дисковото пространство и създаването на файловите системи:

и с натискане на бутона "Next" се преминава към менюто за създаване и управление на дялове и файлови системи. Създадените преди това софтуерни RAID дялове следва да се виждат в списъка с дяловете:

Двата дяла с капацитет от 251 MB са очевидно тези дялове, предвидени за RAID1 масив, в който ще се изгради дял с ext2 файловата система, която накрая ще има точка на монтиране /boot. Останалите два по-големи дяла са LUKS дяловете, на основата на които ще се изгради физически дял за LVM2 структура, в която ще се намират логическите дялове за swap и за кореновата файлова система /. Пристъпва се към асемблирането на достъпните софтуерни RAID дялове в масиви. Първо се изгражда RAID1 масива за дяла с файловата система /boot. За целта се натиска бутона "RAID" и в отворения прозорец се заявява устройство на масива (в случая /dev/md0):

натиска се бутона "OK" се пристъпва към асемблиране на масива:

Асемблирането включва в RAID1 масив дяловете /dev/sda1 и /dev/sdb1. Създаденият на тяхна основа дял в масива ще съдържа в себе си ext2 файлова система (ще се създаде от Anaconda), с точка на монтиране /boot. За потвърждаване на създаването на масив, дял и файлова система с показаните по-горе параметри се натиска "OK" и промените се отразяват в менюто за създаване и управление на дялове и файлови системи:

Идва ред на асемблирането на двата налични LUKS дяла в RAID1 масив. Отново се натиска бутона "RAID" и се заявява устройсто за масива (в случая /dev/md1):

Заявката се потвърждава с натискане на "OK" и в отворения след това прозорец се указва нивото на RAID масива (в случая RAID1) и съдържанието на изградения в него дял (LVM2 структура):

Настройките се потвърждават с бутона "OK" и новият RAID1 масив ще се появи в списъка с дялове и файлови системи:

Последният етап е изграждане на LVM2 структурата. Натиска се бутона LVM и се отваря прозореца за създаване на LVM група и логически дялове в нея:

Минималният брой логически дялове, необходими за инсталацията на Fedora е два: един за swap и един за файловата система с точка на монтиране /. За изграждането на всеки един от тях се натиска бутона "Add" от прозореца с менюта за указване или редакция на името на групата и създаване или промяна на логическите дялове в нея. Swap дяла обикновено се изгражда пръв и трябва да заема дисково пространство, равняващо се на удвоения капацитет на оперативната физическа памет (за примера капацитета на оперативната памет е 1024 MB, следователно swap дяла ще има капацитет 2048 MB):

Натиска се бутона "OK" и създаденият логически дял ще се появи в списъка с дяловете на LVM2 групата VolGroup00:

и ако тя завърши успешно, това ще се отрази в списъка с дялове за LVM2 групата VolGroup00:

След като всички нужни логически дялове са създадени, се натиска бутона "OK" и LVM2 структурата ще се появи в списъка с дялове и файлови системи:

За да бъде завършен този специфичен етап от инсталацията и за да се премине към записването на промените и инсталиране на пакетите, се натиска бутона "Next". След като инсталацията на пакетите приключи, инсталаторът ще се опита да инсталира зареждащата програма на операционната система (GRUB) и най-вероятно ще се изведе съобщение за грешка:

3.6. Инсталиране на GRUB след инсталацията на дистрибуцията върху базиран на LUKS дялове софтуерен RAID

Описаният по-долу начин на инсталиране на GRUB е всъщност завършек на инсталацията на Fedora върху LUKS базиран софтуерен RAID1 масив, както това е описано по-горе. Причината инсталацията да се завършва постфактум, е проблем на инсталатора Anaconda. Този проблем се проявява в невъзможността Anaconda да постави върху твърдите дискове зареждащата програма на операционната система в случаите, в които Fedora се инсталира върху софтуерен RAID1 масив. Хронологично, проблемът се проявява веднага след като инсталацията на избраните пакети завърши и се премине към постинсталационните настройки. Индикация е появата на прозореца:

Причината, поради която GRUB не се инсталира, е непопълването от страна на Anaconda на файла /boot/grub/device.map, който е конфигурационен за инсталатора на GRUB grub-install. За да се попълни ръчно този файл, следва да се премине в т.нар. "rescue" режим на работа на Fedora. Този режим е достъпен за зареждане при зареждане на инсталационната медиа. Когато тя (CD, DVD) се постави в четящото устройство и системата се рестартира, се появява прозореца за избор на режим на инсталация, в който трябва да се избере "Rescue installed system" (изборът се извършва чрез стрелките на клавиатурата, след което се натиска "Enter"):

При зареждане на "rescue" режима на дистрибуцията, ще бъде изискано указването на някои работни настройки. Те се извършват в псевдографична среда, навигацията между елементите на която, се извършва със стрелките на клавиатурата, клавиша "Tab", селекция се прави чрез клавиша "Space" (големия клавиш за пауза), а потвърждението е натискане на "Enter". Първата настройка е за избор на език на интерфейса. В най-честия случай може да се зададе "English":

След това се избира клавиатурна подредба, например "us":

Инсталирането на GRUB не изисква мрежови функции така, че не е необходимо да се стартират мрежовите интерфейси:

След като необходимите настройки бъдат зададени на базата на описаните по-горе примери, от потребителя ще се изиска да направи избор за режима на достъп до инсталацията на Fedora върху RAID1 масива. Възможни са два режима - писане и прочит. Тъй като ще се извършват промени на конфигурацията на дистрибуцията, се избира "Continue" (т.е. режим на писане):

След този избор ще се появи прозорец с указания за влизане в кореновата файлова система на дистрибуцията чрез "chroot":

и след като указанията бъдат прочетени, чрез натискане на бутона "OK" окончателно се установява "rescue" режима на работа. При това автоматично се излиза от псевдографичната среда и се преминава в терминална:

Чрез chroot инструмента работната среда се пренася в кореновата файлова система на инсталираната дистрибуция:

и всички поледващи операции ще бъдат извършвани спрямо нейната файлова йерархия. Ако извикването на chroot от горния пример е успешно, се влиза в директория /boot/grub:

и се проверява се дали наистина файлът device.map е празен:

Ако курсорът премине на нов ред и не бъде изведена информация за съдържанието на файла, той е празен и в него следва да се създаде конфигурация за устройствата, върху които ще се инсталира GRUB. При условие, че RAID1 масивът е бил създаден върху твърдите дискове, представени в системата с устройствата /dev/sda и /dev/sdb, конфигурацията на инсталатора на GRUB във файла device.map може да се зададе така:

Ако твърдите дискове, върху които е реализиран RAID1 масива са представени с други устройства, различни от посочените по-горе, това трябва да се отчете при задаването на конфигурацията!

След това може да се пристъпи към инсталиране на GRUB върху двата диска:

При изпълнението на последните два командни реда, ще бъде изведена информация за успешността на инсталирането. Ако инсталирането е успешно и в двата случая, се излиза от "rescue" режима на дистрибуцията с двукратното изпълнение на exit:

При правилно изпълнение на командните редове по-горе и липсата на генерирани съобщения за грешка, би следвало след изваждане на инсталационната медиа и рестартиране на системата, дистрибуцията да се зареди от RAID1 масива.

Би било добре всеки системен администратор на Fedora базирани системи, да знае причината за двукратното инсталиране на GRUB в подобни случаи (върху всеки един от дисковете). Като се вижда по-горе, инструментът grub-install се извиква двукратно, по веднъж за всеки твърд диск, участващ в софтуерния RAID1 масив и причината, поради която се налага това е механизма на зареждането на дистрибуцията от софтуерен RAID1. При стартиране на системата, BIOS проверява за зареждаща операционната система програма върху устройствата, достъпни през каналите на носителите (твърдите дискове в случая). Ако не намери такава върху първия по старшинство канал, се преминава към втория канал и т.н. Доколкото тук става дума за RAID1 масив, който по замисъл реализира двойна резервираност, ако BIOS не намери (например поради дискова повреда), зареждащата програма GRUB върху диска /dev/sda, ще я потърси върху /dev/sdb и зареждането на операционната система ще започне от там.

4. Използване на cryptsetup за създаване, управление и достъпване на LUKS дялове

4.1. Форматиране на дял като LUKS

ВНИМАНИЕ! При форматирането на дял като LUKS цялата заварена информация върху дяла ще бъде унищожена.

За да може един дял да се форматира като LUKS, трябва той да бъде достъпен в системата и в момента на форматираненето да не е асоцииран с използваема файлова система. Няма значение върху какъв носител се намира дяла, който ще бъде форматиран като LUKS, стига той да позволява форматиране (запис).

Форматирането на дял като LUKS се извършва с опцията luksFormat на инструмента cryptsetup. Като аргумент се посочва пътя до дяла, който ще бъде форматиран и в някои случаи и опции, които ще бъдат коментирани по-долу. Например, ако трябва дялът /dev/mapper/VolGroup-storage да бъде форматиран като LUKS, може да се използва следния команден ред:

В диалогово меню потребителя ще бъде предупреден, че форматирането ще унищожи цялата предишна информация върху дяла и ще изиска съгласие за извършването му. За съгласие се приема въвеждането на символния низ YES, изписан с главни букви:

След това ще се изиска двукратното въвеждане на паролата за криптиране на LUKS дяла:

и ако при двете въвеждания тя е една и съща, ще се изведе съобщение за успешен край на форматирането:

ВНИМАНИЕ! Опциите и аргументите "-c aes-cbc-essiv:sha256 -s 256" са оптимални за това издание на dm-crypt и гарантират максимална за него ниво на сигурност!

Съществуват и опции, чрез които може да бъде избегнато извеждането на диалоговите менюта и процесът на форматиране да се автоматизира и ускори. Например, ако се налага да не се извежда диалога за съгласие (с въвеждането на низа "YES"), трябва да се използва опция "-q", например:

В този случай единственото диалогово меню ще е това за паролата. Възможно е и това меню да не бъде извеждано, ако паролата се намира във файл, читаем за cryptsetup. Преди употребата на файл за съхранение на паролата за криптирания дял, потребителя трябва да се запознае със съдържанието на Приложение III. Файлът с паролата се указва като пълен път, в края на списъка с аргументи, например:

В този пример паролата се чете от файла key.file, който се намира в директория /path/to.

Важно за отбелязване е, че извикването на паролата от файл е 100% еднозначна операция, ако съдържанието на файла е бинарно. Ако съдържанието е символно (ASCII, UTF-8 и др.), е възможно при последващите опити за декриптиране на дяла и въвеждането на паролата през диалоговото меню, тя да бъде отхвърлена. Това трябва да се отчете от този, който форматира дяла като LUKS!

4.2. Ръчно асоцииране на съдържанието на LUKS дял към dm-устройство в системата

Ръчното асоцииране на съдържанието на един LUKS дял към устройство на dm слоя на ядрото (dm - Device Mapper) на системата става с опцията luksOpen на инструмента cryptsetup. За да може асоциацията да се извърши следва командния ред да се изпълни с права на супер потребител (root) и да бъде известна паролата за декриптиране на LUKS дяла:

Този примерен команден ред ще асоциира съдържанието на LUKS дяла /dev/mapper/VolGroup00-storage към устройството /dev/mapper/luks-storage. Паролата за декриптиране на дяла ще бъде изискана в диалогово меню:

и след правилното й въвеждане ще се създаде устройството /dev/mapper/luks-storage, към което системните процеси и инструменти могат да се обръщат като към стандартен дисков дял.

Възможно е паролата да бъде изчетена от файл вместо от диалогово меню. В този случай с опция -d трябва да се подаде като аргумент пълния път до файла съдържащ паролата:

За подробности относно прочита на паролата от файл, виж Приложение III.

4.3. Добавяне на ключ за декриптиране в LUKS дял (създаване на слот)

Съществува разлика между понятията "ключ" и "парола". Ключът е число с фиксиран разред, което служи на криптографския алгоритъм, който го използва, за криптиране и декриптиране на данните. Паролата е обикновено символен низ, на чиято основа се генерира ключ, като се използват т.нар. "хеш-функции".

Криптирането и декриптирането на LUKS дяла се извършва с ключ, който никога не се въвежда от администратора на системата - ключ на дяла. Този ключ се генерира още при форматирането на дяла като LUKS и след това се криптира с паролата/ключа на администратора, иницирал създаването му. Криптираният по този начин ключ на дяла се съхранява като "slot" обект (в служебната част на дяловата структура). Когато дялът не е достъпен в системата и съдържанието му трябва да се направи видимо за нея (например монтиране на съдържаща се в него файлова система), се въвежда паролата за слота, на нейна основа се пресмята ключа, чрез който се декриптира слота, в който се съдържа ключа на дяла. Извлеченият дялов ключ се подава на ядрото, LUKS дяла се декриптира и съдържанието му става достъпно в системата. През цялото време, през което съдържанието е достъпно в системата, ключа на дяла стои в паметта, за да може чрез него да се извършва криптиране и декриптиране на информацията от и към този дял.

Възможно е ключът на дяла да бъде криптиран и с ключове съответстващи на други пароли, което води до създаването на нови слотове (по един за всеки ключ/парола). Ползата от много слотове е, че съдържанието на дяла може да бъде направено достъпно чрез повече от една пароли. Например, от гледна точка на системната администрация това означава, че повече от един оператор може да декриптира ключа на дяла и да прави дяловото съдържание достъпно в системата. Тази функционалност трябва да се използва с повишено внимание и по-скоро да бъде метод за предотвратяване на загуба на достъп до съдъражнието на LUKS дяловете, отколкото да служи за разширяване на достъпа за достъп до криптирания дял. Последното означава, че може да се създаде (най-малко) втори слот, чиято парола да може да послужи за декриптиране на LUKS дяла, ако тази за първия слот бъде забравена или загубена. Това обаче предполага стриктното и сигурно съхранение на паролите за всеки един от слотовете.

За да се добави слот към един LUKS дял трябва дялът да е вече създаден и върху него да има създаден поне един слот, чиято парола да е известна. След това на инструмента cryptsetup се подава опция luksAddKey, например:

В първото диалогово меню първо се въвежда паролата за декриптиране на слота, който оператора използва, a във второто се въвежда два пъти новата парола, на основата на която ще се създаде следващия стол (в примера това е слот с номер 1). Важно е да се отбележи, че в списъка с опции и аргументи на cryptsetup се задава пълния път до LUKS дяла в системата (в случая това е /dev/mapper/VolGroup00-storage), а не до декриптираното устройство, съответстващо на този дял!

Възможен е прочит на паролата от файл. В този случай пълният път до файла с паролата се подава като аргумент на опцията -d:

За подробности относно прочита на паролата от файл, виж Приложение III.

Максималният брой слотове за един LUKS дял е 8. Номерират се с числа от 0 до 7. За да бъде направен преглед кои слотове са използвани, може да се използва опцията luksDump при извикване на cryptsetup за даден LUKS дял:

Примерният изход от изпълнението на този команден ред има вида:

От него се вижда, че са използвани два слота, с номера 0 и 1. За получаването на този резултат не се изисква въвеждане на парола за някой от слотовете, защото хедър частта на LUKS дяла не е криптирана.

Как dm-crypt базираната система за управление на LUKS дялове разбира паролата за кой точно слот е въведена? Както се вижда в командния ред по-горе, няма указване на индекс или номер на слота. Въпреки това ключа за дяла се декриптира с въведената парола. Това, което реално става в случая е, че от въведената парола се пресмята ключ за слот и с него започват да се тестват всички налични слотове, докато не бъде декриптиран поне един от тях (и от него не се извлече ключа за дяла).

Друга важна особеност е, че измежду слотовете на LUKS няма старшинство и йерархия. Всички слотове са равнопоставени. Поради това, ако някой потребител/оператор на системата има слот върху LUKS дяла, той може да създаде нов слот. Това е един от доводите да има много стриктна политика за създаване на слотове в LUKS дялове. Съществува и възможност ключа на дяла да бъде прочетен от всеки, който има права на супер потребител (root). Причината е, че този потребител има достъп до страниците на паметта, където се намира ключа след като LUKS дяла се декриптира. Такъв достъп също следва да се рестриктира.

4.4. Премахване на парола за декриптиране от LUKS дял (премахване на слот)

Както може да бъде добавена парола за създаване на нов слот в LUKS дял, така е възможен и обратния процес. Премахване на слот може да извърши всеки оператор на системата, който има негов слот и парола за него в LUKS дяла. Преди да се премахне даден слот, трябва да е известен неговия номер. Преглед на слотовете в един LUKS дял може да се извърши чрез извикване на инструмента cryptsetup с опция luksDump, например:

Примерният изход от изпълнението на този команден ред има вида:

От изхода се вижда, че са използвани два слота, с номера 0 и 1. За получаването на този резултат не се изисква въвеждане на парола за някой от слотовете, защото хедър частта на LUKS дяла не е криптирана.

Изтриването на слот с номер 1 от LUKS дяла с устройство /dev/mapper/VolGroup00-storage може да се извърши с опцията luksDelKey на cryptsetup по следната схема:

Като последен аргумет е посочен номера на слота. При успешно изтриване ще се изведе съобщението:

Въпреки това проверка дали наистина слота е изтрит може да се направи с luksDump, както вече е показано по-горе.

Важна особеност на процеса на изтриването е, че не се изисква въвеждането на паролата за който и да е слот на LUKS дяла, а единствено изпълнението на командния ред трябва да става с права на супер потребител (root). Операцията по изтриване на слот следва да се извършва с повишено внимание, поради опасност от изтриването на погрешен слот, което може да направи съдържанието на LUKS дяла недостъпно.

4.5. Деасоцииране на LUKS дял от устройство в /dev/mapper

Деасоциирането на LUKS дял от устройство в /dev/mapper се извършва чрез опцията luksClose на инструмента cryptsetup. След опцията се указва като аргумент името на устройството, от което трябва да се деасоциира LUKS дяла. Например, деасоциирането на LUKS дяла от устройството /dev/mapper/luks-storage може да се извърши така:

4.6. Проверка дали един дял е LUKS

Инструментът cryptsetup има опция, чрез която може да се провери дали един дял е LUKS или не. Тази опция е isLuks. Като аргумент се задава пътя до дяла, който ще се проверява. Ако проверяваният дял е LUKS, няма да бъде изведено никакво съобщение, докато ако дялът не е LUKS, ще бъде изведено съобщение от типа "/dev/hda1 is not a LUKS partition". Например, проверката дали дяла /dev/sda4 е LUKS може да се извърши така:

4.7. Получаване на UUID стойността за LUKS дял

Възможно е получаването на UUID стойността на LUKS дял чрез опцията luksUUID на инструмента cryptsetup. Единственият необходим аргумент след опцията е пълния път до дяла. Например, получаването на UUID стойността за дяла с пълен път /dev/sda4 може да се узвърши така:

Резултатът е стойността на UUID идентификатора:

5. Използване на /etc/crypttab за автоматизирано монтиране на LUKS дялове при зареждане на системата

Както Fedora, така и Red Hat Enterprise Linux 5 (и дериватите му), имат възможността да асоциират LUKS дялове към системни устройства при зареждане на системата. Тази възможност се базира на два компонента в процеса на зареждането на системата - инициализиращ скрипт и конфигурационен файл. Инициализиращият скрипт се намира във файла /etc/rc.d/rc.sysinit, а конфигурациите в /etc/crypttab. Единствената разлика между Fedora и Red Hat Enterprise Linux (и дериватите му) по отношение на автоматизираното монтиране на LUKS дялове при зареждане на системата е, че във втория тип дистрибуция (засега) няма възможност за монтиране на кореновата файловата система / от LUKS дял.

Синтаксисът на /etc/crypttab е сравнително лек. За всеки LUKS дял, който трябва да бъде асоцииран към устройство в /dev/mapper при зареждане на системата, се използва (един) ред с описания. В най-честия случай описанието в реда използва шаблона:

Ето и конкретен пример на такова описание за LUKS дялът с физически път /dev/hdc1, който при зареждане на системата трябва да се асоциира към устройството /dev/mapper/luks-storage:

Добра практика е указването на LUKS дяла чрез UUID стойността му. По този начин се реализира назависимост от смяна на канала, чрез който физическия носител е прикачен към системата (най-често IDE или SATA канал). Идеята на UUID идентификаторите на файловите системи и приложението й за LUKS е описано в Приложение IV. Получаването на UUID стойността за даден LUKS дял може да стане чрез опцията luksUUID на инструмента cryptsetup и по описания в Приложение IV начин. Ето и практически пример как LUKS дялът с UUID=a792979a-ce88-4a3e-ae64-fe866a760513 може да бъде асоцииран към устройството /dev/mapper/luks-a792979a-ce88-4a3e-ae64-fe866a760513:

Записите за асоциция в /etc/crypttab влизат автоматично в сила само и единствено при зареждане на системата (когато се изпълнява скрипта /etc/rc.d/rc.sysinit), и то след въвеждането на парола за поне един от слотовете на съответния LUKS дял. Ако в третата колона на всеки ред стои параметър none или дори той е изпуснат, зареждащият скрипт rc.sysinit ще изиска ръчното въвеждане на паролата на кой и да е от слотовете на LUKS дяла. Информация относно слотовете на LUKS дяловете може да бъде намерена в "Използване на cryptsetup за създаване, управление и достъпване на LUKS дялове". Изпълнението на /etc/rc.d/rc.sysinit става преди монтирането на файловите системи по описанието в каталога /etc/fstab. Целта е файлови системи, намиращи се в LUKS дялове, да могат да бъдат монтирани при зареждане на системата чрез описание на LUKS дяла в /etc/crypttab и описание на монтажа на файловата система в LUKS дяла в /etc/fstab.

Ето пример за взаимодействието на описанията в /etc/crypttab и тези в /etc/fstab. За примера ще се разгледа LUKS дял с UUID=a792979a-ce88-4a3e-ae64-fe866a760513, в който се намира ext3 файлова система, която трябва да монтира като /storage. Описанията в двата файла са както следва:

По този начин, при зареждане на системата, ще се изиска въвеждане на парола за някой слот на LUKS дяла. Ако тя бъде въведена, ще се създаде устройството /dev/mapper/luks-a792979a-ce88-4a3e-ae64-fe866a760513, ext3 файловата система в което ще бъде монтирана като /storage.

Накрая трябва да се отбележи, че е възможно на мястото на none да стои пълен път до файл, който да съдържа паролата за декриптиране на LUKS дяла. Подобна практика не се препоръчва освен в изключителни случаи и изисква ясни и задълбочени познания в системната администрация. По-долу е посочен пример за особен случай, при който вместо файл, съдържащ паролата за декриптиране/криптиране на дяла, е посочен изхода на генератора на случайни числа /dev/urandom. Това обаче е твърде специфично използване на такъв източник на парола и не може да бъде практика за случаите на дялове, които са хранилища за информация.

6. Автоматизирано създаване на LUKS базирани /tmp, /var/tmp и swap при зареждане на системата

Съвместното използване на инициализиращият скрипт /etc/rc.d/rc.sysinit и каталога с конфигурации /etc/crypttab дава възможност за автоматизирано създаване на LUKS дялове и форматиране на файловите системи в тях. Тези процеси се извършват при зареждане на системата. Каква е целта им? Swap дяла, както и файловите системи за /tmp и /var/tmp (когато тези файлови системи са в отделни дялове), най-често съдържат в себе си временна информация, която касае текущата сесия на системата (от стартирането до следващото й спиране). В 99% от случаите тя не е нужна след рестартиране, а в нея се съдържат и прекалено много системни данни, които застрашават не само сигурността на системата, но и личния живот и служебната информация на потребителя. Разбира се, това касае случаите, в които не може кореновата файлова система с точка на монтиране / да бъде в LUKS дял (например при Red Hat Enterprise Linux 5 и дериватите му).

Идеята в този случай е LUKS дяловете, в които се съдържат посочените по-горе файлови системи, да се форматират автоматично всеки път при зареждане на системата, за всеки от тях да се създаде слот с парола, взета от генератора на случайни числа (през /dev/urandom) и да се асоциира към устройство в /dev/mapper. Така потребителят не въвежда парола за асоцииране за тези LUKS дялове, а и в общия случай не я знае. След това файловите системи от създадените в /dev/mapper устройства се монтират във файловата йерархия на системата или се използват за swap (зависи кой дял каква файлова система съдържа). При тази схема данните от тези дялове се заличават при всяко стартиране на системата чрез форматиране и криптиране на дяла с нова парола. От друга страна данните в дяловете стават недостъпни за повторен прочит веднага след спиране на системата. Това изключва автоматично поставянето в такива дялове на информация, която трябва да бъде съхранявана продължително време и независимост от рестартирането на системата. Тази важна подробност следва да се отчита от потребителя!

Като начало се прави описание на LUKS дяловете, които трябва да се форматират при всяко зареждане на системата, в /etc/crypttab. При това се спазва следния шаблон на ред за всеки от дяловете:

Вместо от истински файл съдържащ парола, паролата се чете от изхода на системния генератор на случайни числа /dev/urandom и това се указва на трета позиция в шаблона на реда. Типовете файлови системи, които могат да се указват в последната позиция на шаблона на реда, са swap и tmp. Когато LUKS дяла ще съдържа в себе си swap, се избира swap, а в случаите, в които ще съдържа файловите системи за /tmp и /var/tmp, се избира tmp (tmp означава форматиране на файловата система като ext2). Като криптографски алгоритъм за криптиране на LUKS дяла към момента, следва да се използва комбинацията cipher=aes-cbc-essiv:sha256. Ето пример за декларирането на три LUKS дяла в /etc/crypttab, като първия в реда на деклариране ще се използва за swap, втория за /tmp, а третия за /var/tmp:

Докато за swap дяла няма проблеми да се направи запис в /etc/fstab, например:

то не така чисто изглежда решението за файловите системи в устройствата предвидени за /tmp (в примера luks-53259b6c-060a-461a-86f5-43c875e66cd6) и /var/tmp (в примера luks-3594d739-138e-4dec-98eb-00b179d33c9c). Тези файлови системи не могат директно да бъдат указани като точки за монтиране в /etc/fstab и причина за това е необходимостта от изграждане върху тях на SELinux контекстите, които би следвало да имат. За да се реши този проблем могат да бъдат изградени System V базирани услуги, чиято задача е последователно да монтират файловите системи в /tmp и /var/tmp, и веднага след това да създадат SELinux контекстите върху тях (последната операция се извършва чрез инструмента restorecon). По-долу е представена услуга, която обединява в себе си всички необходими операции и носи името името lukstmp.

Услугата lukstmp трябва да има своя конфигурация, съдържаща имената на устройства в /dev/mapper, които съдържат ext2 файловите ситеми, които услугата да монтира. Ето пример за такава конфигурация:

В нея променливата ${TMP} получава за стойност името на устройството /dev/mapper/luks-53259b6c-060a-461a-86f5-43c875e66cd6, което съдържа ext2 файловата система за монтиране като /tmp. Аналогично стойността на променливата ${VARTMP} е устройството /dev/mapper/luks-3594d739-138e-4dec-98eb-00b179d33c9c с ext2 файлова система, която ще бъде монтирана като /var/tmp. Ако се следва йерархията на System V конфигурациите, посочените по-горе два реда трябва да се съдържат във файла с името на услугата, т.е. /etc/sysconfig/lukstmp. Този файл не бива да е писаем за непривилигеровани потребители и следва да е собственост на потребител root и група root. Конфигурацията ще се чете от скрипта на услугата, който ще има следното съдържание:

То се копира във файла /etc/rc.d/init.d/lukstmp и той се обявява за изпълним:

Накрая услугата lukstmp се регистрира за зареждане в нивата на стартиране на системата, описани за заглавната част на скрипта. В случая това са стартови нива 2,3,4 и 5:

Оттук нататък при стартиране на системата и успешното асоцииране на LUKS дяловете към устройства в /dev/mapper, услугата lukstmp ще монтира автоматично съдържащите се в тях файлови системи съответно в /tmp и /var/tmp, и ще задава SELinux контекстите им.

7. Създаване на LUKS дялове върху преносими носители и автоматичното им монтиране

Преносимите носители, върху които се изграждат LUKS дялове най-често са USB флаш устройства. Съществуват някои прнципни постановки, които трябва да се спазват. Най-важната от тях е, че ако преносимото устройство няма нужда да съдържа върху себе си системен дял, а ще служи само като мобилно хранилище на файлове, то трябва да се форматира с файлова система, която да не поддържа върху себе си собственост върху файловете. Най-често като такава се използва FAT32. Монтирането на файлови системи от външни носители, които поддържат върху себе си задаване на собственост върху файловете, носят опасност за сигурността на системата. Причината е, че ако те са съставяни от недобросъвестен потребител, могат да съдържат изпълними за всички потребители на системата файлове със SUID на root и така да се реализират елеваторни привилегии. Именно затова, ако USB флаш носителя ще служи само като хранилище за файлове, той трябва да съдържа LUKS дял, в който да има изградена FAT32 файлова система.

В случаите, в които преносимите устройства са външни SATA твърди дискове, е възможно с определени случаи, да се създават системни дялове, които да съдържат ext3, xfs и други файлови системи, поддържащи собственост върху обектите в тях.

В Linux USB флаш устройствата се разпознават като SATA носители и обикновено се представят като устройство в йерархията /dev/sdX, където X е цяло число. Върху това устройство трябва да се създаде LUKS дял по описаната по-горе методика, който да се асоциира като устройство в /dev/mapper (чрез luksOpen). Върху него се изгражда FAT32 файлова система (чрез инструмента mkfs.vfat). След това следва деасоцииране на устройството (с luksClose) и изваждане на устройството от системата. При повторно включване на USB флаш устройството в система, в която има отворена от непривилигерован потребил GNOME или KDE десктоп сесия, ще се появи прозорец за въвеждане на паролата за поне един от слотовете върху LUKS дяла и при правилното й въвеждане FAT32 файловата система ще бъде достъпна за четене и запис от потребителя. Цялото това ниво на автоматизация е възможно благодарение на HAL демона. Нужно е да се има предвид, че в този случай останалите потребители нямат достъп до файловата система, но такъв може да бъде получен от root. Ако не бива никой друг (дори root), да има достъп до съдържанието на файловата система, освен монтиралия я потребител, USB носителя не бива да се монтира на система, в която някой друг освен потребителя знае root паролата.

Ако в системата, в която ще се монтира файловата система от LUKS дяла на USB флаш устройството, няма графична среда или съответния десктоп, операциите трябва да се извършат ръчно, с права на root (правомощия за това могат да се дадат на непривилигерован потребител с описание в /etc/sudoers). Това означава ръчно да се създаде асоциация на LUKS дяла от устройството към устройство в /dev/mapper (чрез luksOpen), след което файловата система да се монтира в празна директорията чрез инструмента mount.

8. LUKS дялове върху loop устройства

8.1. Създаване на LUKS дялове върху loop устройства

В Linux съществува възможност за създаване на устройство за дял, което да сочи към файл (макар това да не е единствената възможност). С други думи, това е начин да се дефинира псевдо дял, чието съдържание се намира във файл (най-често файл върху локално достъпен носител). Тази възможност е достъпна и за LUKS дялове - те могат да се намират върху файл, чието съдържание да се достъпва през loop устройство.

Устройство за дял от тип loop се създава благодарение на модула loop в ядрото. Информация за този модул може да се получи от команден ред така:

Този модул се зарежда автоматично в паметта при първата операция по създаване на loop устройство, след зареждането на системата. Подразбирщият се максимален брой създаваеми loop устройства е 8. В някои случаи този брой е малък и може да се увеличи (но не повече от 256) при зареждането на модула с опция max_loop=N, където N е максималния брой достъпни loop устройства. Указването на опцията и параметъра й става на нов ред във файла /etc/modprobe.conf. Например, осигуряването на 16 loop устройства след зареждането на модула, се описва така:

Ако задаването е извършено при вече зареден модул, то няма да влезе в сила докато не се отзареди и зареди модула. За да се отзареди модула loop, трябва да се премахнат всички създадени към момента loop устройства, а такава операция понякога изисква рестартиране на системата или спиране на някои услуги и демонтиране на файлови системи.

Файлът за асоцииране към loop устройството, се създава с големина равна на тази на дяла, който ще бъде изграден и първоначално се запълва с нули. За тази цел се използва инструмента dd от състава на пакета coreutils (този пакет по принцип задължително присъства в системата). Той чете източника на нули /dev/null и ги записва във файла. Записът става на порции, като се указва тяхната големина и брой. Например, за да се създаде файла с име file.img и да се запълни с 1.1GB нули, може да се използва команден ред от вида:

След като такъв файл с нули бъде създаден, се изгражда loop устройството, асоциирано към него:

Оттук нататък /dev/loop0 може да се третира като дял, който може да бъде криптиран и в който може да бъде създадена файлова система. Ако устройството /dev/loop0 е вече заето, се използва следващото свободно, напр. /dev/loop1 и т.н.

След като loop устройството е създадено, може да се пристъпи към форматиране на дяла в него като LUKS:

За целта се използва шифъра aes-cbc-essiv:sha256 с дължина на криптиращия симетричен AES ключ от 256 бита. След изпълнение на командния ред ще се стартира диалогово меню, в което извършителят на форматирането следва да потвърди желанието си за форматиране, като въведе с главни букви низа "YES" след двуеточието:

След като желанието за форматиране бъде потвърдено, диалоговото меню ще продължи с изискване за двукратното (втория път за потвърждение) въвеждане на паролата за криптиране/декриптиране на дяла:

и ако при двете въвеждания тя е една и съща, ще се създаде LUKS дяла и ще се изведе съобщение за успешен край на форматирането:

Оттук нататък, до следващо форматиране, в асоциирания с loop устройството файл ще се съдържа структура на LUKS дял.

Горният команден ред за форматиране допуска вариации в опциите, които могат да бъдат намерени в man и info страниците на инструмента cryptsetup. Една от опциите е използването на файл съдържащ паролата. За подробности виж Приложение III.

8.2. Създаване на устройства за loop базирани LUKS дялове в /dev/mapper

В /dev/mapper могат да се създават устройства за декриптираните и готови за прочит и запис LUKS дялове. Това означава, че за да се създаде устройството, трябва LUKS дялът в него трябва да е създаден предварително. Освен това трябва да е известна паролата за декриптирането му. Ако тези условия са налице, създаването на устройство за loop базиран дял в /dev/mapper може да се извърши с командния ред:

Веднага след изпълнението му в диалогово меню ще бъде изискана паролата за декриптиране на дяла:

и създаването на устройството за LUKS дяла ще се извърши само, ако тя бъде въведена правилно и бъде изведено съобщението:

В конкретният пример, за LUKS дяла в /dev/loop0 ще бъде създадено устройството /dev/mapper/loop0. Както се вижда, последният аргумент на командния ред е името на устройството, с което дяла ще бъде достъпен в каталога /dev/mapper.

Използването на парола от файл е описано в Приложение III.

8.3. Създаване на файлови системи в loop базирани LUKS дялове

Създаването на файлова система в LUKS дял по нищо не се различава от създаването на файлова система в друг тип дял. Разбира се, размерът на дяла трябва да отговаря на минималните изисквания за съответния вид файлова система. Например, форматирането на асоциирания към устройството /dev/mapper/loop0 LUKS дял, като ext3 файлова система, може да стане така:

UUID идентификатора на създадената файлова система може да се изведе чрез инструмента vol_id (виж Приложение 4).

8.4. Монтиране на файлови системи от loop базирани LUKS дялове

В рамките на разглежданите дистрибуции (Fedora и Red Hat Enterprise Linux 5), няма автоматизирана процедура за монтиране на файлови системи от loop базирани LUKS дялове. Под автоматизирана процедура се разбира такава, в рамките на която при зареждането на системата се създава loop устройство, изисква се паролата за декриптирането на LUKS дяла, след което се създават устройствата в /dev/mapper и накрая се монтират съдържащите се в тях файлови системи (описани в каталога /etc/fstab).

Винеги е възможно обаче извършването на ръчен монтаж. Той става по следния начин. Файлът, съдържащ LUKS дял, се асоциира към loop устройство (напримр /dev/loop0):

(за примера това е файла /home/test/file.img). След това се създава устройство за дяла в /dev/mapper:

В диалогово меню ще бъде изискана паролата за декриптиране на дяла:

и след успешното й въвеждане ще се изведе съобщението:

Възможно е въвеждането на паролата не от диалоговото меню, а от файл, както това е описано в Приложение III.

Файловата система в полученото устройство /dev/mapper/loop0, може да се монтира в зависимост от нейния тип. Ако в дяла се съдържа LVM2 структура, тя се прочита автоматично от ядрото и за всеки логически дял се създават устройства. Например, ако в LUKS дяла се съдържа файлова система, разпознаваема като тип от ядрото, тя може да се монтира в директорията /mnt/luks така:

Ако са нужни специфични опции за монтажа, те се указват като опции на mount. По-добър метод за монтиране е чрез използване на UUID стойността на файловата система, която ще се монтира. Използването на UUID индикаторите с описано в Приложение IV. Например, ако UUID стойността на файловата система в дяла /dev/mapper/loop0 е 0bab2f27-f4a7-475f-9498-56906f0120ab, монтирането й става лесно чрез командния ред:

8.5. Деасоциация на loop базирани LUKS дялове

Деасоциацията е процес, при който LUKS дяла се "откача" от създаденото за него устройство в директория /dev/mapper. Това не означава, че информацията от LUKS дяла се унищожава. При деасоциацията се спира достъпа до декриптираното съдържание в LUKS дяла. В произволен момент обаче може да бъде създадено устройство за LUKS дяла в /dev/mapper и съдържанието в него отново да стане достъпно в системата.

Ако loop базиран LUKS дял трябва да се деасоциира от създаденото за него устройство в директория /dev/mapper, първо се спират процесите на запис върху съдържащата се в дяла файлова система. След това тя се демонтира с umount. Например, ако съдържащата се в LUKS дяла файлова система е била монтирана като /mnt/luks, демонтирането й може да се извърши така:

Ако демонтажът на файловата система не може да се извърши и е съпроводен с извеждане на съобщения за заетост на дяла, които могат да бъдат пренебрегнати (по преценка на оператора на системата), umount може да се извика с опция -l:

Тази операция е рискова и следва да бъде извършвана с ясна представа за възможните последствия от нея! Ако LUKS дялът съдържа в себе си LVM2 структура, демонтажът следва да се извърши за всички логически дялове (ако те са били монтирани).

След като файловата система бъде демонтирана, може да се пристъпи към деасоциацията на LUKS дяла от асоциираното към него устройство. За целта се използва инструмента cryptsetup с опция luksClose и аргумент името на устройството в директория /dev/mapper. Например, деасоциацията на LUKS дяла от устройството /dev/mapper/loop0 може да се извърши със следния команден ред:

Ако деасоциирането е протекло успешно, курсорът ще премине на нов ред и няма да бъде изведено никакво съобщение. От този момент устройството /dev/mapper/loop0 ще престане да съществува, тъй като към него няма да има асоциация. В случай, че файлът съдържащ LUKS дяла трябва да се деасоциира и от loop устройството, може да се използва инструмента losetup (в примера за устройството /dev/loop0):

Приложения

I. Софтуерни RAID масиви в Linux

ВНИМАНИЕ! Това приложение представя кратко ръководство за създаване, управление и използване на софтуерни RAID масиви в Linux. То не може да се разглежда като пълно ръководство по темата. Подробно ръководство може да бъде намерено в рамките на проекта TLDP.

1. Предимства и недостатъци на софтуерните RAID масиви

Целта на RAID технологията е да даде резервираност при управление на дисковото пространство. Добро описание на технологията за начинаещи има в Wikipedia.

Софтуерният RAID масив е такъв масив, чието изграждане и управление се извършва от ядрото на операционната система (в случая от Linux ядрото). За разлика от софтуерния RAID масив, хардуерно изградените и управлявани RAID масиви се изграждат и управляват от хардуерни устройства - RAID контролери. В случая на хардуерно базиран RAID масив, ядрото на операционната система осигурява само интерфейс към масива, докато при софтуерно базирания, ядрото извършва всички операции: от създаването, през управлението, до достъпа.

Дори по беглото описание по-горе става ясно, че софтуерно базираният RAID масив е слой в операционната система. Поради тази причина той ангажира нейните ресурси в значителна степен, което означава, че използването му е лимитирано от тяхното количесто и качество. Натоварването на софтуерния RAID масив влияе на работата на системата като цяло, а от друга страна производителността му зависи от моментното натоварване на същата тази система. Всичко това показва, че изграждането и използването на софтуерни RAID масиви е компромисно решение. То трябва да се прилага в системи, в които потреблението на ресурси от масива не е високо и системата не се натоварва значимо от други процеси и приложения. Подходящи за използване на софтуерен RAID са системи, които не са критични: работни станции, лаптопи, малки офисни сървъри и др.

Софтуерният RAID масив се изгражда от дялове, които се намират върху едно или повече дискови устройства, достъпни в системата. За разлика от него, хардуерно базираният RAID масив не дефинира дялове, а практически работи директно с дисковете (носителите), съобразявайки се с тяхната геометрия. Това е една от причините добрите хардуерни контролери да позволяват динамичната замяна на дискови носители по време на работа на системата, което е немислимо при софтуерния RAID - там системата се спира, за да се подмени дефектиралия диск, след което тя се стартира и се изгражда дял с определена от RAID структурата големина и чак след това се асемблира RAID масива. Казаното посочва защо софтуерен RAID не може да се използва при критични системи от гледна точка на непрекъснатата им работа - защото не позволява динамичната подмяна на носители.

Съществуват RAID контролери (обикновено нискобюджетни), които реално не създават и не обслужват хардуерно RAID масиви. За някои от тях това е поведение под определена операционна система. Например, Linux ядрото поддържа голям набор RAID контролери, но само на ниско ниво. Това означава, че контролерът само предоставя каналите си, на които могат да се прикачават твърди дискове и по този начин увеличава броя дискови устройства в системата, без обаче при това сам да създава и управлява RAID масиви. В този случай единственият изход е да се създаде софтуерен RAID масив с дялове върху дисковете, достъпни през каналите на контролера. Други нискобюджетни контролери разчитат на процесора на системата за извършване на повечето операции и нямат собствен процесор, което ги прави натоварващи и неефективни.

В ядра 2.6 се поддържат следните нива на софтуерни RAID масиви: 0, 1, 4, 5, 6, 10, вкл. multipath (за подробности виж цитираната статия в Wikipedia по-горе).

2. Създаване на софтуерни RAID масиви

Софтуерните RAID масиви се създават на два етапа. Първият включва изграждането на дялове върху твърдите дискове, които са основата на RAID масива. В зависимост от нивото на изграждания масив, се определя броя необходими дялове. Например, за RAID1 масив са нужни два дяла, равни по големина. Уместно е те да бъдат върху различни твърди дискове. Вторият етап включва изграждането на масивите. Това става чрез инструмента mdadm.

Най-често използваното ниво на софтуерен RAID масив е 1 (RAID1). По-долу ще бъде даден пример за изграждането на такъв масив. Предполага се, че в системата са налични два твърди диска, достъпни като /dev/sda и /dev/sdb. Чрез fdisk върху всеки един от тях се създава дял, съответно /dev/sda1 и /dev/sdb1 и за двата се указва тип "software RAID".

След това с инструмента mdadm се създава RAID масив с ниво 1:

При успешно създаване на масива, той ще е достъпен като устройството /dev/md0. То може да се разглежда като дял върху твърд диск и върху него да се извършват съответните операции, например създаване на файлова система ext3:

която след това да се монтира в дървото на кореновата файлова система.

За да може създаденият в горния пример софтуерен RAID масив да се асемблира при всяко зареждане на системата, той трябва да се опише в конфигурационния файл /etc/mdadm.conf (ако до момента не е бил изграждан масив, този файл няма да съществува):

3. Универсални идентификатори на софтуерните RAID масиви

UUID е универсален числов идентификатор за RAID масив. Той е може да се разглежда като съставен от четири осемцифрени шестнадесетични числа, разделени помежду си с двуеточие ":", например:

Всичките четири осемцифрени шестнадесетични числа са псевдослучайни. Сумарната комбинация, която те реализират трябва да е уникална за всеки от RAID масивите в една система и да не позволява наличието на колизии. Генерирането на комбинацията става автоматично при създаване на RAID масива, като за източник на псевдослучайни числа се използва генератора на случайни числа в системата. След като UUID се генерира, се записва върху всеки един от участниците в RAID масива, който се създава в момента. Основната полза от използването на UUID е автоматичното асемблиране на масива от съставните му дялове, без да се знае предварително физическия път до тях. Ядрото сканира достъпните в системата дялове и проверява кои от тях са обявени като тип "софтуерен RAID". След като този списък бъде съставен, се проверява кои от дяловете в него имат едно и също UUID и те биват асемблирани в масив, съгласно инструкциите за това в конфигурационния файл /etc/mdadm.conf. Подобно високо ниво на автоматизация при изграждането на софтуерни RAID масиви, предоставя в системата мобилност и свобода на монтаж на дисковите устройства. Декларирането на масив в /etc/mdadm.conf се прави без да се изреждат дяловете, които го съставят, а вместо това се указва само неговия UUID. Например, декларацията в /etc/mdadm.conf:

декларира RAID1 масив (level=raid1), представен в системата като устройство /dev/md0 и съставен от два дяла с UUID=9187a482:5dde19d9:eea3cc4a:d646ab8b.

Управление на софтуерните RAID масиви и фини настройки

Повече за управление на софтуерните RAID масиви и извършването на фини настройки върху тях, може да бъде намерено в man и info страниците на mdadm.

II. Създаване и управление на LVM2 дялове в Linux

ВНИМАНИЕ! Това приложение представя кратко ръководство за създаване и управление на физически LVM2 дялове и съдържащите се в тях логически групи и дялове. Тя не може да се разглежда като пълно ръководство за работа с LVM2 и не отменя нуждата от такова. Подробно ръководство за работа с LVM2 може да бъде намерено в рамките на проекта TLDP.

1. Създаване на LVM2 дял

LVM2 дяла се разполага върху вече изграден системен дял на носител (софтуерен RAID масив, хардуерен RAID масив, дисков дял). Създаването на LVM2 структурата на дяла става чрез инструмента pvcreate. Като аргумент при извикването му се задава пътя до системния дял:

Чрез този примерен команден ред, ще бъде създадена LVM2 структура в дяла /dev/sda2. Повече информация за опциите и аргументите на pvcreate може да бъде намерена в неговите man и info страници.

Чрез инструмента pvdisplay (за подробности виж man и info страниците му) може да се получи подробна информация за параметрите и свойствата на един създаден и работоспособен LVM2 дял:

Изведената информация за LVM2 дяла има структурата:

Съгласно нея дяла с физически път /dev/sda2 съдържа LVM2 структура, в която все още няма създадена LVM група. Дялът има големина 223.39 GB, от които 1018.00 KB не са използваеми за запис/алокиране Този резервиран капацитет служи за описание на системно ниво на LVM2 структурата.

Ако не бъде изведена подобна информация, това означава, че:

2. Създаване на LVM2 група

Следващата структура над LVM2 дяла е LVM групата. За да може да бъде създадена LVM група, трябва да има създаден и достъпен за запис LVM2 дял, в който да има необходимото за потребностите на групата неалокирано пространство. Тя се създава чрез инструмента vgcreate (за повече информация, виж man и info страниците му). Минималният набор аргументи, подавани при извикването на този инструмент, включва пътя до LVM2 дяла и името на групата:

Възможно е една група да е разположена върху два или повече LVM2 дяла.

3. Извеждане на информация за параметрите и свойствата на LVM2 група

Извеждането на информация за параметрите и свойства на LVM група става чрез инструмента vgdisplay (за повече информация, виж man и info страниците му):

При успешно изпълнение на командата, ще се получи изход с информация за свойствата и параметрите на групата:

В примерният резултат по-горе, се съдържа информация за параметрите и свойствата на групата с име VolGroup00. Конкретно, тя заема 223.39 GB място върху LVM2 дяла, в нея има свободни за алокиране 111.69 GB и също толкова заети.

Ако не бъде изведена подобна информация, това означава, че върху достъпните за проверка от страна на ядрото носители:

Ако списъкът с групи е дълъг, а е нужно да се получи информация само за конкретна група, нейното име се подава като аргумент на инструмента vgdisplay. Например, за извеждане на информация само за групата с име VolGroup00 може да се използва командния ред:

4. Създаване на LVM логически дял

За да се създаде LVM логически дял е нужно да има предварително създадена LVM група, в която да има нужното свободно пространство.

Създаването на логическия дял се извършва чрез инструмента lvcreate (за повече информация, виж man и info страниците му). Минималният набор аргументи, подавани при извикването на този инструмент, включва големината на дяла в единици кратни на байтове (M-за мегабайти, G-за гигабайти и т.н.), името на дяла и името на LVM групата, например:

Този команден ред ще създаде логически дял с име storage, с големина 111.69 GB в рамките на LVM групата с име VolGroup00. За да може да се прецени какво е максималното пространство, достъпно за създаване на нов дял в групата, се използва предварително информацията, получена от инструмента vgdisplay.

5. Извеждане на информация за параметрите и свойствата на LVM2 дял

Извеждането на информация за параметрите и свойства на един или всички логически LVM дялове, достъпни в системата, става чрез инструмента lvdisplay (за повече информация, виж man и info страниците му):

Ако в системата са достъпни повече от един логически дяла, блокът с изведената информация може да стане твърде голям и неудобен за прчит и анализ. Затова, ако трябва да се изведе информация само за един логически дял, от пълния блок информация се извлича името на логически дял, за който се търси конкретна подробна информация и то се подава като аргумент на инструмента lvdisplay:

Изведената като изход информация ще има следната структура:

Нужно е да се спомене една важна особеност. Логическият дял винаги има по-малка големина от този, използвана за изграждането му в майчината LVM група. Например, големината на логическия дял от примера е 92.84 GB, докато използваното от този дял място в LVM2 групата с име VolGroup00 е 111.69 GB. Това е следствие от LVM2 структурата.

III. Генериране и съхраняване на пароли за операции с LUKS дялове

1. Добра практика по съставянето на символната парола за форматиране и достъп

Паролата за криптиране и декриптиране на съдържанието на един LUKS дял е изключително важна и нейното отгатване от злонамерени лица в повечето случаи е катастрофално. Именно затова съставянето й трябва да се придържа към добрата практика за целта, която е била изградена с течение на времето. Накратко тази практика може да се опише така:

Спазването на тази добра практика значително намалява риска от разкриването на паролата за достъп до LUKS дяловете.

2. Добра практика по съхраняването на символната парола

Символната парола за достъп (декриптиране) до LUKS дяла следва да се съхранява изключително добре и нейното хранилище да се достъпва единствено при нуждата от въвеждането й, освен ако тя не се помни наизуст.

Символният низ на паролата следва да е криптиран и да се съхранява под тази си форма. Начинът на съхранение зависи от нивото на поверителност на съхраняваните върху LUKS дяла данни. По принцип, с цел предотвратяване на безвъзвратната загуба на паролата, тя може да се съхранява некриптирана в сейф, ако информацията върху LUKS дяла не е от най-високо ниво на поверителност. За организационни нужди е възможно паролата да бъде разделена на части и всяка нейна част да се съхранява на различно място, а отделните части да се събират само, ако работното копие на паролата бъде загубено. Възможно е подобно разделяне на паролата на части да се направи по електронен път с използването на алгоритъма "Blakely-Shamir" в рамките на софтуер, който го прилага.

Паролата не бива да бъде записвана в паметта на мобилни телефони, върху файлове без оценка къде се намират те физически и какъв достъп има до тях, върху външни системи за услуги (напр. електронна поща), върху листи хартия и др. Паролата не бива да се съобщава по телефонни системи, освен такива с вътрешнофирмено значение, осигуряващи криптиран гласов пренос. Изпращането на файл съдържащ паролата (дори с криптирано съдържание) в рамките на публични услуги, не се препоръчва.

3. Използване на файл за съхранение на символна парола

Използването на файл за съхранението на паролата за декриптиране на LUKS дялове трябва да бъде практика само на администратори и потребители, които са запознати с принципите на съхранение на криптирана и чувствителна информация.

В примера по-долу ще се предполага, че паролата, с която ще се криптира LUKS дяла е abracadabra, а криптираното й копие ще се намира във файла /path/to/key.file. Разбира се, в реалния случай трябва да се използва много по-дълга и богата на символи парола. Ако потребителят няма все още създадено хранилище за GnuPG за ключове и сертификати, ще трябва да извърши криптирането с парола:

Паролата за криптиране ще бъде изискана двукратно и след като и в двата случая бъде въведен един и същ символен низ, ще се извърши криптирането на файла. Ако обаче потребителят има създадено хранилище за GnuPG в профила, в който ще се създава файла с паролата, криптирането на информацията може да се извърши с публичен ключ:

При изпълнение на този команден ред ще се изведе диалогово меню, в което ще трябва да се укаже идентификатора на OpenPGP сертификата, чиито публичен ключ ще бъде използван за криптиране.

След като криптирането на файла завърши, трябва да се изтрие историята на командния интерпретатор (във Fedora и Red Hat Enterprise Linux най-често се използва bash):

Причината поради която това се налага е, че командният ред с паролата от по-горе, се описва във файла с историята на интерпретатора и съхранението й там създава опасност от разкриване.

Ето и конкретни примери с опции и аргументи за използването на паролата от файла с криптирано съдържание:

Удобството в случая е, че дори форматирането на дяла да е било извършено чрез прочит на паролата от "pipe", след това при асоцииране (декриптиране) на LUKS дяла към системно устройство, тя може да бъде въведена чрез диалогово меню.

Използването на парола, която съдържа само въвеждани от клавиатурата символи често поражда проблем поради наличието в нея на социален фактор. Наличието на социален фактор означава, че съдържанието на паролата в много случаи може да бъде обвързано с този, който я е създал и обратното. Често за пароли се използват символни низове, които подлежат на лингвистично предвиждане или са податливи на речникова атака. Следва да се използват такива пароли, които освен че имат голяма дължина, не са податливи на лингвистично предвиждане (да не са имена на приятел(ка), име на куче, име на град, рождена дата и др.) и речникови атаки (не са често използваеми в практиката символни низове). Един начин да се генерира парола, която да не е податлива на лингвистично предвиждане или речникова атака, но въпреки това да може да бъде въведена като набор клавиатурни символи, е чрез подаване на изхода от системния генератор на случайни числа, към инструмента base64, който превръща числовата поредица в символна. Ето пример за генерирането на случаен символен низ, основан на 32 байтово случайно число:

Примерният изход от такова генериране изглежда от вида:

Нужно е да се отбележи, че последният символ от низа (=), не е част от случайната комбинация от символи, съответстващи на 32-байтовото случайно число, но въпреки това няма проблем да се разглежда като част от генерираната парола. Ако паролата трябва да се съхранява в криптиран вид, тя се записва в криптиран вид във файл, като този процес може да се извърши още при генерирането й:

С така съхранения низ могат да се извършват операции върху LUKS дялове, като показаните по-горе.

4. Двоични пароли и съхранението им

Двоични пароли са тези, които не могат да се представят чрез низ от клавиатурни символи, а са поредица от двоични числа (най-често генерирани чрез генератор на случайни числа).

При работа с двоични пароли следва да се има предвид, че те не могат да бъде въвеждани в диалоговото меню на cryptsetup поради естеството им. Това създава проблеми в случаите, в които LUKS дяловете трябва да се декриптират при зареждане на системата, но криптирането им е извършено с двоична парола. Единствената възможност е тя да бъде описана като пълен път до съдържащ я файл в /etc/crypttab, но това не се препоръчва, освен в особени случаи.

Въпреки това двоични пароли могат да се използват в случаите, при които не се налага висока степен на интеграция на LUKS дяловете със инициализиращата скрипт системата на Fedora и Red Hat Enterprise Linux. Пример за това могат да бъдат "loop" дялове или други инцидентно монтируеми дялове. Ако двоичните пароли са генерирани с генератор на случайни числа, те не носят в себе си социален фактор, което е често неизбежно при използваните от потребителите пароли. Това ги прави с пъти по-надеждни от директно въвежданите като клавиатурни символи пароли. Разбира се, изключение е случаят, в който клавиатурно въвежданите символи пароли също са генерирани на базата на генератор на случайни числа.

Най-честата практика е двоичната паролата да се генерира с използването на системния генератор на случайни числа. За целта се препоръчва генератора /dev/urandom (вместо /dev/random). Ето примерна процедура по генерирането на двоична парола с дължина 32 байта (256 бита) и записването й в криптиран вид във файла /path/to/binkey.file:

При този начин на извикване на gpg, съдържанието на файла ще бъде криптирано с парола (чието въвеждане ще стане двукратно в диалогово меню). Ако за криптирането ще се използва публичен ключ, следва вместо опцията "-c" да се използва "-e" и след това в диалоговото меню да се укаже идентификатора. Използването в първия команден ред на umask с аргумент 0177 има за цел да укаже, че достъп (запис, прочит) до съдържанието на създавания файл ще има само собственика му (създателя му).

Оттук нататък двоичната парола може да се използва за форматиране и криптиране преди асоциирането на LUKS дял към системно устройство. Например:

Начинът на съхранение на двоичната парола зависи от нивото на поверителност на съхраняваните върху LUKS дяла данни. По принцип, с цел предотвратяване на безвъзвратната загуба на паролата, тя може да се съхранява некриптирана в сейф, ако информацията върху LUKS дяла не е от най-високо ниво на поверителност. За организационни нужди е възможно паролата да бъде разделена на части и всяка нейна част да се съхранява на различно място, а отделните части да се събират само, ако работното копие на паролата бъде загубено. Възможно е подобно разделяне на паролата на части да се направи по електронен път с използването на алгоритъма "Blakely-Shamir" в рамките на софтуер, който го прилага.

IV. Уникални идентификатори на файлови системи (UUID)

1. Обща информация и приложения

Тази информация е допълнителна и не е пряко свързана с изграждането, управлението и използването на LUKS дялове, но носи добра практика, която улеснява системната администрация.

Какво е наложило използването на UUID за обозначаване на файловите системи? Твърде често в каталога с дялове за монтиране на файлови системи, /etc/fstab дяловете, които ги съдържат, се описват чрез път до устройствата, в които физически са разположени. Например, монтирането на /dev/hda6 като /home, се представя в каталога по начин подобен на:

Такова описание е абсолютно и поражда неудобство и дори нееднозначност в случаите, в които се налага да се смени физическия път до монтиран дял. Практически ситуации на смяна на физическия път са тези, при който се извършва смяна на IDE канала, към който е включен твърдия диск. Ако се направи препратка към примера от по-горе и диска, на който се намира дяла /home се премести от първия IDE канал на втория, то пълния път няма да е вече /dev/hda6, а ще бъде /dev/hdc6. Очевидно е, че при подобна смяна трябва да се предвиди новия път и да се направи съответната редакция в каталога /etc/fstab още преди да се извърши физически преместването на каналите. За един дял подобна операция е сравнително лесна за изпълнение, но при смяната на много физически пътища се създава опасност от грешка и незареждане на системата след рестартирането й в новата конфигурация. Съществуват и случаи, при които няма как предварително да се знае кой точно ще е физическия път за даден дял.

Използването на UUID води до избягване на необходимостта от описание на път до дяловете. В този случай всеки дял има свой уникален 128 битов идентификатор и при монтаж вместо пътя се използва идентификатора. Така отпада необходимостта да се прави строго каталожно описание на физическите пътища до дяловете и се облекчава обслужването на системи с динамични пътища до физическите носители на информация. При описанието на дяла в каталога /etc/fstab се използва UUID вместо път, например:

Основателен е въпроса как да се провери стойността на UUID за всяка файлова система. За да се провери какъв е UUID на една дайлова система, може да се използва инструмента vol_id. Следващият пример показва как се извежда UUID стойността файловата система в дяла /dev/hda1:

При успешното изпълнение на този команден ред, като резултат ще се получи блок с информация, подобен на следния:

Редът започващ с ID_FS_UUID съдържа универсалния уникален иденфификатор (UUID) на файловата система в дяла /dev/hda1. За примера това е 91a143c1-0ee6-4a2a-bda6-d7b7bdaf28d1.

Ако обаче върху даден дял не е зададен UUID, изходът от комадния ред няма да покаже стойност след ID_FS_UUID=:

За да се постави универсален уникален идентификатор върху файлова система, той трябва да се генерира. За целта се използва инструмента uuidgen. Той генерира случайно 128 битово число, във формат на UUID:

След като се генерира, идентификатора може да се постави върху файловата система в дяла чрез инструмента tune2fs. Ето примерен команден ред, чрез който файловата система с път /dev/hda6 се поставя UUID със стойност 42306191-be7f-40c2-b007-d258d1bdf860:

Смяната на UUID на файловата система се свежда до задаване на нова стойност на UUID с инструмента tune2fs. Нужно е да се отбележи, че дяловете, които инсталаторът Anaconda създава и в които има директно достъпна файлова система (т.е. файловата система не е в софтуерен RAID или LVM), имат винаги задаени стойности на ID_FS_UUID и ID_FS_LABEL полетата (вкл. и на ID_FS_LABEL_SAFE).

2. Откриване на физическия път до LUKS дял по неговия UUID идентификатор

Това е решение на обратната задача, т.е. по известен UUID на файловата система (в случая LUKS дял), да се открие дяла (като пълен физически път), който я съдържа. Намира се чрез инструмента blkid, който е част от пакета e2fsprogs и задължително присъства в системата. Например, физическия път до дяла, който съдържа файловата система с UUID=a792979a-ce88-4a3e-ae64-fe866a760513, може да се открие с помощта на blkid така:

Ако бъде открит физически път, съдържащ файловата система с посочения UUID, той ще бъде изведен на нов ред, например:

Списък на всички достъпни към момента файлови системи, техните типове и UUID стойности, могат да бъдат намерени във файла /etc/blkid/blkid.tab. Съдържанието на файла е в XML формат и за всяка файлова система има по един ред. То не бива да се редактира!

Инструментът blkid се използва в инициализиращия скрипт /etc/rc.d/rc.sysinit. Целта е преобразуването на UUID стойностите от файла /etc/crypttab (ако такива са използване), във физически пътища до дялове, които да се задават като аргумент на инструмента cryptsetup (той не може да приема за аргумент UUID стойности).

Нужно е да се отбележи, че в каталога в /etc/blkid/blkid.tab има и други UUID идентификатори, различни по формат от тези за файлова система. Такива се идентификаторите за софтуерни RAID дялове и LVM2 дялове.

3. UUID дуализъм за файлови системи в LUKS дялове

LUKS дяловете също имат UUID индикатор, доколкото те са тип файлова система, която реализира псевдодял. Например, ако дялът /dev/mapper/VolGroup00-storage е LUKS, то UUID идентификатора му може да бъде изведен по начина, по който това става за всяка файлова система:

Конкретно за примера, идентификаторът има стойност 5ecbe934-0280-46fb-8a91-79e8557a59a1. Вижда се и идентификацията на дяла като LUKS (crypto_LUKS). Друг начин за намирането на UUID за LUKS дял е използването на cryptsetup с опция luksUUID или преглед на съдържанието на /etc/blkid/blkid.tab.

Когато дялът се декриптира и асоциира към устройство, файловата система в дяла става достъпна за ядрото и UUID идентификатора й става читаем. Например, ако LUKS дяла /dev/mapper/VolGroup00-storage е бил декриптиран и асоцииран към устройството /dev/mapper/luks-storage, UUID на файловата система съдържаща се в него, може да се прочете така:

Освен стойността на идентификатора (0bab2f27-f4a7-475f-9498-56906f0120ab), се извежда информация и за типа (ext3) и версията (1.0) на файловата система. Както се вижда, UUID идентификаторите на LUKS дяла и на файловата система не съвпадат. Това е равносилно на това в един и същи дял да има две файлови системи една в друга, всяка от които е различна по характер и съдържание, а оттам и с различна UUID стойност. Нужно е да се отбележи, че щом файловата система в LUKS дяла бъде монтирана (все едно дали ръчно или автоматизирано чрез описание в /etc/fstab), за нея се създава ред с информация в /etc/blkid/blkid.tab.