id: Гость   вход   регистрация
текущее время 13:37 28/03/2024
Автор темы: ressa, тема открыта 29/07/2014 10:40 Печать
Категории: криптография, инфобезопасность, защита дисков, алгоритмы, операционные системы
http://www.pgpru.com/Форум/UnixLike/МаскировкаВводаПароляВCryptsetup
создать
просмотр
ссылки

Маскировка ввода пароля в cryptsetup


Форумчане, скажите, можно ли сделать в Crytpsetup затирание вывода консоли при вводе пароля на загрузку?
Как в TrueCrypt – фейковая ошибка, например "Invalid BOOT.INI file Booting from C:windows", таким образом ввести в заблуждение по поводу установленной системы и не реагировать на ввод неправильных паролей.
Спасибо


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— Yellow (14/08/2015 13:02)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Я так понимаю, что, например, в Tails система в конце выключения перед запуском sdmem (или аналога) перезагружает новое ядро с помощью kexec.
— pgprubot (15/08/2015 17:29, исправлен 15/08/2015 17:31)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Видимо, да:


First, the memory erasure process is triggered at the end of a normal shutdown/reboot sequence. This is implemented by slightly modifying the System V initscripts shipped by the kexec-tools Debian package: the kexec-load initscript, that normally only runs at reboot time, is enabled to run at shutdown time as well. A custom tails-kexec initscript replaces the kexec one in order to support the case when the boot medium is not available anymore at the time this script runs; it also provides an improved user interface more suitable for Tails target users needs. Finally, the standard Debian halt and reboot initscripts are taken over by having the tails-kexec initscript run before they have a chance to be run (implemented with Required-Stop in the LSB headers).

Я не уверен, что безопасную очистку памяти нельзя сделать без kexec. Главное — удалить ту информацию в RAM, которая может содержать какие-либо юзерские данные.


Ещё в тему:


Мне озвучивали мнение о том, что в Linux'е ядро зануляет фоново оперативную память (так ли это?), что уменьшает опасность утечек при доступе к оперативке постфактум, но насколько быстро идёт процесс стирания для реальных данных после реальной работы (поглядел документ, посмотрел фильм, послушал музыку) — не ясно.

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

— pgprubot (17/08/2015 13:56, исправлен 17/08/2015 13:58)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Он ещё и новые утечки добавляет. К слову о скрытии процессов от других пользователей и разделении информации между пользователями: после выполнения sdmem ядро ругается на нехватку памяти, записывая в dmesg список текущих выполняющихся процессов и их параметры, а dmesg и т.п. логи* по умолчанию доступны для чтения всем пользователям системы.


* /var/log/{debug,dmesg,kern.log,messages,syslog} — содержимое этих файлов во многом дублирует друг друга.

— Yellow (18/11/2015 13:16, исправлен 18/11/2015 13:38)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Хотелось бы вернуться к вопросу загрузочного носителя. Выше говорилось





На внешней загрузочной флешке должны быть MBR+GRUB+{содержимое /boot}. Всех данных от силы пол-гига. В crypttab и fstab указаны UUID-ы, в том числе и загрузочного носителя, поскольку это упрощает практическую жизнь.


Пусть размер флешки 1Г. Копирование каждый раз всей флешки с помощью dd и последующее ее затирание – муторное дело.


Будьте добры, как можно повысить эффективность процедур, но так, чтобы при этом у флешки не поменялся UUID?

— pgprubot (20/11/2015 15:00, исправлен 20/11/2015 15:03)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Слишком много. На самом деле, их около 60 MB.



В crypttab — нет. В fstab UUID указан только для /boot, но и тут можно поменять на /dev/sdb1, например. А можно вообще эту строчку убрать из fstab, и каждый раз, когда нужно, монтировать /boot руками.


