у меня так proxmox работает — весь storage зашифрован.
Но вчера в голову пришла мысль, что избежать терморектального метода расшифровки поможет только электронное тело)
Лан, не вопрос, просто как-то слог сложноват для понимания.
А если у меня кейс без шифрования? А если я указал в конфиге граба GRUB_ENABLE_CRYPTODISK=n как он об этом узнает без расшифровки контейнера?
А вот тут вот самое забавное.
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
Как-то так. Попробуйте, оно так и есть
Т.е. как я понимаю, этот файл *.efi уже немного другой.
В efi вон люди даже тетрис запускают :)
что такое ССЗБ? В каком конфиге LUKS? Что значит «запрещать»?
Тогда он будет игнорировать мой конфиг что-ли или не будет ничего выполнять
Он это кто? LUKS? GRUB? Ваши вопросы меня… немного смущают. Странные они. Я лучше вместо полемики бесполезной просто расскажу, как оно, на мой взгляд, работает(как я понял)
1. UEFI запускает grubx64.efi
2. Это запущеное приложение ищет по HEAD устройство LUKS, спрашивает у вас пароль ( Grub 2.02~beta2-29 supports reading an encrypted /boot partition. option GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub )
3. Контейнер открывается для самого grub после успешного ввода пароля. Становится доступной содержимое /boot/* (у меня оно там же, где и /)
4. С открытого контейнера с опциями, параметрами загружается ядро, initramfs.
5. На этапе загрузки initramfs, а именно предварительно настроенного хука encrypt второй раз спрашивается пароль уже для системы. Контейнер заново открывается уже для самой системы и вы работаете в ней.
ну, если быть точным, бинарник будет искать все устройства, которые имеют определённый HEADER (TYPE=«crypto_LUKS») и далее спрашивать пароль на открытие этого контейнера.
Вот у меня по статье зашифровано всё и открыт только один файл efi и всё(ну, естественно раздел тоже)
А если в конфиге параметр отвечающий за шифрование запрещает расшифровку?
а чёт как-то бессмысленно звучит. Зашифровывать раздел а потом указывать, что надо запрещать расшифровку, так-то оно да, целее будет, согласен.
Способ 1. Отключить верификацию модулей ядра
Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.
Собственно, вижу способ, не вижу препятствий. Т.е. достаточно будет только подписать сам загрузчик, а модули ядра особо и незачем будет подписывать, потому как они лежат в криптоконтейнере и всё будет работать. Не?
Если я хочу сохранить полный контроль за загрузкой и использую единственную точку входа в виде граба, который даже подписанный может быть скомпрометирован, потому что конфиг то лежит рядом незашифрованый.
Конфиг какой? /boot/grub/grub.cfg лежит уже внутри криптоконтейнера.
Ну не засунуть в мой криптоконтейнер закладку, значит засунут в граб скрапер и я не замечу.
Ну тут я только один метод могу представить — кто-то нашёл уязвимость в самом luks, secure boot и т.д., что достаточно сложно и надо таком человеку руку пожать просто
я вот видел пару раз шифрование подкачки. Расскажите мне зачем и почему? т.е. я видел, что бывает так, что система не зашифрована, а swap — зашифрован.
Насколько я помню swap очищается при корректном выключении/перезагрузке системы. Стало быть только стоп виртуалки или выключение по питанию может сохранить данные в swap (т.е. по сути продолжение обычной памяти). Но, так как свопится зачастую всякое, скажем не такое уж и важное, то какова суть шифровать swap без шифрования рута?
PS, ещё помню, что XSPider на вёнды 2000,2003 показывал уязвимость «Неочищаемый раздел подкачки» и советовал в реестре это исправить. Кто знает как это вообще можно использовать для компроментирования удалённой системы?
красивейший трюк меня просили сделать на прошлой работе. Суть — найти секурный VPS, где потом настроить luks таким же образом, что и описано в системе, но зашить в initramfs мини-образ системы с сетью и ssh-демоном, что использовать ssh для того, чтобы после перезагрузки системы открыть контейнер и загрузить саму систему.
ниииииит! grubx64.efi это бинарный файл, efi-приложение, которое тупо запускается, а дальше уже работает… как приложение собсно.
А вот, к примеру, efibootmgr, он чуть более крут, он ( мой любимый приём — поправьте, если не так ) efi-приложением не является, а напрямую взаимодействует с efi, позволяя поменять порядок загрузки, создать порядок и беспорядок)
PS: для повышения уровня шизофрении здесь не хватает только secure boot, чтобы подписать наш загрузчик grubx64.efi.
Просто положить ядро и initramfs на /dev/vda1 я счёл безыинтересным, так как 100 раз так уже делал. Другие загрузчики типа SHIM, bootctl и прочее не умеют вытворять подобного(ну и ли я не в курсе — расскажите в комментах )
к тому же, если не использовать grub, а, к примеру, просто положить ядро придётся положить на открытое место и initramfs(поправьте меня, если я ошибаюсь). И как в этом варианте использовать secure boot? Ну или какой от неё будет толк, если фс открыта и будет можно подменить и ядро и initramfs?
Я примерно понял, как использовать secureboot, по сути эти подписание загрузчика (efi-исполняемого файла) в pki UIFI. Может коряво, но вроде поянил норм.
В моём варианте есть файл grubx64.efi, который мы «подпишем» и вряд ли он изменится(ну или не так часто), а вот если обновится ядро, то как-то заново надо будет secureboot настраивать или?
— До конца не разобрался как secureboot работает, возможно позже добавлю его в статью, когда настрою на ноуте. Но как мне видится, есть только один файл, который является загрузчиком и только его можно подменить, но его же можно и верифицировать через secureboot чтобы избежать подмены.
не критикую статью, вас. Всё вполне здраво. В фактах не сомневаюсь.
Просто говорю, что в регионах(на момент года 2013-14) было именно так, что эти стойки тупо стояли без дела. Линк какой-то держали, но не использовались по факту.
Насколько я помню, (сталкивался с этим в ЛПУ), все эти ЗТКИ стоят, типа работают, никто за ними не смотрят и самое главное… никакой траффик через них не ходит.
Стоят они для видимости, деньги «уплочены» и всё отлично.
вручную вообще не рекомендуется, но если вы имеете ввиду почти вручную — packstack, да, это простенько, понятненько и круто. Знаем-плавали.
Просто сама эта концепция TripleO, Director невероятно умная, красивая(мне даже нравится). Но вот приехал я такой на экзамен RH, начал ставить 8 версию, а она такая хоп и не ставится. Тупо в процессе overcloud deploy на втором часу деплоя — ошибка. И все гайды по troubleshooting просто бесполезны. Вернуть состояние можно, вроде всё ок, но вот реально, почему билд происходит с непонятными сообщениями puppet? К чему вот такая автоматизация установки, которая тебе говорит всё время «Unknown Error» даже в процессе удачного деплоя?
Ansible вроде уже есть, но были костыляки вроде того, что Ansible вызывал Puppet и делал часть работы — это как вообще так и зачем?
Openstack прекрасен в своём странном поведении, особенно на этапе установки(скажу на RH Openstack 8 ).
Overcloud deploy выглядит как pyppet Unknown Error практически всегда и это нормально. Отлаживать проблемы устнановки просто нереально, как вообще этим можно нормально рулить, если всё настолько никак в Openstack?
corp.mail.ru/ru/press/releases/9593
и вполне себе нормальные инструкции уже 100 раз тут были.
Единственное, что стоит добавить — публичный ключ 2048 DKIM не всегда влезает в поле, если вы хостите DNS у недопровайдеров.
хз, но я думаю большинство предпренимателей не рискуют подать на них иск, потому как у них резко могут что-то найти или что-то отрубить. Судя по тому как пролоббировали тему блокировок будут тупо отказы на такие иски на основе прецедентов.
:)
Я может наивный, но вот просто мне близка такая идеология — если что-то уже написано(какой-то код) нормально, то незачем опять придумывать как сделать тоже самое, но по-своему.
Могли бы уже вместо траты сил своих разработчиков(а я думаю нехилые траты), просто объединиться с готовым проектом(notepad++, sublime), инвестировать, разрабатывать свою версию и заменить стандартный блокнот. Да, будут компоненты opensource, а может и не будет(сделать платную версию, а бесплатную как тестинг для платного как Fedora-Centos для RedHat)
нахер вообще этот магазин, который нормально не отключается? Почему он не работае через тот же WSUS, к примеру? Почему всё так через жопу? Они хотят прийти к концепции репозиториев Linux(публично доступных, зеркалируемых, с подписанными для верификации пакетами), но делают это так стрёмно и убого, что даже страшно иногда.
Но вчера в голову пришла мысль, что избежать терморектального метода расшифровки поможет только электронное тело)
А вот тут вот самое забавное.
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
Как-то так. Попробуйте, оно так и есть
Т.е. как я понимаю, этот файл *.efi уже немного другой.
В efi вон люди даже тетрис запускают :)
Он это кто? LUKS? GRUB? Ваши вопросы меня… немного смущают. Странные они. Я лучше вместо полемики бесполезной просто расскажу, как оно, на мой взгляд, работает(как я понял)
1. UEFI запускает grubx64.efi
2. Это запущеное приложение ищет по HEAD устройство LUKS, спрашивает у вас пароль ( Grub 2.02~beta2-29 supports reading an encrypted /boot partition. option GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub )
3. Контейнер открывается для самого grub после успешного ввода пароля. Становится доступной содержимое /boot/* (у меня оно там же, где и /)
4. С открытого контейнера с опциями, параметрами загружается ядро, initramfs.
5. На этапе загрузки initramfs, а именно предварительно настроенного хука encrypt второй раз спрашивается пароль уже для системы. Контейнер заново открывается уже для самой системы и вы работаете в ней.
PS. такое ощущение, что тупо троллите.
Вот у меня по статье зашифровано всё и открыт только один файл efi и всё(ну, естественно раздел тоже)
а чёт как-то бессмысленно звучит. Зашифровывать раздел а потом указывать, что надо запрещать расшифровку, так-то оно да, целее будет, согласен.
Собственно, вижу способ, не вижу препятствий. Т.е. достаточно будет только подписать сам загрузчик, а модули ядра особо и незачем будет подписывать, потому как они лежат в криптоконтейнере и всё будет работать. Не?
Конфиг какой? /boot/grub/grub.cfg лежит уже внутри криптоконтейнера.
Ну тут я только один метод могу представить — кто-то нашёл уязвимость в самом luks, secure boot и т.д., что достаточно сложно и надо таком человеку руку пожать просто
Насколько я помню swap очищается при корректном выключении/перезагрузке системы. Стало быть только стоп виртуалки или выключение по питанию может сохранить данные в swap (т.е. по сути продолжение обычной памяти). Но, так как свопится зачастую всякое, скажем не такое уж и важное, то какова суть шифровать swap без шифрования рута?
PS, ещё помню, что XSPider на вёнды 2000,2003 показывал уязвимость «Неочищаемый раздел подкачки» и советовал в реестре это исправить. Кто знает как это вообще можно использовать для компроментирования удалённой системы?
Не хватило времени и желания… пришлось уволиться)
А вот, к примеру, efibootmgr, он чуть более крут, он ( мой любимый приём — поправьте, если не так ) efi-приложением не является, а напрямую взаимодействует с efi, позволяя поменять порядок загрузки, создать порядок и беспорядок)
у меня как раз /boot зашифрован. Разве нет? — доступен только /dev/sda1 fat32, на котором grub-файл и всё, дальше только по парольной фразе
к тому же, если не использовать grub, а, к примеру, просто положить ядро придётся положить на открытое место и initramfs(поправьте меня, если я ошибаюсь). И как в этом варианте использовать secure boot? Ну или какой от неё будет толк, если фс открыта и будет можно подменить и ядро и initramfs?
Я примерно понял, как использовать secureboot, по сути эти подписание загрузчика (efi-исполняемого файла) в pki UIFI. Может коряво, но вроде поянил норм.
В моём варианте есть файл grubx64.efi, который мы «подпишем» и вряд ли он изменится(ну или не так часто), а вот если обновится ядро, то как-то заново надо будет secureboot настраивать или?
— До конца не разобрался как secureboot работает, возможно позже добавлю его в статью, когда настрою на ноуте. Но как мне видится, есть только один файл, который является загрузчиком и только его можно подменить, но его же можно и верифицировать через secureboot чтобы избежать подмены.
Поправьте меня, если что не так
Просто говорю, что в регионах(на момент года 2013-14) было именно так, что эти стойки тупо стояли без дела. Линк какой-то держали, но не использовались по факту.
Стоят они для видимости, деньги «уплочены» и всё отлично.
Просто сама эта концепция TripleO, Director невероятно умная, красивая(мне даже нравится). Но вот приехал я такой на экзамен RH, начал ставить 8 версию, а она такая хоп и не ставится. Тупо в процессе overcloud deploy на втором часу деплоя — ошибка. И все гайды по troubleshooting просто бесполезны. Вернуть состояние можно, вроде всё ок, но вот реально, почему билд происходит с непонятными сообщениями puppet? К чему вот такая автоматизация установки, которая тебе говорит всё время «Unknown Error» даже в процессе удачного деплоя?
Ansible вроде уже есть, но были костыляки вроде того, что Ansible вызывал Puppet и делал часть работы — это как вообще так и зачем?
Overcloud deploy выглядит как pyppet Unknown Error практически всегда и это нормально. Отлаживать проблемы устнановки просто нереально, как вообще этим можно нормально рулить, если всё настолько никак в Openstack?
corp.mail.ru/ru/press/releases/9593
и вполне себе нормальные инструкции уже 100 раз тут были.
Единственное, что стоит добавить — публичный ключ 2048 DKIM не всегда влезает в поле, если вы хостите DNS у недопровайдеров.
Я может наивный, но вот просто мне близка такая идеология — если что-то уже написано(какой-то код) нормально, то незачем опять придумывать как сделать тоже самое, но по-своему.
Могли бы уже вместо траты сил своих разработчиков(а я думаю нехилые траты), просто объединиться с готовым проектом(notepad++, sublime), инвестировать, разрабатывать свою версию и заменить стандартный блокнот. Да, будут компоненты opensource, а может и не будет(сделать платную версию, а бесплатную как тестинг для платного как Fedora-Centos для RedHat)