Введение новых дисков в работу и LUKS


Есть абсолютно НОВЫЙ hdd, который нужно ввести в работу в linux x64. Необходимо надежно защитить данные на этом hdd.
Для этого предполагается приготовить его с помощью dm-crypt/LUKS.
Планируется выполнить следующие действия:

1. Создать один раздел на диске с помощью
.

2. Отформатировать LUKS.

как указано здесь
https://www.pgpru.com/faq/zaschitadiska#h42-18

3. Открыть его


4. Отформатировать с помощью и смонтировать.

Всё.

Теперь что хотелось бы узнать:
а.) Для абсолютно нового диска имеет ли смысл заполнение случайными числами, как это указано здесь
https://www.pgpru.com/faq/zaschitadiska#h42-15
?

б.) Какова рекомендуемая минимальная длина пароля?

в.) Так ли уж нужны ключевые файлы? Для чего они в случае довольно мощного подхода, предлагаемого линукс?

г.) Покритикуйте вышеуказанные действия или добавьте что-то еще в эту последовательность.

Спасибо.



Комментарии
— SATtva (25/02/2014 09:45)   
Для абсолютно нового диска имеет ли смысл заполнение случайными числами, как это указано здесь ... ?

Обязательно. В противном случае можно будет элементарно определить объём зашифрованных данных и их расположение на диске.
— unknown (25/02/2014 10:22)   

а). Заполнять рэндомом даже чистый диск практически обязательно. Чтобы нельзя было видеть, сколько там осталось пустого места; вычислять, есть ли там известные файлы некоторого очень большого размера (например после полупустых блоков появился кусок на пару гигов, похожий на известный противнику архив с документами или видео) и т.д.
б). Обсуждение[link1] этой темы привело к вопросу кандидату в FAQ[link2] с последующем обсуждением самого этого вопроса на грани флуда. Формально, исходным параметром является не длина пароля, а более абстрактная величина — его энтропия. А длина зависит от энтропии по тому, каким способом придумывался/генерился пароль. В обсуждении ещё приведены и указаны по ссылкам разные техники. Но всё упирается в то, что у разных пользователей разные предпочтения. Кто-то может запомнить абсолютно рэндомный набор символов. А кто-то на это совсем неспособен и ему проще набивать равностойкие по энтропии, но гораздо более длинные парольные фразы, к которым можно придумать какой-то скрытый смысл.
в). Ключевые файлы, которые используются отдельно от заголовков контейнера в большинстве случаев не нужны. Если не нужно только использовать некую внешнюю флэшку как дополнительный ключ или делать сложную иерархию доступа между разными шифрованными раздела (вида «при открытии одного контейнера получаем ключ к другому»).
г). Можно не форматить под ext4, а сначала отформатить внутри шифрованного тома как физический том, а в нём сделать логические тома. Но если не знаете, что такое LVM, то скорее всего он и не нужен. И даже если знаете, возможно, тоже ничего добавлять смысла нет.
— cyber_beard (25/02/2014 11:42)   
Спасибо за подсказки! Ещё вопрос по пункту а.)
Какой конкретно способ заполнения рэндомом предпочесть.
1. Способ затирания через зануление криптотома
https://www.pgpru.com/faq/zaschitadiska#h42-15
2. выполнить с самого начала, еще до разметки диска.
3. Еще какие-то способы.
3-ий пункт связан с одной стороны с тем, что запонение случайными числами обязательно, с другой стороны с тем, что речь идет о 2Tb hdd, и
такой процесс будет высокой нагрузкой и для hdd, и для системы в целом.
— unknown (25/02/2014 12:28)   

Это может на пару суток растянется.

Два способа из FAQ — примерно часов на 8.


Так и зануление криптотома с переформатом заголовка даст случайные числа в итоге. Способ с HAVEGE — самый быстрый, простой и приемлемо надёжный для данной задачи.
— cyber_beard (01/03/2014 17:43)   
Для абсолютно нового диска имеет ли смысл заполнение случайными числами, как это указано здесь ... ?

Обязательно. В противном случае можно будет элементарно определить объём зашифрованных данных и их расположение на диске.