Другое дело — что UUID прописан и в initramfs на той самой флешке, с которой грузится система. В момент загрузки система ещё ничего не знает про crypttab и fstab, ей всё равно. Вот там поменять UUID — да, уже тяжелей. Я какой-то раз игрался, но не получилось. Правда, реальной необходимости его менять нет. Если вы делаете dd, UUID устройства не меняется.



Если изначально использовался компактный носитель для /boot, расширить его потом будет легко. Сузить уже существующий — сложнее, я этого никогда не делал, могу дать только теоретические советы. У меня полное затирание носителя занимает несколько десятков секунд, что вполне можно потерпеть.


Если в теории... могу выдать такие советы. UUID есть у устройств (/dev/sdb, /dev/sdb1) и у файловой системы. grub2 слишком умный. Скорей всего, если хоть один из UUID'ов поменяется, он откажется грузить систему.


Соответственно, есть 2 пути: либо назначать UUID'ы всем устройствам вручную, либо взять готовый образ и переделать его так, чтобы UUID'ы не поменялись. Первый способ более правильный, если получится. MBR можно будет перенести с помощью dd, всё остальное — через стандартные инструменты типа rdiff-backup и fdisk.


Второй способ тупее, но может оказаться проще. Я бы попытался как-то так:

  1. Снимаем образ с загрузочного носителя в файл посредством dd.
  2. Ищем способы сделать shrink (уменьшить размер) для файловой системы FAT, которая на /dev/sdb1 (но работаем сейчас не с носителем, а с образом). Есть утилита fatresize, но не уверен, что она это умеет. Вопрос в сети обсуждался, гуглите, результаты я после беглого чтения не понял.
  3. После уменьшения размера ФС уменьшаем размер (DOS'овского) дискового раздела на флешке. (Процедура аналогично ужиманию файловых систем на LVM: уменьшается ФС, потом ужимается LV, потом ФС расширяется до размеров ужатого LV).
  4. Когда всё ужали, как надо, таблица дисковых разделов будет исправленой. Осовбодившееся место можно будет просто выкинуть из таблицы разделов (fdisk).
  5. Берём dd и читаем нужное число секторов с образа — чтобы захватить только то пространство, которое адресовано новой таблицей разделов.
  6. Считанное число секторов в п.5. записываем в файл — это новый «ужатый» загрузочный образ.

Процедура сложная, тут может понадобиться погуглить, поэкспериментировать, поизучать процесс, хотя заранее понятно, что её сделать можно.


Есть ещё один способ, куда более тупой. Поскольку на носитель записывается и затирается меньше 100MB каждый раз, вы можете затирать не всего его, а только его часть. Затирание, таким образом, будет не столь надёжным, но его надёжность можно будет на каком-то уровне проверить экспериментально — выяснить, меняются ли данные при записи dd в конце носителя (точнее, за тем пространством, которое вы затираете).

— Yellow (29/11/2015 16:03, исправлен 29/11/2015 16:04)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Спасибо. Вашей развернутой инфой обязательно воспользуюсь, т.к. назрела необходимось переделки всей системы по практическим причинам. В настоящий момент пришлось воспользоваться самым простым и тупым способом из предложенных:



Копировалось, затиралось и восстанавливалось с помощью dd первых 100MiB данных, которые уверенно включают MBR и /boot (и одновременно помнить цифру 100 просто). Затирание производилось как с помощью /dev/zero, так и с помощью /dev/urandom.


При всех указанных операциях, данные после первых 100MiB не изменяются. Проверялось командой



После восстановления данных с помощью dd, UUID не изменяется, как Вы и указывали.

— Yellow (03/12/2015 11:49, исправлен 03/12/2015 12:22)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Читая форум, решил попробовать упростить схему бессигнатурки. Сейчас схема такая: бессигнатурно шифрованный хард, внутри которого LUKS, разбитый на LVM-разделы. Какие чисто пользовательские подводные камни возникнут, если сделать по-другому, как в заметке – на харде будет прямо LUKS (с LVM или без, без разницы), заголовки которого вынесутся на внешний носитель, где уже есть MBR и /boot?

— pgprubot (04/12/2015 14:28, исправлен 04/12/2015 14:58)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Хорошо, но лучше, если вы этот способ будете применять не к флэшкам, SSD-дискам или SD-карточкам, а к обычным HDD-дискам (например, подключаемым по USB), поскольку частичное затирание данных достаточно надёжно (для современных используемых носителей) только для последних. Иначе говоря, если есть HDD, который можно использовать только как загрузочный диск, это хорошо, он и затраться будет быстрее флэшек.


То, что ничего за пределами первых 100MiB не меняется, следует, как я понимаю, из особенностей таблицы разделов, располагающейся в начале диска, и файловой системы FAT. Если бы вместо FAT было бы что-то менее примитивное, скорей всего, как минимум, была бы ругань ОС на обрезанную файловую систему. Не знаю, как NTFS, но типичные UNIX'овские ФС пишут так называемые суперблоки в разных местах ФС при её создании, т.е. нет такого, что за пределами какого-то объёма точно нет служебных метаданных.



Если тёрли нулями какой-то раз чисто для тестов, это ещё ладно, но в нормальной рабочей схеме никогда не затирайте ничего нулями — только рандомом, поскольку нули рушат отрицаемость всей схемы.



Сначала комменты по поводу самой заметки:


It is absolutely NOT POSSIBLE to decrypt the LUKS device without the header because of the SALT in it. No known technology could decrypt the device without the SALT. That’s a very strong cryptographically NOT POSSIBLE. It would take something far beyond quantum computing.

Автор путает тёплое с мягким. Соль, хидер, LUKS — это всё инструменты для вывода мастер-ключа. Если КК будет брутфорсить просто AES как алгоритм, т.е. сам мастер-ключ, ему всё равно, откуда он взялся. Если следовать рекомендациям АНБ, нужно крутить режимы, а хидеры ни на что не влияют. AES-128 на КК превращается в 64-битный шифр, и это плохо. Чтобы было хорошо, нужно брать AES-256 и 256-битный случайный ключ в качестве пароля. С точки зрения опций, это те самые -c aes-xts-plain64 -s 512 -h sha512.


cryptsetup luksFormat /dev/sda --header /dev/sdb --align-payload=0

Во-первых, автор, кажется, не совсем понимает смысл команды luksFormat. Во-вторых, --align-payload=0 должно нормально заработать только в 1.6.7, а в более ранних версиях эта опция попросту игнорируется.


luksFormat всего лишь записывает LUKS-хидер на какое-то устройство или в файл. Это устройство/файл потом просто будет проверять введённую пассфразу и выдавать мастер-ключ для расшифрования целевого устройства. Каким будет целевое устройство — абсолютно неважно. Иными словами говоря, на стадии luksFormat можно вообще не указывать, к какому устройству будет применяться создаваемый хидер. Кроме того, одним хидером можно расшифровывать разные устройства (так делать не советуется, но технически это возможно, если разные устройства используют один и тот же хидер, а, следовательно, и один и тот же мастер-ключ).


В принципе, вот это должно бы работать (даже с несуществующим файлом tmpLUKS):

# cryptsetup -q -c aes-xts-plain64 -s 512 -h sha512 --header /tmp/tmpLUKS luksFormat
но синтаксис cryptsetup'а этого не позволяет. Эта команда могла бы создавать файл tmpLUKS и записывать туда LUKS-хидер. Можно создать пустой файл tmpLUKS и/или в конце команды указать /dev/null как фейковое целевое устройство для шифрования, но это тоже не помогает. Думаю, разработчиков LUKS можно было бы убедить в том, что такое поведение cryptsetup'а нелогично.


Рабочий метод есть, и он примитивен:

# dd if=/dev/urandom of=/tmp/tmpLUKS bs=1M count=5
# cryptsetup -q -c aes-xts-plain64 -s 512 -h sha512 luksFormat /tmp/tmpLUKS
# cryptsetup --header /tmp/tmpLUKS luksOpen [устройство] mydevice_crypt
Т.е. в случае автора было бы достаточно написать
# cryptsetup luksFormat /dev/sdb
вместо
# cryptsetup luksFormat /dev/sda --header /dev/sdb --align-payload=0


Я взял 5MB для файла с хидером, что было с запасом, потому что размер хидера может отличаться в зависимости от версии cryptsetup'а. Когда хидер на файле уже создан, его можно ужать до актуального размера с помощью команды luksHeaderBackup:

# cryptsetup luksHeaderBackup /tmp/tmpLUKS --header-backup-file /tmp/pure_header
Файл pure_header короче; он будет занимать, скорей всего, 2MB. Далее можно пользоваться уже только им в качестве опции для --header.


Идём далее. Следующая команда по ссылке:

# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y --header container.h \
  --align-payload=0 container

С учётом вышеприведённых замечаний она эквивалентна такой:

# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -y \
  --align-payload=0 luksFormat container.h
причём --align-payload=0, скорей всего, тоже можно убрать.


Следующие команды:

# losetup /dev/loop0 container
# cryptsetup luksOpen /dev/loop0 --header container.h cont

Это усложнение (первая команда) просто не нужно — cryptsetup сам догадается рассмотреть файл как блочное устройство, поэтому можно писать напрямую:

# cryptsetup --header container.h luksOpen container cont
Соответственно, не нужны и команды losetup -d потом. Кроме того, вместо luksClose в современных версиях cryptsetup можно писать remove — тип устройства он определяет сам.




Теперь вернёмся к самому вопросу. Да, метод правильный и логичный: вместо двойного шифрования просто пользоваться откреплённым хидером. Думаю, его можно было бы класть отдельным файлом в /boot. В крайнем случае, можно было бы создать отдельный дисковый раздел на загрузочном носителе, и класть хидер туда в виде файла (или сам этот дополнительный дисковый раздел использовать как хидер).


Проблемы могут быть только в автоматизации процесса и в установке системы на такую конфигурацию. При установке внешний бессигнатурный слой всё равно создавался вручную (см. пункт 3), поэтому отличий не будет — точно так же в командной строке создаём и устройство и хидер. Понятно, что в crypttab инсталлятор вряд ли догадается прописать хидер, поэтому первая загрузка будет в ручном режиме с указанием всех опций cryptsetup'а из командной строки grub'а, но потом можно будет crypttab подправить на нужный — вдруг можно добиться автоматической загрузки и для такой конфигурации? Первая строчка crypttab'а должна быть, думаю, какой-то такой:

cryptroot /dev/sda none header=/dev/sdb2,luks,initramfs
если загрузочное устройство — /dev/sdb, /boot находится в /dev/sdb1, а раздел /dev/sdb2 содержит LUKS-хидер. Если хидер в файле в /boot, может быть, надо писать header=/boot/header_file, но это надо проверять, т.к. я не уверен, что на стадии командной строки grub/boot уже есть и подмонтирован в этот каталог.


Последнее, на что стоит обратить внимание — опция --align-payload. Если она везде указывалась в версии 1.6.6, оффсет будет всё равно ненулевой (и если не указывалась, то тоже). Потом вы обновляете систему и получаете cryptsetup 1.6.7, где опция трактуется правильно — соответственно, автоматическая загрузка сыпется, всё перестаёт работать. Конечно, указанием правильного значения для --align-payload всё можно будет поправить, чтоб работало, как и раньше, но учтите этот подводный камень — можете в будущем об него споткнуться.

— Yellow (31/12/2015 12:01, исправлен 31/12/2015 12:35)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Вижу, что опять задал простой вопрос. :-) Большое спасибо, уже пробую.



