Re: [Sysadmins] шифрование корневого раздела

Re: [Sysadmins] шифрование корневого раздела

[Michael Shigorin]

On Mon, May 30, 2016 at 01:42:28PM +0300, Serge R wrote:
> Использую систему, установленную с basealt-p8-server-20160429-x86_64.iso
> Пытаюсь зашифровать корневой раздел, используя cryptsetup.

В смысле при установке или уже после вручную?

> При вводе пароля получаю такую ошибку (см. вложение).
> Что необходимо мне предпринять?

Как вариант, попробовать штатный способ. :)
Например, сперва в виртуалке.

PS: установлен ли пакет make-initrd-luks?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] шифрование корневого раздела

[Michael Shigorin]

On Mon, May 30, 2016 at 04:10:10PM +0300, Serge R wrote:
> > Использую систему, установленную с basealt-p8-server-20160429-x86_64.iso
> > Пытаюсь зашифровать корневой раздел, используя cryptsetup.
> >>В смысле при установке или уже после вручную?
> делаю после вручную

Лучше сразу инсталятором, если корень.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] шифрование корневого раздела

[Michael Shigorin]

On Tue, May 31, 2016 at 08:43:57AM +0300, Serge R wrote:
> Не шифрованный /boot как то может влиять на взлом шифрованных разделов?

Теоретически это тоже стартовая площадка, практически же такую
работу я бы пытался начинать скорее со своего загрузочного
носителя.

> Пока, предполагаю, разница в именовании криптового устройства (через
> инсталятор создается sdaX_crypt, у меня было другое). Буду проверять.

sdXY_luks, точнее.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] шифрование корневого раздела

[Michael Shigorin]

On Tue, May 31, 2016 at 01:22:08PM +0300, Serge R wrote:
> >>Не шифрованный /boot как то может влиять на взлом шифрованных разделов?
> >Теоретически это тоже стартовая площадка, практически же такую
> >работу я бы пытался начинать скорее со своего загрузочного
> >носителя.
> Планируется ли реализация в дистрибутиве шифрованного /boot?

Мной пока не планируется за отсутствием видимого смысла --
если кто-либо заинтересован сделать, видимо, начинать надо
будет с выяснения текущей ситуации поддержки в grub2.

> Появилось еще пара вопросов по шифрованию:
> 1) При шифровании с aes-xts-plain64 нет поддержки этого
> алгоритма при загрузки системы.  Как добавить этот модуль
> в initrd? (работает только с aes cbc-essiv:sha256)

Например, указать в MODULES_ADD в /etc/initrd.mk

> 2) Можно ли реализовать ввод пароля только на корневом разделе,
> а остальные разделы расшифровываются по ключу?

Это надо смотреть документацию cryptsetup и, возможно,
https://bugzilla.altlinux.org/show_bug.cgi?id=28255#c41
-- сам не сталкивался.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] шифрование корневого раздела

[Michael Shigorin]

On Wed, Jun 15, 2016 at 05:55:27PM +0300, Serge R wrote:
> С помощью инсталлятора за май так и не получилось установить Linux на
> шифрованный раздел (включая корневой). /boot делал отдельный нешифрованный.

Если что, уже 20160612: http://nightly.altlinux.org/p8/release/

> Так же не удалось установить систему на raid1, на котором лежит корень.
> На 6 шаге (сохранения параметров) выдает ошибку и система
> перегружается.