Вот к этой фразе постоянно мысленно возвращаюсь.
Вопрос больше теоретический. Допустим, в ходе соответствующего анализа был определен объем данных и их расположение.
Имеется в виду общий объем данных?
Что это дает?
В таком случае, какие будут следующие шаги по анализу этих данных?
— unknown (01/03/2014 19:41)   

Чисто теоретически, противник должен видеть после шифрования данные, неотличимые от рэндома, без какой-либо структуры и различителей. За исключением служебных заголовков и предопределённого форматирования шифртекста, если таковое используется (в случае дискового шифрования в текущих режимах форматирования нет).

Что это дает?
В таком случае, какие будут следующие шаги по анализу этих данных?

у меня пока нет возможности квалифицированно ответить на этот вопрос. Могу дать отвлечённый, косвенный ответ.

Считается, что при расположении данных не на локальном винчестере, а, например на удалённом сервере (в облаке), который подконтролен противнику, использовать нынешние режимы дискового шифрования вообще нельзя. Ни в прямом онлайн-режиме, ни в режиме бэкапов. Или надо каждый бэкап перешифровывать заново с нуля, но тогда дисковое шифрование не нужно — можно пошифровать данные через архив или образ диска, пропущенный через gnupg в режиме симметричного шифрования.

Считается, что с каждым актом наблюдения за изменением данных при дисковом шифровании происходит утечка сведений об открытом тексте. Поэтому, для серверного и облачного шифрования разрабатывают специальные режимы updatable encryption, чтобы сохранять возможность шифровать прозрачно без перешифровки всех данных. Публикуются соответствующие работы с кучей специфической терминологии, сведениями о нетривиальных различителях и пр.

Попадание противнику диска с шифроконтейнером, который не был заполнен целиком, схоже со случаем единичного наблюдения шифрования. Возможно, при этом утечка данных будет и незначительной. Возможно, никто из теоретиков этот вопрос подробно и не исследовал. Важен факт, что утечка есть, но её достаточно легко в данном случае предотвратить.
— cyber_beard (01/03/2014 20:09)   
Спасибо, теперь уже яснее.
Вернусь к предыдущей проблеме:
раздел на диске был отформатирован с помощью luksFormat и смонтирован в /dev/mapper/experimental
Далее применяется следующая команда:

На что получаем ответ:


В чем здесь ошибка?

Зато работает следующая команда:
— cyber_beard (01/03/2014 20:19)   
Еще вопрос по вышеуказанному мануалу Способ затирания через зануление криптотома, возникший в ходе сравнения с другими подобными мануалами в англоязычном интернете.
Получается, что мы сначала форматируем раздел в LUKS и монтируем его в /dev/mapper/some_name. А потом к уже смонтированному /dev/mapper/some_name применяем такую же процедуру, т.е. еще раз форматируем его с помощью luksFormat и еще раз монтируем в /dev/mapper/some_name1. Правильно понимаю? Спасибо.
— unknown (01/03/2014 21:59)   
sudo pv -s 2T sudo >

Это явная опечатка. Как можно перенаправлять что-то из sudo? sudo должно стоять перед командой. Или сделайте sudo -i, чтобы войти в рутовую консоль и наберите все команды с правами рута.

Получается, что мы сначала форматируем раздел в LUKS и монтируем его в /dev/mapper/some_name. А потом к уже смонтированному /dev/mapper/some_name применяем такую же процедуру, т.е. еще раз форматируем его с помощью luksFormat и еще раз монтируем в /dev/mapper/some_name1. Правильно понимаю? Спасибо.

Монтирование обозначает обычно несколько другое: связывание устройства, на котором есть файловая система, с каталогом. Здесь же можно сказать, что не монтируем, а открываем "open" или поднимаем том.

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

В том примере операции производятся над логическим томом, возможно это вас и запутало. Потому что в таком случае в /dev/mapper есть и просто исходный логический том и открытый том одновременно.

