Ads
Comments 24
+4
Необходимо отметить, что для всего этого требуется e2fsprogs версии >=1.43, а в текущем LTS Ubuntu(16.04) мы имеем 1.42.13 и при попытке включить криптацию получим
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.
-2
Почему обязательно разводить помойку? Можно найти репозиторий чтоб не тянуть кучу ненужных зависимостей или поставить вовсе не из репозитория.
+12
> поставить вовсе не из репозитория.

Вот это и называется помойка.
-1
Почему же? У вас весь софт из репозиториев? Становится ли моя система помойкой если я поставлю хотя бы одну программу не из репозитория, потому что разработчик не озадачился этим вопросом?
UFO landed and left these words here
0
Я прекрасно осведомлен и понимаю. Но что же делать — отказываться от огромной доли софта, потому что его придется обновлять вручную? Или обрекать свою систему «помойкой», как выразился Erelecano?

В случае с одной библиотекой тоже не вижу проблем, в 18.04 можно будет от этой «закладки» отказаться, если шифрование уже сейчас так необходимо.
UFO landed and left these words here
0
Нет, не только. Это сферический линукс в вакууме — иметь весь софт из репозиториев, если список не ограничивается парой позицией. Даже если учитывать не только десктоп.
0
Это нормальный сервер и десктоп имеют софт только из репозиториев. Даже если этот репозиторий ваш собственный. За установку чего-то из исходников прямо на сервере я лично увольнял сотрудников, как проф.непригодных.
Нужно понимать, что у вас нет опыта работы с серверами, а у меня опыт работы с GNU/Linux 17 лет, так что мое мнение и мой подход весомей, чем ваше вредительство.
0
Не вижу смысла на десктопе делать собственный репозиторий из десятков программ, авторы которых не озаботились поставкой своего софта в репозитории. От этого ничего не изменится. А телеграм давно в репозиториях поставляется? Упс. Судя по вашей карме и комментариям, вредитель здесь явно не я :) /thread
-3
А телеграм не нужен установленный, для отправки сообщений от бота, вот ведь неожиданность!
То что вы не видите смысла в том, что обязан делать любой админ я уже понял, вы — админ локалхоста и мамкин какир, когда вас возьмут хотя бы помощником попингуя в контору «Рога и копыта», тогда вам объяснят, возможно при помощи ног, а возможно при помощи увольнений, что весь софт должен ставиться и обновляться штатными средствами.

А на карму можете дальше дрочить, вот только мои статьи люди читают, а у вас чистый акк и тупые комментарии выдающие глуповатого ребенка.
+1

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

0
Ровно такой же подход должен быть и на десктопе. А помойку разводить можно в lxc-тазах, если хочется помойки. А десктоп должен работать, тут вам не виндовс.
+3

Никто не мешает поставить tune2fs и другие утилиты в отдельную директорию. Тогда система продолжит использовать версию из репозитория, но при этом можно будет экспериментировать с последними фичами ФС.
По поводу помойки — да, в идеале все пакеты должны быть из репозитория, но жизнь диктует свои правила. Стандартный репозиторий хорош только для самых типовых задач, как только в требования попадает что-то хоть немного необычное — на сервере сразу появляется директория с самосбором. Те, кто поаккуратнее, собирают в пакеты, остальные просто делают набор директорий для каждой утилиты/библиотеки и кидают симлинки, если это нужно. Это то, что лично я видел в продакшене. Особенно это актуально для RHEL/SLES. Погуглите, убедитесь сами — большинство инструкций для этих дистрибутивов предлагают самому собирать нужные утилиты. К счастью, с появлением Docker стало немного попроще, но, сами понимаете, e2fsprogs в нем не запустишь.

0
> Никто не мешает поставить tune2fs и другие утилиты в отдельную директорию. Тогда система продолжит использовать версию из репозитория, но при этом можно будет экспериментировать с последними фичами ФС.

Ага, а потом штатный fsck из репозитория проверит вашу fs. И что накроется медным тазом, а что чугунной ванной в процессе науке неизвестно.

> на сервере сразу появляется директория с самосбором.

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