Вот это странно, хорошо бы притормозить вывод после слетания
инсталятора (или сразу грузиться с добавлением параметра
instdebug, чтоб обложить его добавочными шеллами) и вытащить
/tmp/*.log -- особенно интересует remount.log.

> Пришлось ставить Linux без raid и без шифрования, и
> реализовывать все эти вещи (шифрованный рейд) руками.
> Как результат, могу сказать, что так работает.

Ну это не дело...

> Можно ли в будущей версии инсталлятора реализовать указание
> имени раздела, для которого запрашивается пароль?  Почему
> прошу, так как заметил, что порой, при загрузке ядра изменяется
> порядок имен разделов, для которых вводится пароль шифрования.
> Заранее благодарен.

Повесьте багу на компонент alterator-luks:
https://bugzilla.altlinux.org/enter_bug.cgi?product=Sisyphus
(вероятно, дальше она ещё куда-то переедет, но пока так)

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

Очень бы хорошо было, если б прокопали тематику на предмет
уже известных реализаций -- а пока гляньте вот эти баги:
https://bugzilla.altlinux.org/show_bug.cgi?id=28082
https://bugzilla.altlinux.org/show_bug.cgi?id=28255

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Sysadmins] шифрование корневого раздела

[Michael A. Kangin]

Немножко оффтопика, опишу для гугля как я у себя делал систему.

Дано: новенький рабочий компьютер с 4 HDD и 1 SSD.
Надо всё зашифровать по максимуму (/, swap) и поиметь максимально 
быструю при этом дисковую систему, утилизируя SSD и 4 шпинделя.

В основу кладём уже используемую мной ранее схему - разделы с редкой 
записью - /boot, /, /usr (разделы по отдельности или вместе) кладём на 
ssd, из дисков (сырых, безраздельно) делаем raid10, на котором размещаем 
LVM, из которого нарезаем /var, /home, swap, и далее по потребностям. 
Потребности можно кстати оставить вообще пока невыделенными, и потом 
увеличить любой требуемый раздел. При выходе из строя HDD просто 
вынимаем его, вставляем новый, и никак не размечая, запускаем ребилд.

Но при такой схеме используется только маленькая часть самого маленького 
SSD, много ли там на /usr надо. Так что попробуем еще и bcache. Большую 
часть SSD пускаем на кеширование, и кешировать будем весь md0, который у 
нас raid10 на 4 сырых дисках. Да, с точки зрения надёжности наверное 
стоит пустить на кеширование отдельное зеркальце из пары отдельных SSD, 
но у меня тут не Ынтерпрайз, а скромная рабочая станция :)

Хорошо, но куда же тут прилепить шифрование?
А шифровать мы будем посерединке между bcache и LVM.
Т.е., с одной стороны, у нас уже сразу целиком зашифрованный PV, дальше 
можно по-раздельно уже не париться. С другой стороны, сам b-кеш на SSD 
тоже скидывается зашифрованный, на радость моей паранойе.

Ну и корень с /usr, которые остались на SSD вне LVM. Их же тоже надо 
зашифровать. Ну, это простенько - ни рейдов, ни кешей, ни LVM, обычный 
простой раздельчик.
Только вот беда - теперь при старте системы пароль спрашивается два раза 
- на / и на LVM. Внутренний полузадушенный перфекционист негодуэ.
Выход из этой ситуации - для расшифровки брать ключ не с клавиатуры, а 
из некоего файла или устройства. Недушенный перфекционист прикрутил бы 
смарт-карту с двухфакторной авторизацией, но мой такого не осилил. 
Поэтому ключ мы храним просто где-то в файле, который на этом же диске, 
и является в свою очередь криптоконтейнером. Который мы открываем 
паролем, вводимым с клавиатуры при старте системы. Но всего один раз! 
Сколько бы мы потом разделов не нашифровали себе.

Ладно, извращаться, так по крупному. Всё в этой схеме хорошо, но этот 
компьютер я постоянно использую и удалённо, из дома. Что, если он там 
без меня соскучится, зависнит, перезагрузится, электричество моргнёт?
Я могу попросить коллегу нажать там резет, но не сдавать же пароли чтобы 
отпереть диск?
Это мог бы сделать я и сам, по сети. Жаль что груб2 её не умеет :)
Тогда мы приходим к пониманию необходимости еще одной, 
минимальной-вспомогательной системы на нашей SSDшечке. Её заботой будет 
загрузиться, поднять сеть, запустить OpenVPN для обхода NAT-ов (у меня 
хоть и есть прямой IP, но подстраховаться никогда не помешает), 
запустить sshd, и спрашивать пароли, на физической консоли и при 
ssh-подключениях. Если там или там был введён пароль, которым удалось 
раскрыть наш криптоконтейнер с главным ключом, мы открываем им наш 
основной криптованный рут, LVM, и делаем pivot_root в основную систему.
Или, если пароля не ввели, можно например перезагрузиться, или выпасть в 
консоль вспомогательной системы, или показать котика дня. Ведь по 
существу ничего, кроме котиков, хранить в незашифрованной системе нельзя 
(здесь должна быть КДПВ с котиком).

Вот, собственно, такая система была реализована на базе P7 и живёт и 
здравствует уже почти полтора года.

Плюсы - высокое быстродействие (если верить fio и субъективным 
ощущениям), вроде-бы криптобезопасность, ну и удобство использования, 
насколько это возможно.

Из минусов - некоторый геморрой создания всего этого. Штатный 
инсталлятор, разумеется, и десятой части всего этого изврата не осилит, 
поэтому основная работа происходит из лив-системы, с последующим 
разворачиванием образа готовой системы в подготовленное место (можно 
использовать, например, ALT Linux Live имени enp@).
Вспомогательная система у нас должна быть аналогична по пакетному 
составу основной (совершенно точно должно совпадать версия ядра, скорее 
всего и всякие libc), за этим надо специально следить при обновлении.
Наличие только одного нерезервируемого SSD внушает некоторые опасения, 
поэтому я время от времени делаю копию рута/бута на диски. Возможно 
подумаю потом о зеркалировании SSD, хотя уже и устройств пихать некуда :)

Получившаяся разбивка SSD:
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 468862128 sectors, 223.6 GiB
...

Number   Size       Code  Name
    1    256.0 MiB   EF00  EFI System
    2    8.0 MiB     EF02  BIOS boot partition
    3    256.0 MiB   8300  Linux filesystem
    4    2.0 GiB     8300  Linux filesystem
    5    24.0 GiB    8300  Linux filesystem
    6    197.1 GiB   8300  Linux filesystem

3 - boot, 4 - вспомогательная система, 5 - шифрованный рут+usr основной 
системы, 6 - кеш.


HDD-диски в lsblk выглядят так:

sdb                          8:16   0   1.8T  0 disk
└─md0                        9:0    0   3.7T  0 raid10
   └─bcache0                252:0    0   3.7T  0 disk
     └─cr-lvm (dm-2)        253:2    0   3.7T  0 crypt
       ├─VG0-lv_var (dm-0)  253:0    0    64G  0 lvm    /var
       ├─VG0-lv_home (dm-3) 253:3    0   2.9T  0 lvm    /home
       └─VG0-lv_swap (dm-4) 253:4    0    32G  0 lvm    [SWAP]
sdc                          8:32   0   1.8T  0 disk
└─md0                        9:0    0   3.7T  0 raid10
   └─bcache0                252:0    0   3.7T  0 disk
     └─cr-lvm (dm-2)        253:2    0   3.7T  0 crypt
       ├─VG0-lv_var (dm-0)  253:0    0    64G  0 lvm    /var
       ├─VG0-lv_home (dm-3) 253:3    0   2.9T  0 lvm    /home
       └─VG0-lv_swap (dm-4) 253:4    0    32G  0 lvm    [SWAP]
sdd                          8:48   0   1.8T  0 disk
└─md0                        9:0    0   3.7T  0 raid10
   └─bcache0                252:0    0   3.7T  0 disk
     └─cr-lvm (dm-2)        253:2    0   3.7T  0 crypt
       ├─VG0-lv_var (dm-0)  253:0    0    64G  0 lvm    /var
       ├─VG0-lv_home (dm-3) 253:3    0   2.9T  0 lvm    /home
       └─VG0-lv_swap (dm-4) 253:4    0    32G  0 lvm    [SWAP]
sde                          8:64   0   1.8T  0 disk
└─md0                        9:0    0   3.7T  0 raid10
   └─bcache0                252:0    0   3.7T  0 disk
     └─cr-lvm (dm-2)        253:2    0   3.7T  0 crypt
       ├─VG0-lv_var (dm-0)  253:0    0    64G  0 lvm    /var
       ├─VG0-lv_home (dm-3) 253:3    0   2.9T  0 lvm    /home
       └─VG0-lv_swap (dm-4) 253:4    0    32G  0 lvm    [SWAP]

Re: [Sysadmins] шифрование корневого раздела

[Michael A. Kangin]

18.06.2016 12:27, Alexey Shabalin пишет:

> Не понятно, зачем во всей этой схеме mdadm? lvm давно умеет raid. А ещё
> проще перейти на btrfs, избавившись и от mdadm и от lvm.

Да привык как-то, что каждая система должна заниматься своим делом, зато 
заниматься им хорошо. md заточен под рейды, у него инструментарий для 
этого богатый, мониторинг там, всякие bitmap и тд.

btrfs примерно по тем же соображением, кроме того она сыровата пока 
к.м.к., ну и помнится апологеты райзерфс сильно ругали её на 
архитектурном уровне.
Я уж тогда bcachefs подожду. %)