Если же вы шифруете всё устройство, то желательно создать на нём через fdisk раздел /dev/sd[x]1 и пометить как Linux LVM. Есть варианты с разметкой через pvcreate – vgcreate – lvcreate. Зависит от того, что вам нужно, например при автомонтировании через /etc/crypttab или стартовые скрипты и что для вас допустимо может торчать наружу, а что нет.
— cyber_beard (01/03/2014 22:11)   
ОК, спс. По поводу haveged все понятно.

Монтирование обозначает обычно несколько другое: связывание устройства, на котором есть файловая система, с каталогом. Здесь же можно сказать, что не монтируем, а открываем "open" или поднимаем том.

Тогда в мануале неточность. Первые 2 команды должны быть такими:
cryptsetup luksFormat /dev/sdx1
cryptsetup luksOpen /dev/sdx1 Group_T
dd if=/dev/zero bs=1M | pv -s [размер раздела в терабайтах]T > /dev/mapper/Group_T
— unknown (01/03/2014 22:38, исправлен 01/03/2014 22:42)   

Был выбран пример на основе логического тома, о чём не было явно указано. Подразумевлось, что пользователь, знакомый с LVM, сам разберётся и подставит нужное устройство.


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


Кстати, вывод haveged не нужно направлять в открытый с помощью cryptsetup том: это ускоренный аналог {u}random, так что его можно направить на исходное устройство или на сырой том, который ещё не был отформатирован при помощи cryptsetup.

— cyber_beard (01/03/2014 22:57)   
так что его можно направить на исходное устройство или на сырой том, который ещё не был отформатирован при помощи cryptsetup.

Полезная информация! Уже было протестировано и так и так ) Скорость от этого не поменялась, что писал в /dev/mapper/example, что в /deb/sdx. Одно и то же.

Был выбран пример на основе логического тома, о чём не было явно указано. Подразумевлось, что пользователь, знакомый с LVM, сам разберётся и подставит нужное устройство.

Ок, но еще раз хочу у Вас уточнить: нули можно направить и в dev/mapper/example, это корректно?
Например вот так:
— unknown (01/03/2014 23:56)   
Нули нужно направлять исключительно на открытый том, который возникает после открытия через cryptsetup/LUKS от другого исходного тома или устройства. Чтобы когда этот том закроют, нули на исходном устройстве оказались зашифрованными данными.

Параметр bs в команде dd обычно не имеет смысла брать больше 1M, скорость выше этого предела не растёт, хотя на каких-то современных носителях может и можно что-то выжать при незначительном увеличении.
— Гость (02/03/2014 04:33)   

Делать одну файловую систему на все 2 TB — это очень плохо по множеству соображений, таких как:
  1. Ошибка в файловой системе — и сразу будет проблема со всем диском.
  2. Если захочется открыть доступ только к некоторому набору данных, придётся открывать доступ ко всем имеющимся, поскольку иного не будет предусмотрено.
  3. Будет невозможно сделать гибкое управление данными (разбить диск на подразделы, разные файловые системы, назначить разные пароли к разным виртуальным разделам и т.д.), т.к. для этого нужно LVM. Если LVM есть на нижнем уровне, то вы можете им и по сути не пользоваться, используя всё пространство LVM под один раздел, но главное — что он есть, т.е. при надобности можно будет ужать файловую систему, переразбить диск иначе, создать новые подразделы и т.д., причём всё это будет делаться без переноса всех данных на третий носитель. Если же на нижнем уровне (внутри первого LUKS) LVM'а нет, то без полного временного переноса данных куда-то и полной переразбивки диска не обойдётся. С учётом того, что 2 TB — слишком большой объём данных, вероятность того, что вам рано или поздно захочется большей гибкости в управлении этими данными, стремится к единице. В общем, не повторяйте чужих ошибок. Лучше потратить лишние день-два, чтобы разобратья с LVM (делов-то — тройку лишних команд ввести: pvcreate, vgcreate и lvcreate), чем потом годами негодовать по поводу «сложившегося порядка вещей на диске». Ну, и не стоит забывать про вечное «нет ничего более постоянного, чем временное».


Если это внешний диск, работающий по USB 2.0, то на 5 суток:

2*1024*1024*1024*1024/(5*1024*1024)/3600/24 ≈ 4.85,