Возник легкий практический затык на пользовательском уровне. Если загрузочная файловая система на внешнем носителе всего 100MiB (включая MBR), то в рамках обновления системы не хватает места для обновления /boot. Вижу всего два варианта решения – или перед каждым обновлением ядра увеличивать ФС с /boot на борту и потом умешьшать обратно (проверено с некоторыми диск-менеджерами и разными ФС, работает без ошибок), или размер ФС увеличить перманентно.


Есть еще варианты?


Второй пользовательский затык. Порядок действий: грузимся с Live-CD, записываем загрузочный раздел на флешку с бессигнатурно шифрованного харда, перезагружаемся, делаем плановое обновление системы. Теперь хотим записать обновленный загрузочный раздел с флешки обратно на хард, но не тут то было. В запущенной системе уже имеются подмонтированные разделы с данного харда, поэтому система не позволяет подмонтировать другую область того же самого харда, где хранится загрузочный раздел для флешки. Это означает, что надо опять грузиться с болванки для одной единственной операции.


Как сделать наиболее эфективно, чтобы было поменьше действий?

— pgprubot (02/01/2016 17:15, исправлен 02/01/2016 17:18)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Если места на самом носителе, используемом как загрузочный, достаточно, никто не запрещает аналогичным образом использовать, например 200MiB вместо ста. Увеличить размер ФС проще, чем уменьшить. Раз вам удалось сжать до 100, почему бы не повторить процедуру для 200? Можно вообще всё пространство носителя использовать как загрузочное, а затирать только начало — вы же сами убедились, что за пределами какого-то числа первых секторов данные всё равно не пишутся.



