Шифрование разделов (Arch, LUKS)

Нет не будет. Шифруется раздел. А /home в / является только точкой монтирования.

Смотри, какую статью для тебя написали: https://wiki.archlinux.org/title/Data-at-rest_encryption Она не идеальна, конечно, но неплохо покрывает типовые кейсы, и после внимательного прочтения ты уже будешь что-то примерно понимать, и таких вопросов не возникнет.

Стандартным способом шифрования нескольких разделов в Линуксе считается использование luks+lvm+ext4.

1. Нужно создать раздел luks;
2. На нем создать lvm;
3. И на lvm уже создать необходимые разделы ext4.

/boot и /boot/efi так же нужно сделать отдельными разделами.

Стандартным способом шифрования нескольких разделов в Линуксе считается использование luks+lvm+ext4

[Citation needed]

ext4 можно XFS заменить. Если LUKS1 использовать, как минимум в Debian GRUB2 умеет сам расшифровывать при вводе ключа, так что отдельный /boot не нужен.

И в Arch, ЕМНИП, использование как LUKS, так и LVM требцет ручной настройки хуков ядра. В отличии от Debian, скажем, где такую разбивку можно прямо из установщика сделать, еще и с RAID1 ниже.

ext4 можно XFS заменить

Сорта :)

Если LUKS1 использовать, как минимум в Debian GRUB2 умеет сам расшифровывать при вводе ключа, так что отдельный /boot не нужен.

UX не очень. Оно медленное, а если опечатаешься, то ещё и проще перезагрузиться, чем вспоминать команды GRUB. В плане безопасности тоже не особо полезно.

И в Arch, ЕМНИП, использование как LUKS, так и LVM требует ручной настройки хуков ядра

Вроде да, но у них тоже есть dracut, который везде работает примерно одинаково.

создать два раздела «/» и «/home»

Зачем?

Зачем?

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

на lvm уже создать необходимые разделы ext4

btrfs для / и xfs для /home, жы

Этим гениям забыли сообщить, что форматировать каждый раз не обязательно.

Этим гениям забыли сообщить, что форматировать каждый раз не обязательно.

Зато обязательно чистить все руками от мусора прошлой системы. Чертовски хороший совет.

Нашел проблему прям. Двигать разделы, приседать с lvm или печально смотреть на пустующие гигабайты в корне конечно лучше.

Ещё лет цать назад мудрые диды придумали создавать отдельно раздел под данные, чтобы при переустановке не пришлось перезаписывать целый раздел.

Уж не те ли самые диды, которые придумали отдельный /usr, потому что у них закончилось место в /, и надо было куда-то примонтировать новый диск?

потому что у них закончилось место в

Закончилось место это уже другой вопрос. Одно дело когда ты решил снести дебиан, а вместе с этим гигатонны фоточк с котиками, и поставить Арч, а совсем другое колличество свободного места на диске. Хотя это и из одной области

• разметки диска, но не одно и то же. Не путай теплое с мягким.

Закончилось место это уже другой вопрос

Но диды вполне конкретные. Вот история, если интересно: https://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Я вообще использую Btrfs с подтомами, а если по какой-то причине мне понадобится переустановить ОС (не знаю, зачем, но вполне может быть), я воспользуюсь debootstrap или аналогом для другого дистрибутива. И не надо ничего форматировать, и даже старую систему можно оставить, она же в отдельном subvolume.

Пункт 2 лишний, хотя часто и навязывается установщиками.

Ещё лет цать назад мудрые диды придумали создавать отдельно раздел под данные, чтобы при переустановке не пришлось перезаписывать целый раздел.

Тогда уж и под /etc отдельный раздел, а то системные конфиги потеряются. Да и чего мелочиться, даешь отельный раздел для каждой иноды!

А можно ли как нибудь зашифровать /boot?

Можно. grub2 поддерживает luks, а в OPAL есть некий preboot image.

Класс, надо будет попробовать

Но зачем?

Чтобы подмену ядра никто не сделал

Можно, но придется скакать в гамаке, grub поддерживает какую-то не ту версию luks, поэтому надо делать руками, установщики вряд ли такое поддерживают из коробки.

Ну подменят тебе ядро вместе с загрузчиком. Легче стало? Use SecureBoot, gentoorulz.

Если они будут на LVM, то будут зашифрованы оба раздела.

Use SecureBoot

Ну сбросят тебе SB, зальют свой загрузчик и PK. Легче стало? Лучше бы TPM посоветовал, в условиях дырявого потребительского железа оно выглядит мало-мальски надёжно.

А ещё можно перестать воображать, что кто-то реально будет заморачиваться с атаками evil maid, когда есть варианты намного проще и незаметнее (нет, не монтировка за $5).

Лучше бы TPM посоветовал

На инцелах он почему-то всегда дискретный, слушай кто хочет. С пинкодом только если

Ну сбросят тебе SB

И как это сделать на условном тыкбуке?

На инцелах он почему-то всегда дискретный, слушай кто хочет

Везде же сейчас fTPM из коробки, не?

С пинкодом только если

Если кто-то слушает шину TPM, то и клавиатуру он будет слушать с вероятностью 100%. В том числе снаружи, потому что по звуку тоже можно восстановить историю ввода.

И как это сделать на условном тыкбуке?

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

Везде же сейчас fTPM из коробки, не?

На AMD - да. В инцел тыкпаде 2024 года всё так же дискретный от STM.

Если кто-то слушает шину TPM, то и клавиатуру он будет слушать с вероятностью 100%. В том числе снаружи, потому что по звуку тоже можно восстановить историю ввода.

Тогда мы в жопе.

с богатой историей сервисных бэкдоров

Со всех сторон обложили.

Это как?

У меня есть /boot раздел зашифрованный моим ключом. В случае удачной расшифровки грузится ядро, которое там записано.

Загрузчик поменять смогут, но как они повлияют на то что у меня записано в крипторазделе?

Объясни алгоритм плз

Я не до конца понимаю как груб работает с крипторазделом. Кто расшифровывает закриптованный /boot раздел?

А ещё можно перестать воображать, что кто-то реально будет заморачиваться с атаками evil maid, когда есть варианты намного проще и незаметнее

Это да, если раздел зашифрован, то вряд ли будут такой ерундой заниматься. Но если /boot лежит расшифрованный, то вероятность подмены возможен. И тут речь скорее даже не про какие-то спецслужбы, а про вирусы. Зайдешь в винду, словишь вирус и он тебе initramfs какой нибудь свой зальёт. Хотя не уверен что такое вообще есть %) С учетом что винда из коробки не видит ФС линуксовые. Хотя хрен знает что у них там в недокументированных функциях имеется. Но скорее я просто фантазёр

но как они повлияют на то что у меня записано в крипторазделе?

А это нужно? Настроить сеть, отправить пароль куда надо, заменить файл загрузчика на оригинальный, продолжить загрузку. Корректно реализованный SB проблему решает, но я с трудом могу поверить, что у тебя он будет действительно secure. А если нужно внести изменения, то с большой вероятностью у тебя там ФС, для которой даже R/W-драйвер писать не надо, есть в GRUB2.

Тебе надо задаваться не вопросом «как мне вот ещё тут зашифровать?», а «какая у меня модель угроз?». Ну и просто как пример: не понадобилось взламывать Tor, чтоб поймать наркоторговцев — их развели классическим фишингом.