А в случае с e2fsprogs беда в том, что пакет — критичный для системы и если его совать в свой репозиторий, то вам нужно будет автоматизировать его обновление, да еще самому следить за стабильность. Можно собирать какую-нибудь луашку с луаджитом в своей репе и обновлять когда есть критичные причины, можно nginx так или еще какой апач, но e2fsprogs слишком критичен, что бы тащить его из левых мест, собирать из исходников на месте или держать в своей репе. А потому данная фича сможет придти на мой ноутбук или сервера под моим контролем не раньше, чем она войдет в официальные репы.
0
Проблема в том, что в официальные репы тоже время от времени проскакивает разного рода чача. Есть конечно надежда, что ментейнеры умнее вас, но чтобы все было реально оттестированным, кто-то должен гонять testing-ветки, затягивать туда исходники из апстрима и т.д. И не только на синтетических тестах, но и на более-менее приближенных к боевым системах. И делать это будет некому, если все будут ставить всюду только stable. Так что гибче надо, imho. На свой комп, который по сути — консоль для SSH-а, или в тестовую виртуалку одноразовую — можно и из исходников накатить на посмотреть. Если фича из апстрима реально так нужна, что без неё никуда — то и ресурсы на поддержку системного пакета в своем репозитории найдутся. А как оттестируется как следует — можно выделить время и на предмет общения с мейнтейнерами backports-репозиториев пообщаться. Тогда и помойки не будет, и сообществу — польза.
0
Так что версия ядра нам никак не поможет, если мы не станем разводить у себя помойку и тащить столь важный пакет не из родных репозиториев.

Не знаю, где находятся ваши родные репозитории, но для меня нет большой разницы между apt install и git clone https://github.com/tytso/e2fsprogs
+3

Зря не озвучили, зачем оно вообще всё надо. Грузиться с него нельзя, отдельные папки шифровать и без него способов много.

0
1. Зачем нужно шифрование на уровне файловой системы? Ну, как минимум, для улучшения производительности без использования сторонних продуктов. Это чисто мое мнение, а лучше спросить у Гугла, как у заказчика.
2. Зачем с него грузиться, я, честно, вообще не задумывался. Подозреваю, что моя паранойя еще не прогрессирует
3. Шифровать отдельные папки способы есть, несомненно. Но, может, пришло уже время выкинуть этот бубен, когда есть способ сделать это из коробки.
0

Не-не-не. Шифрование на уровне около файловой системы в Линуксе было испокон веков, от юзерспейсной ecryptfs до монументального LUKS. И да, с последнего можно грузиться. На ноуте можно оставить незащищённым только GRUB, который, однако, защищён цифровой подписью secureboot. В результате, если злоумышленник незаметно получит физический доступ к машине, он не сможет не только ничего открыть, но и оставить программную закладку тоже. А физическую закладку, имхо, труднее сделать и легче найти.
Из коробки — тоже сильно сказано. Нужна файловая система, которой уже может и не быть, и к ней набор утилит, которых ещё может не быть. К концу 2018, когда эти улиты осядут в медленных дистрибутивах, уже, наверное, и сервера будут делать на Btrfs.
Так что речь идёт о довольно-таки специфическом решении, и вопрос "А зачем оно надо, когда есть ecryptfs и LUKS?" стоит по-прежнему. Вкупе с описанными ниже сложностями с бекапом всё равно для серьёзного дела будут создавать отдельный раздел для зашифрованного. Чтобы бекапить без проблем.
К тому же мне очень сильно не нравится решение "без ключа — видны папки с кракозябрами". Зачем они нужны? Чтобы find в них застревал? Чтобы объём зашифрованного добра утёк? Не знаю.

0
1. Для бекапа проблем нет. Могу долго и нудно про это рассказывать (вкратце уже изложил ниже), но это совершенно другая тема.
2. ecryptfs — насколько я понял, шифрование в ext4 как раз реализовано на ее основе.
3. LUKS, насколько помню, шифрует сразу всё и сразу, т.е. это не совсем то.
4. Если злоумышленник вроде меня снимет dd со всего раздела, то я навскидку не могу придумать, как расшифровать содержимое директории, владея всеми этими заумными аббревиатурами. Ключи всё-таки ого-го.
5. Видны папки с кракозябрами? Это еще пол-дела. Эти кракозябры совершенно не соответствуют тому, что непосредственно прописано в direntry, т.е. для вывода пользователю оно еще раз шифруется по типу base64, дабы исключить невалидные символы в именах. А для find вообще не должно быть вопросов: ну получит он restrict, ему же лучше
UFO landed and left these words here
0
Хороший вопрос. Резервное копирование — это вообще отдельная тема.
В данном примере содержимое зашифрованного файла получается при непосредственном чтении кластеров, которые принадлежат этому айноду — сначала необходимо найти айнод в таблице и затем пройти по его дереву экстентов, читая занятые кластера. Обратите внимание на рис. 4, где показан айнод зашированного файла и выделен его один единственный кластер. Здесь рассмотрен очень простой случай. Но в целом — задача, мягко говоря, не самая тривиальная.

Что же касается резервного копирования, то выполнение этой операции через readdir() с последующим read/write здесь не годится, если я правильно понял вопрос. Придется либо подружиться с деревом экстентов, либо вычитывать битмап блоков для каждой группы дескрипторов и копировать занятые кластера.
Only those users with full accounts are able to leave comments.  , please.