т.к. urandom, судя по моему опыту, больше 5MB/sec почему-то не даёт. И, вообще, есть ограничения на скорость USB, её не предололеть. Скорей всего, именно она будет самым узким местом при заполнении диска.


Нет, нет здесь никакой вложенности процедур. Заполнять нулями надо /dev/mapper/some_name, а потом этот LUKS-раздел уничтожить переформатированием, после чего создать новый на этом же месте (а не внутри предыдущего!), грубо говоря.
— cyber_beard (02/03/2014 13:59)   
Если LVM есть на нижнем уровне, то вы можете им и по сути не пользоваться, используя всё пространство LVM под один раздел, но главное — что он есть, т.е. при надобности можно будет ужать файловую систему, переразбить диск иначе, создать новые подразделы и т.д., причём всё это будет делаться без переноса всех данных на третий носитель.

Тогда последовательность будет такой?
1.) форматируем

2.) Открываем LUKS:

Появляется диск /dev/mapper/lvm/
3.) Создаем на нем физический раздел

4.) Создаем группу томов

5.) Создаем логические разделы внутри, исходя из объема 2Gb(например, 2 раздела по 500Gb + 1 раздел всё остальное, т.е. около 1Gb):

6.) Далее каждый форматируем:

7.) И монтируем как обычно, т.е.


Правильно?

Благодарю за совет по поводу LVM, но не совсем понятно:
судя по этому
назначить разные пароли к разным виртуальным разделам

Вы говорите про LUKS on LVM.
А судя по этому
Если же на нижнем уровне (внутри первого LUKS)

Вы пишите об LVM on LUKS.
Если исходить из моих потребностей, то допускаю возможность поделить диск на несколько разделов с разными паролями. Но в таком случае было бы лучше делать LUKS on LVM, т.е. создавать LVM сначала, а потом уже форматировать каждый раздел под LUKS. Это даст возможность в случае необходимости изменить конфигурацию не сносить с диска вообще всё.
С другой стороны, в случае с LVM on LUKS нравится то, что можно скрыть вообще всю структуру разделов диска, когда LUKS закрыт.
Подитожу вопросы:
1.) О каком типе использования LUKS и LVM Вы пишите, когда пишите о преимуществах LVM? Сначала LVM, а потом LUKS?
2.) При каком подходе LVM все же больше преимуществ с точки зрения добавления новых носителей?
3.) Правильна ли моя последовательность команд, указанных выше?
— cyber_beard (02/03/2014 14:13)   
По поводу скорости haveged и скорости заполнения luks нулями.
Было экспериментально проделано и то, и другое. Сравнивались процедуры:

и

Скорость оказалась примерно одинаковая: от 150Mb/s до 250Mb/s.
haveged оказался даже быстрее по субъективным оценкам.
— unknown (02/03/2014 18:52)   
По поводу LVM, вроде в общем виде правильно, но может быть масса вариантов, как именно удобно и правильно для вас. Можно вообще использовать двойное шифрование — и снаружи (на уровне устройства), и внутри (для логических томов LVM). Ни к каким конфликтам это не приводит. В современных компьютерах это практически никак не сказывается на быстродействии для большинства обычных задач. Надёжность хранения тоже особо не падает: при сбоях с шифрованием следует надеяться лишь на бэкапы, а не на попытки восстановить данные с побитого носителя.


Померяйте теперь с перенаправлением в /dev/null. Если там будет быстрее, значит у вас лимитируется скоростью записи на носитель. При шифровании нулей ещё имеет значение, задействована ли аппаратная поддержка криптоалгоритма со стороны процессора.
— Гость (03/03/2014 00:23)   
cyber_beard (02/03/2014 13:59)
а попробуйте посмореть через графический иyсталятор Debian как создается шифрованный раздел и затем в нем lvm, в т.ч. дальнейшая настройка логических томов. имхо, будет больше понимания. все это можно попробовать в вирт машине (очень удобно и быстро).
— Гость (03/03/2014 03:31)   