Не понимаю, зачем вам такие сложности. Какая разница, куда на бессигнатурно шифрованном носителе будет сохранён загрузочный образ? Сохраняйте его просто файлом на какой-либо внутренней файловой системе на нём — именно её вы и должны монтировать с LiveCD, чтобы забрать оттуда образ (снимаете бессигнатурный слой, потом LUKS, потом LVM, потом на какой-то стадии добираетесь до ФС, оттуда выцепляете файл с загрузочным образом и записываете его на временный загрузочный носитель). Можете загрузочный образ хранить хоть в корневой файловой системе: главное — что с LiveCD вы до любой информации на этом носителе можете добраться, где бы и как бы она ни была записана.

— pgprubot (11/01/2016 18:39, исправлен 11/01/2016 18:41)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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


Хорошо, что хоть вообще ОС грузится. Эта новость лишний раз подтверждает нестандартность и опасность всей схемы. Например, по этой причине могли отвалиться все обновления ОС: пока проблемы не решишь, пришлось бы работать на необновлённом ядре с дырами.

— pgprubot (24/01/2016 10:08)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Последующее обновление системы устранило эту проблему; теперь всё снова работает так же, как и раньше.
— pgprubot (08/03/2016 19:47, исправлен 08/03/2016 20:32)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Ресайз сделал — всё работает, как и описывал. Берём готовый внешний загрузочный носитель, монтируем его в /boot, смотрим размер ФС. Делаем, например, resize2fs /dev/sdb 70M — ужимаем размер файловой системы до 70 MB, этого должно бы хватать. Потом запускаем fdisk -l -u /dev/sdb и смотрим на таблицу секторов. 2048 секторов (1MB) в начале — это MBR + таблица разделов, далее идёт ФС. Возьмём размер раздела с запасом — допустим, 80 MB. Значит, количество первых используемых секторов на флешке будет X=2048+80*1024*1024/512+1 (1 — потому что в fdisk Size раздела почему-то на 1 больше, чем разница между Start и End; возможно, это MBR так учитывается, не знаю). Короче, X-2048 — новый размер раздела в секторах. При редактировании fdisk не меняет ничего в данных, а только редактирует таблицу разделов, хранящуюся в фикисированном месте в начале диска. Запускаем fdisk /dev/sdb, удаляем имеющийся раздел (скорей всего, он один), и добавляем новый с 80 MB места. Первый сектор так же будет 2048, конечный сектор — вводим число X. Потом меняем командой "t" тип раздела на исходный (83 — Linux) и командой "a" делаем разделу bootable-флаг. В общем, это всё. Теперь снова запускаем resize2fs /dev/sdb, и она расширит ФС с 70 MB в точности до нового чуть большего размера — 80MB (там, где просят сделать e2fsck -f, делаем). Флешка готова и урезана, теперь остаётся только снять с неё образ до указанного места: dd if=/dev/sdb of=/path/to/file.img count=X. Получается новый образ, который занимает примерно 81 MB, его можно копировать на загрузочный носитель, когда нужно загрузиться. Правда, если речь о флешках, затирать потом нужно всё равно всё пространство, а не только первые 81 MB.


