id: Гость   вход   регистрация
текущее время 21:33 11/10/2024
Владелец: SATtva (создано 23/06/2015 19:02), редакция от 23/06/2015 19:02 (автор: SATtva) Печать
Категории: криптография, софт, инфобезопасность, защита дисков, симметричное шифрование, свободный софт, разграничение доступа
https://www.pgpru.com/Новости/2015/ВLinux41РеализованаПоддержкаФайловогоШифрованияВExt4
создать
просмотр
редакции
ссылки

23.06 // В Linux 4.1 реализована поддержка файлового шифрования в Ext4


После двух месяцев разработки Линус Торвальдс анонсировал релиз ядра Linux 4.1. Среди наиболее заметных улучшений: поддержка шифрования в ФС Ext4, новая виртуальная файловая система tracefs, экспериментальная реализация распределённого RAID 1, поддержка MPLS, однопользовательский режим для встраиваемых систем, блочное устройство PMEM для энергонезависимой памяти, интеграция наработок Intel по виртуализации GPU.


Файловая система Ext4 получила поддержку шифрования отдельных частей ФС, например, отдельных директорий. Шифруется только содержимое и имена файлов, а метаданные о файлах, такие как размер и права доступа, остаются видимыми. Ключ шифрования определяется во время монтирования ФС. Настройки шифрования выполняются посредством xattr. Новые файлы или директории могут быть зашифрованы отдельно или автоматически, в случае если они создаются в уже зашифрованной директории.


Зашифрованные данные размещаются с использованием метода AES-256-XTS, для имён файлов применяется AES-256-CBC. Для каждого inode генерируется свой уникальный 512-битовый ключ шифрования, что позволяет блокировать атаки в ситуациях, когда злоумышленнику известна часть зашифрованного содержимого. По сравнению с применением надстроек, таких как dm-crypt и eCryptFS, интеграция поддержки шифрования непосредственно в драйвер ФС, позволяет добиться более высокой производительности, использовать текущий код для обработки прав доступа и обеспечить возможность работы с незашифрованной частью файлов на устаревших системах.


Источник: http://www.opennet.ru/opennews/art.shtml?num=42472


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

Интересно, как у неё с безопасностью на фоне таких предшественников, как eCryptFS и EncFS. У тех систем пофайлового шифрования были солидные разработчики (IBM), но это не помогло безопасности.

Ещё интересно, где действительно нужно пофайловое шифрование так, что без больших проблем его не заменить LUKS'ом (вопросы удобства для домохозяек пока можно оставить в стороне). Может быть, оно где-то даст большую производительность, и это критично? Вряд ли.
— SATtva (23/06/2015 20:20)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
У меня ровно те же вопросы. Хочется компетентного анализа безопасности и собственного понимания, нафига оно вообще.
— pgprubot (23/06/2015 20:22, исправлен 23/06/2015 20:31)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Я поначалу хотел сразу написать «пофайловое шифрование не нужно», но решил что это будет толсто выразить мысль тоньше, а то вдруг чего-то не знаю. ☺



Я вижу только то, что на поверхности: вопросы удобства для домохозяек. Это возможность включить шифрование на лету, отсутствие необходимости после установки и настройки ОС переразбивать диск/LVM, чтобы выделить раздел/том под шифрование, и т.п. аргументы. Впрочем, LUKS тоже активно движется в сторону возможности включения шифрования на лету: есть команда cryptsetup-reencrypt, из мануала:


Cryptsetup-reencrypt reencrypts data on LUKS device in-place. During reencryption process the LUKS device is marked unavailable.
— просто_Гость (24/06/2015 00:00, исправлен 24/06/2015 00:02)   профиль/связь   <#>
комментариев: 92   документов: 0   редакций: 0

Так и пусть будет. Винда содержит BitLocker, но это ж не мешает использовать то что нравится. Так и здесь – пусть будет. Многие ли шифруют диски/разделы при установки Debian? Еще меньше создают LVM, хотя все это есть из коробки.
Лишь бы такого не было

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

Почти никто. По-моему, штатные инсталляционные диски поддерживают только шифрование домашней директории пользователя его пассфразой (ecryptfs или encfs — не помню уже, что там используется). Для получения всех возможностей по настройке нужно использовать netinstall-диски, о чём, во-первых, мало кто знает, а, во-вторых, без надлежащего опыта с инсталляцией через них можно не справиться.


Когда-то было обсуждение на тему того, хорошо или плохо это — включать дисковое шифрование для всех по умолчанию [1], но я склоняюсь к тому, что это, скорее, хорошо [тем более, что Google и Apple сейчас тоже по этому пути пошли (см. вашу же ссылку)].

— просто_Гость (24/06/2015 15:56)   профиль/связь   <#>
комментариев: 92   документов: 0   редакций: 0

Поддерживается полнодисковое шифрование без проблем, в т.ч. с последующим размещением на них LVM-group.
При шифровании используется пассфраза или файл.
ecryptfs или encfs штатно не используется, для этого нужно доустановить fuse в уже установленную систему (в инсталяторе не предлагается).


Лично мое мнение, что если инструмент предлгается в виде разработки каких то вендоров или гугла, то я бы выбрал установку стороннего программного обеспечения для шифрования.
— pgprubot (24/06/2015 16:29)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

В Debian или в Ubuntu? Написано, что пять лет назад было так. Недавно смотрел Ubuntu (не самую свежую, но не такую старую) — там предлагалось шифровать домашнюю директорию, но там была уже установленная и настроенная система, а не процесс инсталляции. Про штатные диски Debian вообще не помню, смотрел их когда-то или нет.


Какой ещё файл? С мастер-ключом? Этот? Или файл с заголовком LUKS?


В Debian или Ubuntu?


Если RedHat вкладывается в ядро Linux и, допустим, в LUKS, стоит ли выбирать альтернативу LUKS?
— просто_Гость (25/06/2015 12:59, исправлен 25/06/2015 13:03)   профиль/связь   <#>
комментариев: 92   документов: 0   редакций: 0

Речь идет об инсталяторе Debian.
Кодовое имя: Squeeze Дата выпуска: 26 июня 2010 – уже содержал возможность шифрования диска/раздела при инсталяции.



filehttp://uni-smr.ac.ru/archive/l.....-squeeze-install.pdf
стр 75-76



Речь конечно шла не о таких вариантах. Примером была ситуация с BitLocker и ей подобным.

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

Из man cryptsetup:


Opens the loop-AES <device> and sets up a mapping <name>.
If the key file is encrypted with GnuPG, then you have to use --key-file=- and decrypt it before use, e.g. like this:
gpg --decrypt <keyfile> | cryptsetup loopaesOpen --key-file=- <device> <name>

Понятно. Это специфика loop-AES. Он появился, по-моему, ещё до LUKS и сейчас не особо рекомендуем (устарел).

— Aminгч (22/10/2015 01:27)   профиль/связь   <#>
комментариев: 10   документов: 0   редакций: 0
Помимо безопасности, важен ещё и вопрос обратной совместимости.
Я так понимаю, монтироваться такой раздел будет на старых ядрах.
Если на такой старой системе копирнуть файл на другой том,
то насколько велик риск его испортить? Скажем, в случае утраты атрибутов фс ?
Или он не прочитается ?

Просто если атрибуты ФС становятся критически важными для доступности файла -
то могу возникнуть проблемы при переносе таких файлов, их резервировании
и прочих менее очевидных ситуациях.
— pgprubot (25/10/2015 23:08, исправлен 25/10/2015 23:10)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Логично предположить, что в старых ядрах, где поддержки этого расширения не было, ничего правильно работать не будет. Впрочем, надо смотреть, когда именно эти расширенные возможности появились. Может быть, на уровне базовых интерфейсов это было уже сразу заложено в ext4. Возможно, на старых системах шифрованные файлы будут смотреться как мусор (например, если не ввести пароль, именно так смотрятся файлы в encFS/ecryptFS).


Как уже было выше сказано, непонятно, зачем оно нужно, особенно с учётом этого:


метаданные о файлах, такие как размер и права доступа, остаются видимыми.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3