Вроде правильна (за -l 100%FREE TestStorage не поручусь, консультируйтесь с how-to в интернетах и мануалами). В любом случае, я бы вам посоветовал следующее: не надо стремиться сразу разбить весь диск. Сколько вам надо места под текущие данные и сколько вам надо разделов — столько и выделите. Потом размер разделов всегда можно увеличить (расширив и файловую систему соответственно) или досоздать новые из имеющегося «пула». Т.е. смысла загонять всё оставшееся место в какой-то третий логический том на уровне «лишь бы создать» — подумайте, надо ли это вам. И, как говорил unknown, лучше создавать разделы (логические тома) поменьше, а потом их увеличивать по мере надобности, т.к. это более безболезненная ситуация, чем ужимать уже существующие (но не до конца заполненные) разделы (логические тома), но не до конца заполненные.


Настоятельно рекомендуется делать LUKS снаржи + LUKS внутри. Т.е. вместо вашего шага №6
mkfs.ext4 /dev/mapper/TestStorage-test0
надо сделатьСмысл понятен? Весь диск — LUKS-раздел, внутри него — LVM-структура с логическими томами, которые, в свою очередь, сами являются LUKS-разделами (в общем случае, с другими пассфразами). И внутри этих LUKS-разделов сидят файловые системы. Пока для простоты можете пассфразу везде одинаковую поставить, т.к. она «уничтожается» из оперативной памяти сразу после подсоединения LUKS-раздела. Позже пассфразы на LUKS можно будет сменить, это элементарно делается.


Одинаково. Предлагаемая структура (куча LVM-LUKS-томов внутри одного большого LUKS на весь диск), кстати, очень похожа на то, как можно сделать полнодисковое шифрование в Debian при его выборе при инсталляции. Можно создать LUKS-раздел, а внутри нарезать LVM-тома, на каждом томе будет своя файловая система и своя точка монтирования. При загрузке система будет спрашивать пароль на внешний LUKS и грузиться, а загрузившись, вы можете подсоединять уже собственные LVM-тома, несистемные (для /home и прочего), внутри которых будет LUKS в качестве прокладки между LVM-томом и файловой системой; т.е., не введя дополнительных паролей, к объёму данных противник доступ не получит, даже если сможет загрузить систему]. Ну, и общая идеология, стоящая за такой разбивкой — рассортировать данные по степени нужности в работе так, чтобы держать подключенными те и только те объёмы данных, которые вам в данный момент нужны, а не вообще все.


Не советую, это только запутает. Из инсталлятора можно сделать всё очень по-разному, а чтобы понять, как надо делать, надо уже знать матчасть. Сам инсталлятор тоже запутанный, и там много слишком контринтуитивных вещей. Общая схема такая, когда речь доходит до дележа дискового пространства (пишу по памяти, могу ошибаться в деталях):
  1. Выделить отдельный дисковый раздел под точку монтирования /boot и не шифровать его ничем.
  2. Пометить, что мы используем другие дисковые разделы (их может быть один или несколько), как контейнеры для LUKS.
  3. Выбрать «сконфигурировать LUKS-разделы» (никто не догадается, что это надо обязательно сделать именно на этом этапе!).
  4. После конфигурирования появится виртуальное блочное устройство /dev/mapper/NAME, где NAME — то, как вы его назвали + учёт внутренней номенклатуры. Этот новый LUKS-раздел будет виден в списке блочных устройств на дальнейшее разбиение и/или создание файловых систем.
  5. Вот только теперь можно заняться LVM: выбираем этот NAME и делаем «использовать его, как LVM-том/раздел».
  6. Появившуюся группу логических томов (LVM) разбиваем на «логические тома» — тут всё как с дисками, выделаем пространство и назначаем имя.
  7. Каждый логический том форматируем и назначаем ему точку монтирования (типа /usr, корень / и т.д.).
Собственно, всё. Лучше на системные разделы всё NAME не бить, а оставить место для собственных /home/pupkin и т.п. После успешной инсталляции можно будет загрузиться и в командной строке досоздать руками те «логические тома», какие было необходимо, сделав их LUKS-контейнерами. Т.е. часть LVM-томов будут просто файловыми системами, а другая часть — LUKS-разделами, требующими ввода дополнительной пассфразы, чтобы их смонтировать. Недавно на эту тему целый топик был[link3].
— unknown (03/03/2014 09:52, исправлен 03/03/2014 09:53)   