Были идеи упростить эту процедуру, но они не сработали. Например, можно создать образ, в котором первый мегабайт тот же, что и в /dev/sdb, а на оставшемся месте нарезана та же файловая система. С помощью rdiff-backup туда можно перенести файлы c /boot с сохранением всех атрибутов. Получается вроде бы валидный образ, grub загружается, но потом продолжить загрузку не может, т.к. uuid не совпадает. Попытки на лету убрать UUID'ы в меню тоже не приводят к успеху, т.е. grub'у нужна строго та же ФС, какая была изначально. Кстати, образы дисков можно легко монтировать на лету как mount -o offset=$((2048*512)) boot.img /path/toloop-устройство создаётся автоматически.




Другая интересная идея — отказаться от использования внешнего носителя при обновлении системы (типа apt-get upgrade), т.к. это, прежде всего, влечёт за собой много лишних действий. Если просто подмонтировать образ носителя в /boot, команды update-grub и update-initramfs -u (иногда ещё надо -t указывать) отрабатывают, но создаваемый образ не грузится — grub слишком умён и прописывает loop-устройство как загрузочное (причём во многих местах) вместо конвенциональных set root='hd1,msdos1' и т.п. Теоретически это можно потом править своим скриптом, но такое решение грязное, а исправлений будет много. Можно ли сделать чище? Оказывается, можно.


