Comments 24
tune2fs -O encrypt /dev/vda1
tune2fs 1.42.13 (17-May-2015)
Invalid filesystem option set: encrypt
Так что версия ядра нам никак не поможет, если мы не станем разводить у себя помойку и тащить столь важный пакет не из родных репозиториев.
Таким образом в серьезных серверных дистрибутивах, а не в тестовых версиях(каковыми являются у Ubuntu non-LTS), мы получим эту возможность только с выходом Debian 9(где e2fsprogs 1.43.4), а для Ubuntu только в 18.04 LTS.
Вот это и называется помойка.
В случае с одной библиотекой тоже не вижу проблем, в 18.04 можно будет от этой «закладки» отказаться, если шифрование уже сейчас так необходимо.
Нужно понимать, что у вас нет опыта работы с серверами, а у меня опыт работы с GNU/Linux 17 лет, так что мое мнение и мой подход весомей, чем ваше вредительство.
То что вы не видите смысла в том, что обязан делать любой админ я уже понял, вы — админ локалхоста и мамкин какир, когда вас возьмут хотя бы помощником попингуя в контору «Рога и копыта», тогда вам объяснят, возможно при помощи ног, а возможно при помощи увольнений, что весь софт должен ставиться и обновляться штатными средствами.
А на карму можете дальше дрочить, вот только мои статьи люди читают, а у вас чистый акк и тупые комментарии выдающие глуповатого ребенка.
Вам стоит добавлять "для критичного сервера на продакшене" для каждого вашего комментария. Подход правильный, но на куче платформ излишне строгий.
Никто не мешает поставить tune2fs и другие утилиты в отдельную директорию. Тогда система продолжит использовать версию из репозитория, но при этом можно будет экспериментировать с последними фичами ФС.
По поводу помойки — да, в идеале все пакеты должны быть из репозитория, но жизнь диктует свои правила. Стандартный репозиторий хорош только для самых типовых задач, как только в требования попадает что-то хоть немного необычное — на сервере сразу появляется директория с самосбором. Те, кто поаккуратнее, собирают в пакеты, остальные просто делают набор директорий для каждой утилиты/библиотеки и кидают симлинки, если это нужно. Это то, что лично я видел в продакшене. Особенно это актуально для RHEL/SLES. Погуглите, убедитесь сами — большинство инструкций для этих дистрибутивов предлагают самому собирать нужные утилиты. К счастью, с появлением Docker стало немного попроще, но, сами понимаете, e2fsprogs в нем не запустишь.
Ага, а потом штатный fsck из репозитория проверит вашу fs. И что накроется медным тазом, а что чугунной ванной в процессе науке неизвестно.
> на сервере сразу появляется директория с самосбором.
Как я уже писал выше я за такое людей просто увольнял, как несоответствующих занимаемой должности. Весь софт всегда должен ставиться и обновляться штатными методами. Если что-то критичное нужно версий отличных от того, что есть в репозиториях, то нужно поднимать свой и собирать. Если что-то отсутствует в репозиториях, то нужно собирать пакет и ставить его штатным образом.
А в случае с e2fsprogs беда в том, что пакет — критичный для системы и если его совать в свой репозиторий, то вам нужно будет автоматизировать его обновление, да еще самому следить за стабильность. Можно собирать какую-нибудь луашку с луаджитом в своей репе и обновлять когда есть критичные причины, можно nginx так или еще какой апач, но e2fsprogs слишком критичен, что бы тащить его из левых мест, собирать из исходников на месте или держать в своей репе. А потому данная фича сможет придти на мой ноутбук или сервера под моим контролем не раньше, чем она войдет в официальные репы.
Так что версия ядра нам никак не поможет, если мы не станем разводить у себя помойку и тащить столь важный пакет не из родных репозиториев.
Не знаю, где находятся ваши родные репозитории, но для меня нет большой разницы между apt install и git clone https://github.com/tytso/e2fsprogs
Зря не озвучили, зачем оно вообще всё надо. Грузиться с него нельзя, отдельные папки шифровать и без него способов много.
CryptoAPI ядра Linux: разработка и применение российской криптографии?
2. Зачем с него грузиться, я, честно, вообще не задумывался. Подозреваю, что моя паранойя еще не прогрессирует
3. Шифровать отдельные папки способы есть, несомненно. Но, может, пришло уже время выкинуть этот бубен, когда есть способ сделать это из коробки.
Не-не-не. Шифрование на уровне около файловой системы в Линуксе было испокон веков, от юзерспейсной ecryptfs до монументального LUKS. И да, с последнего можно грузиться. На ноуте можно оставить незащищённым только GRUB, который, однако, защищён цифровой подписью secureboot. В результате, если злоумышленник незаметно получит физический доступ к машине, он не сможет не только ничего открыть, но и оставить программную закладку тоже. А физическую закладку, имхо, труднее сделать и легче найти.
Из коробки — тоже сильно сказано. Нужна файловая система, которой уже может и не быть, и к ней набор утилит, которых ещё может не быть. К концу 2018, когда эти улиты осядут в медленных дистрибутивах, уже, наверное, и сервера будут делать на Btrfs.
Так что речь идёт о довольно-таки специфическом решении, и вопрос "А зачем оно надо, когда есть ecryptfs и LUKS?" стоит по-прежнему. Вкупе с описанными ниже сложностями с бекапом всё равно для серьёзного дела будут создавать отдельный раздел для зашифрованного. Чтобы бекапить без проблем.
К тому же мне очень сильно не нравится решение "без ключа — видны папки с кракозябрами". Зачем они нужны? Чтобы find в них застревал? Чтобы объём зашифрованного добра утёк? Не знаю.
2. ecryptfs — насколько я понял, шифрование в ext4 как раз реализовано на ее основе.
3. LUKS, насколько помню, шифрует сразу всё и сразу, т.е. это не совсем то.
4. Если злоумышленник вроде меня снимет dd со всего раздела, то я навскидку не могу придумать, как расшифровать содержимое директории, владея всеми этими заумными аббревиатурами. Ключи всё-таки ого-го.
5. Видны папки с кракозябрами? Это еще пол-дела. Эти кракозябры совершенно не соответствуют тому, что непосредственно прописано в direntry, т.е. для вывода пользователю оно еще раз шифруется по типу base64, дабы исключить невалидные символы в именах. А для find вообще не должно быть вопросов: ну получит он restrict, ему же лучше
В данном примере содержимое зашифрованного файла получается при непосредственном чтении кластеров, которые принадлежат этому айноду — сначала необходимо найти айнод в таблице и затем пройти по его дереву экстентов, читая занятые кластера. Обратите внимание на рис. 4, где показан айнод зашированного файла и выделен его один единственный кластер. Здесь рассмотрен очень простой случай. Но в целом — задача, мягко говоря, не самая тривиальная.
Что же касается резервного копирования, то выполнение этой операции через readdir() с последующим read/write здесь не годится, если я правильно понял вопрос. Придется либо подружиться с деревом экстентов, либо вычитывать битмап блоков для каждой группы дескрипторов и копировать занятые кластера.
Шифрование в EXT4. How It Works?