Топик-стартер не указал, что он собирается использовать полнодисковое шифрование для запуска рабочей операционной системы (это действительно отдельная тема). Из его вопроса можно только предположить, что он хочет аккуратно затереть носитель (возможно внешний), а затем вероятно использовать его для хранения каких-то данных.


В FAQ, собственно, только вопрос затирания в общем виде и рассматривался. При установке системы лучше положиться на опции установщика с шифрованием, а варианты допиливания под свои потребности — это не вопрос для FAQ, там есть что пообсуждать или надо большую доку сочинять по всем возможным вариантам.


Кстати, перед установкой системы, винт лучше затереть рэндомом быстрыми способами из FAQ. А при инсталляции отказаться от затирания, если всё уже заранее затёрто: ведь в инсталляторе используется тормозной urandom.

— Гость (04/03/2014 20:47)   
На тему LVM, если что: после подключения внешнего LUKS разделы LVM не всегда становятся доступными автоматически. Если их нет, надо сделать vgchange -ay NAME, где NAME выцепляется из вывода vgdisplay. Соответственно, чтобы закрыть внешний LUKS (luksClose), который на весь диск, придётся делать принудительный vgchange -an NAME, иначе не сработает. В неоторых юзерофильных системах автодетект LVM происходит сам по себе, и там vgchange -ay можно не делать.
— unknown (04/03/2014 21:51)   
А можно сделать vgchange -ay безо всякого NAME. На уже открытые группы томов это никак не повлияет, а все неоткрытые просканируются. А вот закртие vgchange -a n NAME уже только с именем группы.
— cyber_beard (05/03/2014 12:07)   
Вот как раз хотелось бы спросить:
после открытия luks группа томов приводится в активное состояние с помощью:

И далее происходит монтирование логических томов.
А чтобы выключить, то наоборот: размонтируем тома и делаем:


Вопрос в том, достаточно ли этих операций для стандартного подключения lvm on luks, или, м.б., что-то пропущено?
— Гость (05/03/2014 13:02)   
Подключение всех LVM-разделов:
# cryptsetup luksOpen /dev/sdb1 sdb1_crypt
# vgchange -ay mygroup
# cryptsetup luksOpen /dev/mygroup/LVname1 LVname1
# cryptsetup luksOpen /dev/mygroup/LVname2 LVname2
...
# mount /dev/mapper/LVname1 /path/to/LVname1
# mount /dev/mapper/LVname2 /path/to/LVname2
Отключение всех LVM-разделов и внешнего LUKS (например, чтобы вытащить диск из системы):
# umount /path/to/LVname1
# umount /path/to/LVname2
...
# cryptsetup luksClose LVname1
# cryptsetup luksClose LVname2
...
# vgchange -an mygroup
# cryptsetup luksClose sdb1_crypt
Чтобы так сделать, надо предварительно убить все программы/процессы, которые используют эти разделы. Например, -an не сработает, если хотя бы один из внутренних LUKS-контейнеров используется. Иногда возникают глюки, из-за которых файловые системы удаётся отмонтировать, а внутренние LUKS-контейнеры закрыть, но при этом какой-то процесс, типа ssh-agent'а, остаётся запущенным. В этом случае, хотя ничего не мешает, не удаётся сделать -an и/или luksClose для внешнего LUKS. Проще всего лечить перезагрузкой, хотя можно попробовать подмонтировать проблемные разделы, а потом их снова отмонтировать (не пробовал, поэтому не знаю, поможет ли).

Если нужно подключить/отключить только конкретный LVM-раздел («группу логических томов») при условии, что диск уже подключен, а LVM на нём уже активирован, то:
# cryptsetup luksOpen /dev/mygroup/LVnameN LVnameN
# mount /dev/mapper/LVnameN /path/to/LVnameN
Чтобы отключить только конкретный LVM-том (но не все остальные) при этих же обстоятельствах:
# umount /path/to/LVname1
# cryptsetup luksClose LVname1
umount отмонтирует файловую систему (она более недоступна всем, кроме root'а, который её может примонтировать вновь, не требуя пассфразы). luksClose удаляет ключ шифрования раздела из оперативной памяти (т.е. без повторного ввода пассфразы доступ к данным не вернуть). Что при этом происходит с самими данными с раздела, которые были ранее в оперативке — вопрос дискуссионный[link4].
— cyber_beard (08/03/2014 14:55)   
Из его вопроса можно только предположить, что он хочет аккуратно затереть носитель

Речь шла о простых hdd, на которых не установлена система.
Хочу так же подтвердить, что всё, указанное в faq (а так же рекомендации из данной темы относительно lvm) работают отлично.
Способы из faq (нули и haveged) действительно быстрые, так что в случае необходимости их можно использовать даже вместе без существенных потерь времени.
Что касается haveged, то в сети встречал непроверенную информацию относительно того, что демон потребляет значительное количество ресурсов при запуске. Посему на всякий случай данный пакет был удален.
— Гость (08/03/2014 23:16)   

Ну вот и хорошо.
— pgprubot (18/07/2015 15:06, исправлен 13/10/2015 20:49)   

Имя группы томов можно узнавать динамически, сравнивая вывод vgscan до и после подключения соответствующих разделов. Будет выглядеть примерно так:

#!/bin/zsh
 
[some commands] && \
VG_before=$(vgscan |grep Found) && \
[cryptsetup opening commands] && \
VG_after=$(vgscan |grep Found) && \
VG_new=$(diff <(echo $VG_before) <(echo $VG_after) |grep Found) && \
VG_name=$(echo $VG_new |sed 's/\(^.* "\)\([^"]*\)\(" .*\)$/\2/') && \
[some commands] && \
С /bin/sh diff-строка не заработает, нужен хотя бы bash. VG_name — название новой появившейся Volume Group.

— pgprubot (13/10/2015 21:17, исправлен 13/10/2015 21:32)   

В случае, когда внутри криптотома (к примеру, /dev/mapper/sd{b,c,d}_crypt) содержится VG с (дополнительно) шифрованными LV, иногда возникает проблема: из-за плохих контактов в USB-разъёме или из-за вашей ошибки (нечайно выдернули диск до корректного отмонтирования и отключения всего нужного) ядро решило, что диск более недоступен. Все попытки чтения диска приводят к I/O-ошибкам.


В этой ситуации выглядит логичным принудительно всё отмонтировать и отключить, выдернуть диск, если он ещё не было выдернут, а потом подсоединить заново и всё подключить. Однако, это не работает, т.к. даже после принудительного отмонтирования ФС и отключения шифрованных LV-устройств vgchange -an mygroup отказывается выполняться, а опции сделать -an для конкретной VG принудительно нет. Более того, если подключить этот же диск снова, то не удастся на нужной стадии выполнить vgchange -ay mygroup, потому что эта VG считается недоступной.


Здесь может помочь грязный хак: диск вынимаем, подключаем снова; после подключения делаем переименование: vgrename mygroup mygroup_new; теперь шифрованные LV могут быть подключены (несмотря на сыпящиеся в консоль предупреждения). Но главное тут то, что ссылки на старую VG становятся неактивными после переименования VG, т.е. VG как бы исчезает, и становится возможным сделать cryptsetup remove sd{b,c,d}_crypt для того диска, на котором находилась эта VG.



Можно делать по аналогии с предлагаемым в Tails для завершения работы системы — после отмонтирования криптотомов запускать sdmem[link5].


P.S. Кстати, vgrename помогает и в других случаях — например, при коллизиях имён[link6].


Ссылки
[link1] http://www.pgpru.com/forum/tehnicheskievoprosy/dlinaparoljnojjfrazyluks

[link2] http://www.pgpru.com/chernowiki/rukovodstva/voprosykandidatyvfaq/kriptografijapraktika#h36842-2

[link3] http://www.pgpru.com/forum/unixlike/spisoksledjaschegopobezopasnajaustanovkadebian

[link4] http://www.pgpru.com/comment51009

[link5] http://www.pgpru.com/comment93773

[link6] http://www.pgpru.com/comment83413