Фактически, дело за малым — надо объяснить системе, что некий образ — это реальное устройство /dev/sdb, а не что иное. Может быть, это можно порулить какими-то грязными хаками и симлинками в /dev, но, оказывается, есть простой и изящный трюк — проброс устройств в Xen. Его можно установить, он проапдейтит ядра и таблицу вариантов загрузки в grub, а всё остальное останется, как и раньше — т.е. отличий работы на обычном ядре и на паравиртуальном ядре в dom0 особо никаких нет. Однако, если основная ОС загружена именно как дом 0, появляется возможность использовать утилиту управления домами xl. Xen поддерживает переброс на лету между гостевыми ОС (domU) множества всякого харда — дисков, сетевых и PCI-устройств. Проброс дисков обычно делается из дома 0 в какой-то дом U, однако... в сети есть указание, что никто не запрещает пробрасывать устройства из дома 0 в дом 0. :-) Т.е. мы берём какой-то образ и закидываем его самим себе как новый виртуальный диск.


В VG создаём LV для загрузочной флешки, размер выбираем равным размеру готового образа (ужатого, как описано выше, например) + 2 MB на LUKS-хидер — получается примерно 83 MB (если делать, как выше). Нарезаем на новом LV хидер LUKS, открываем устройство, внутрь через dd записываем наш образ загрузчной флешки. Когда всё готово, перекидываем его самим себе:

# xl block-attach 0 phy:/dev/mapper/DEVNAME_crypt sdb w
Теперь по теории в системе должен появиться диск /dev/sdb. Однако, ОС слишком умная и принимает его к себе как Xen-диск, т.е. xvdb. К счастью, это не будет фатальным. Далее монтируем его (mount /dev/xvdb1 /boot) и можем выполнять обновление системы, update-grub и т.д. Когда всё сделано, делаем umount /dev/xvdb1, возвращаем устройство от самих себя себе:
# xl block-detach 0 sdb
а потом с помощью dd содержимое устройства /dev/mapper/DEVNAME_crypt складываем в базу данных загрузочных флешек как файлы boot.img, готовые к переносу на внешние носители. LUKS на LV-устройстве с образом теперь можно закрыть через luksClose — подмонтированный /boot в норме системе не нужен, он только для обновлений.


Это работает. Странно, что хотя 'hd1,msdos1' более не пишется, grub это не смущает. Если подключение (монтирование) /boot и отмонтирование скриптовать, после/перед xl-командами следует сделать паузы хотя бы в 1 сек через "sleep 1", потому что виртуальное устройство появляется/исчезает не моментально.



Кстати, Xen умеет очищать RAM от старых данных перед загрузкой: добавляем опцию

GRUB_CMDLINE_XEN_DEFAULT="bootscrub=1"
в /etc/default/grub и делаем update-grub. При загрузке потом об этом будет писаться, можно посмотреть и непосредственно:
# xl dmesg |grep scrub
(XEN) Scrubbing Free RAM: .done.

— Yellow (02/11/2016 10:10, исправлен 02/11/2016 10:21)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

В рамках работы над совершенствованием системы решил пошагово проверить затирание части флешки. Оказалось, что может быть сюрприз. Действия:


1. Затираем флешку



2. Снимаем с нее хеш, отступив от начала на 100MiB, на которых потом будет партиция



3. С помощью gparted создаем MBR.


4. Повторяем шаг 2...


...и обнаруживаем, что хеши НЕ соответствуют. Оказывается, при создании MBR gparted пишет в конец носителя нули. Проверялось созданием дампа конца флешки



Больше сюрпризов не было. Идем дальше.


5. Затираем флешку, отступив все тех же 100MiB



6. Снимаем хеш, как во втором шаге.


7. С помощью gparted создаем партицию FAT32 размером 99MiB (gparted резервирует первый 1MiB, наверное в связи с MBR). Проверяем, чтО мы создали (выхлоп команды опускается)



8. Снимаем хеш, как во втором шаге, и убеждаемся, что он не изменился.


9. Экспериментируем с затиранием первых 100MiB и созданием в их рамках разных файловых систем. Этим убеждаемся, что это ни в коем случае не затрагивает остальную часть флешки. Прверялось на


FAT32
ext4
reiserfs
ntfs

— pgprubot (02/11/2016 21:49, исправлен 02/11/2016 21:52)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Есть умные программы со сложной логикой, предназначение которых — продумывать детали за вас, пользователя. Когда вы используете такие программы, не удивляйтесь, что эти интеллектуальные исполнители ваших желаний продумают детали за вас, опираясь на свою логику и широко экстраполируя ваши намерения на те тонкости действия, которые вы явно не оговорили (явно оговорить не всегда бывает возможно).


Gparted — GUI-шная приблуда к parted, который сам по себе не так прост как кондовый fdisk. Каждый следующий уровень усложняет логику и контроль простых действий. Делайте всё простыми предсказуемыми инструментами — и не будет никаких сюрпризов.


Возможно, там использовалось какое-то выравнивание геометрии, из-за чего конец оказался неразмечен, а потом завайплен нулями. Возможно, конец как-то предполагается использовать в качестве резервного места хранения для таблицы разделов. По вашему описанию ничего похожего в сети не ищется, а своего опыта с parted у меня нет — остаётся только гадать.


Говоря простым языком, ваш комментарий сводится к следующему: при первичном форматировании диска и установке MBR parted зачем-то пишет нули в конце диска, но при последующей работе с дисковыми разделами этого не наблюдается — конец не трогается.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3