Re: Снова о ZFS
*** artiom [2018-01-08 04:28]:
>Да, вспомнил тему: солярис использует снэпшоты для отката обновлений.
>FreeNAS, как я заметил, тоже.
Я и руками это делаю перед обновлением системы -- это очень удобно.
>Ну предполагается, что журнал пишется синхронно с записью данных.
В ZFS все записи (данных, изменённых метаданных) какое-то время
агрегируются в памяти, а потом сбрасываются одним большим куском на
диски. fsync для ZIL означает что эти данные не ждут когда они
накопятся, а сразу же записываются на диск, но только в особую для ZIL
область и только потом они уже распределяются по дискам нормально,
штатно.
http://www.freenas.org/blog/zfs-zil-and-slog-demystified/
Тут вот они и говорят, что сначала данные запишутся в short-term ZIL
область, а только потом, второй раз ещё запишутся учитывая все эти RAIDZ
конфигурации и прочее. То есть писаться они будут по два раза. Отдельное
log устройство как-раз просто и выносит эту short-term область на
отдельный диск.
>Эм... Сейчас у меня только одна SSD и та - системная.
>А ведь потеря части ZIL мне грозит лишь частичной потерей последних
>транзакций?
Потеря ZIL грозит потере части транзакций последних, верно. Но просто
получается что с точки зрения ОС выполнен fsync, а на самом деле, при
потере log устройства мы всё-равно теряет данные как-будто fsync-а не
было. Если бы не было log-устройства, то fsync на обычные диски в RAIDZ
надёжен -- при вылете одного из дисков всё-равно данные есть. Поэтому
если вам так не нужна надёжность fsync-ов и не хочется чтобы проседала
скорость от них, то можно просто zfs set sync=disabled выставить -- и
скорость не просядет и надёжность не зависит от вылета несдублированного
log устройства. Но это моё личное мнение :-). Насколько знаю, log-device
нужен тем у кого нагруженные почтовые сервера, СУБД всякие. А так ведь
не сказать что много софта нуждается в fsync-е.
>> Для тех кто готов "сливать" только факт изменения всего блока, но не
>> конкретной позиции в нём, есть режим EME -- который делает двойное
>> шифрование (туда-обратно), что в два раза дороже для CPU, но да --
>> надёжнее.
>Каким образом он сливал? Вряд ли хранил в незашифрованном журнале.
>Я так думаю, что дисковое шифрование нужно для предотвращения
>оффлайновых атак, разве нет?
Смотрите, у вас есть 512-байт блок жёсткого диска. Он шифруется в CBC
режиме: то есть это 32 128-битных блока симметричного шифра. Вы
перезаписываете данные в этом секторе диска, но начиная например с
300-го байта. Само собой весь блок физически на диск записывается с
нуля, но перед этим он перешифровывается. Ключ у вас точно такой же как
и был прежде, изменяемого вектора инициализации нет (его просто негде
хранить на диске), и первые 16 128-битных блоков такие же как и были
прежде -- поэтому их перешифрование произведёт абсолютно точно такой же
шифротекст как и был прежде. Но с 17-го блока (288-го байта внутри
сектора) блок шифротекста уже поменяется. Если злоумышленник видел каким
был блок до этой перезаписи и после, то он и видит что в этом секторе вы
начали что-то менять в пределах с 288-304 байт этого сектора.
Данные само собой не слились, но данные об этих данных (метаинформация)
выдаёт где именно эти данные менялись. Так же как сделав LUKS/GELI на
чистом диске, вы всё-равно видите что диск забит на 100% сплошными
нулями и значит, хоть он и зашифрован, но ещё не использовался и данных
на нём не было.
Я когда-то очень давно (больше 10 лет назад) писал вот такую статью:
http://www.stargrave.org/Disk-encryption.html
само собой не я придумывал все эти атаки, а просто собирал из разных
источников эти знания в одной статье. Атак много разных. И до
изобретения XTS режима (и tweakable block cipher) вы или мирились с
двойным проседанием по скорости (по CPU) или шли на жертвы по разным
атакам. Вот у меня дома жёсткие диски, но дома кроме меня, грубо говоря,
никогда никого не бывает и я не представляю что в моё отсутствие кто-то
приходил, вынимал диски, что-то с ними делал, вставлял обратно, итд. Я
готов мириться с такими видами атак и поэтому вряд ли бы жёг на них свой
CPU (хотя понимаю что сейчас производительность CPU такая, что все эти
лишние перешифрования на скоростях НЖМД -- копейки).
>> Или вот GELI/LUKS по-умолчанию не предоставляют никакой
>> аутентификации данных, так как это начнёт занимать дополнительное место,
>> но тоже не самый безопасный вариант.
>В смысле?
GELI по-умолчанию делает просто XTS шифрование и не более. Вы можете
спокойно изменить зашифрованные данные на диске и никто вам не скажет
что их аутентичность/целостность нарушена. Полнодисковое шифрование
требует чтобы никакого дополнительного места под это шифрование не
занималось (ну не считая заголовков LUKS/GELI само собой). LUKS,
насколько помню, тоже просто делает XTS/CBC/whatever шифрование --
аутентификации нет. В GELI это можно включить, но (кроме потери скорости
из-за HMAC операции (судя по man, там только HMAC)) вы, при
использовании, потеряете ощутимо места.
-a aalgo Enable data integrity verification
(authentication) using the given
algorithm. This will reduce the
size of storage available and also
reduce speed. For example, when
using 4096 bytes sector and
HMAC/SHA256 algorithm, 89% of the
original provider storage will be
available for use. Currently
supported algorithms are: HMAC/MD5,
HMAC/SHA1, HMAC/RIPEMD160,
HMAC/SHA256, HMAC/SHA384 and
HMAC/SHA512. If the option is not
given, there will be no
authentication, only encryption.
The recommended algorithm is
HMAC/SHA256.
>Это да. Но во-первых, они предлагают сделать перезапись свободного места
>перед созданием раздела.
Но если пользователь откажется и не сделает этого, то информация о
свободном месте зашифрованного раздела -- слита.
>Во-вторых, это даст только сведения о записанном объёме: это почти ничего.
Но это всё-равно технически является сливом информации о состоянии дел
вашего диска. Я тоже считаю что это мелочи которые преобладающему
большинству до лампочки и о которых можно не париться.
>Да, в этом был вопрос: насколько незашифрованная метаинформация облегчает:
>- Оффлайновую дешифровку.
>- Возможность оффлайнового изменения файлов (в т.ч. системных).
Ни тому ни другому часть незашифрованной ZFS не поможет ни на йоту.
Замечу, что если вы сделаете обычный GELI/LUKS, который без
аутентификации, и поверх ZFS, то злоумышленник, изменив шифротекст на
диске, на сможет это сделать так, чтобы все контрольные суммы/хэши в
низдежащем ZFS так остались корректными -- поэтому scrub в зашифрованном
диске вам скажет что целостность данных нарушена. Поэтому по поводу
аутентификации GELI/LUKS при использовании ZFS внутри них я бы не
парился. scrub ничего не скажет если злоумышленник поменял
незадействованные данные внутри диска (пустое место).
Родное ZFS шифрование делает не просто какой-нибудь CBC/XTS, а
аутентифицированное шифрование CCM/GCM -- поэтому там аутентификация
данных явно проводится и он явно скажет что именно аутентичность
нарушена, а не просто целостность. Ведь если злоумышленник имеет доступ
к ZFS (но в которой родное шифрование), то он может в принципе изменить
данные и пересчитать все хэши, чтобы, с точки зрения scrub всё выглядело
так, что целостность не нарушена. Но изменить аутентифицированный
шифротекст он, само собой, не сможет. Это ведь кстати ещё один плюс в
сторону родного шифрования: с GELI/LUKS у вас может сыпаться жёсткий
диск и действительно нарушаться целостность, а может быть и
злоумышленник данные подменивает -- с ними вы этого не узнаете. А
включать аутентификацию GELI/LUKS -- дорого, так как для каждого
512/4096 сектора придётся отбирать несколько десятков байт.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Reply to: