LINUX.ORG.RU

Мечта параноика

 


3

4

Proof-of-concept: зашифрованный /boot! То, чего так не хватало тем людям, которые хотели полностью зашифрованную систему на одном разделе или опасались, что их нешифрованный /boot изменят, засунут в initrd трояна и таким образом получат доступ ко всем остальным данным.

Рецепт:

  • Свежий GRUB, не старше 2011-07-07 (grub-2.00 с официального сайта вполне подошёл)
  • Сборка руками, ничего интересного, но много build-dependencies.
  • grub-install оказался недостаточно умным, чтобы сработать автоматически.
    • Во-первых, эксперимент проводился на /dev/loop0, что у GRUB не было никаких шансов заметить, пришлось править .../boot/grub/device.map:
      dd if=/dev/zero of=luks.img bs=1M count=100
      losetup /dev/loop0 luks.img
      fdisk /dev/loop0
      cruptsetup luksFormat /dev/loop0p1
      cryptsetup luksOpen /dev/loop0p1 test
      mke2fs /dev/mapper/test
      mount /dev/mapper/test /mnt
      mkdir -p /mnt/boot/grub
      echo '(hd0) /dev/loop0' > /mnt/boot/grub/device.map
    • Во-вторых, по умолчанию GRUB даже не пытается открывать зашифрованные устройства:
      # share/grub/grub-mkconfig_lib
        if abstractions="`"${grub_probe}" -t abstraction "$path"`" 2>&1 ; then 
            :
        else
          return 1
        fi
      
        if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
            return 0
        fi
        
        for abstraction in $abstractions; do
            if [ "x$abstraction" = xcryptodisk ]; then
                return 1
            fi
        done
      Чтобы он сделал такую попытку, необходимо установить переменную окружения GRUB_CRYPTODISK_ENABLE в «y».
    • В-третьих, разработчики не зря спрятали это за переменную окружения, поскольку получившийся core.img не смог прочитать таблицу разделов и увидеть зашифрованный раздел. Решилось это ручным добавлением модуля к grub-install.
    В итоге команда установки выглядела так:
    sudo env GRUB_CRYPTODISK_ENABLE=y ~/grub2/sbin/grub-install --modules=part_msdos --root-directory=/mnt/ /dev/loop0

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

А на самом скриншоте смотреть почти нечего, да.

>>> Просмотр (722x804, 17 Kb)

★★★★★

Проверено: JB ()

Весело наверное было

q9 ()
Ответ на: комментарий от derlafff

Почему же? Вполне хорошее решение, если стоит задача защиты информации. Разве что в отличии от флешки с ключём, уничтожить возможность доступа в критической ситуации намного сложнее (многие флешки можно быстро и надёжно сломать голыми руками).

KivApple ★★★★★ ()

Теги: пацаны ваще котята

zolden ★★★★★ ()
Ответ на: комментарий от KivApple

Потому, что это совершенно бессмысленно.

Если стоит задача защитить информацию, то стоит зашифровать / и /home. В чем соль шифрования именно загрузчика? Легче поставить пароль на него тогда

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 1)
Ответ на: комментарий от KivApple

можно отломать порт или повредить плату, а вот чип так просто не сломаешь.

frozenix ★★★ ()
Последнее исправление: frozenix (всего исправлений: 1)
Ответ на: комментарий от frozenix

Не спорю. Но от пароля на загрузчике толку столько же, сколько от шифрованного загрузчика.

derlafff ★★★★★ ()

Молодца, конечно, но это бессмысленно.

acme ()

Но зачем? Вы храните свою коллекцию CP в /boot?

Axon ★★★★★ ()
Ответ на: комментарий от derlafff

А где автор сказал, что он не шифрует /home? Просто таким образом он защищает и /boot от возможной подмены ядра/загрузчика. Да и на нём теперь можно хранить ключи от / и /home, чтобы потом ничего не запрашивалось.

KivApple ★★★★★ ()
Ответ на: комментарий от frozenix

Бывают флешки специальной конструкции, где корпус внутри залит эпоксидкой и попытка разобрать (а чем это хуже разлома флешки?) повреждает чип. По идее такую фичу можно приделать и к простой флешке. Или использовать карту памяти. Уж если MicroSD переломить, я надеюсь, это смертельно?

И в любом случае разбить флешку чем-нибудь гораздо проще и быстрее, чем извлечь диск из компьютера и начать ломать его. А ещё не забываем, что маленькую флешку проще «потерять», если уж сломать никак не получается.

KivApple ★★★★★ ()

Уважуха. Для ноутбуков хорошо.

wbrer ★★★ ()
Ответ на: комментарий от derlafff

/ и /home. В чем соль шифрования именно загрузчика?

1. враг крадёт ноут с зашифрованным /home и открытым /boot

2. враг компиллит свой grub, с функцией перехвата паролей и отправкой их на свой сервер

3. враг подсовывает тебе твой ноут со своим грабом

4. ты радостно вбиваешь свой пароль в его граб

5. всё твоё хоумвидео слито, и выставлено фконтактике

6 ???????????????????77

7 ПРОФИТ

drBatty ★★ ()
Ответ на: комментарий от drBatty

А что мешает врагу сделать тоже самое с данным конкретным вариантом?

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от drBatty

1. враг крадёт ноут с зашифрованным /home и открытым /boot

2. враг компиллит свой grub, с функцией перехвата паролей и отправкой их на свой сервер

Нет, компилить свой GRUB придётся в случае, описанном в топике :) С открытым /boot достаточно сунуть закладку в initramfs.

Единственный актуальный способ не держать не зашифрованного кода без использования внешних носителей — TPM. Но безопасность и качество реализации оных (напомню, что при открытом стандарте TPM остаётся закрытым устройством) вызывают большие сомнения.

Homura_Akemi ()
Ответ на: комментарий от vasily_pupkin

Внешний носитель с загрузчиком — в случае чего всегда виноват недотёпа-пользователь :)

Homura_Akemi ()
Ответ на: комментарий от vasily_pupkin

ну например ты вбил пароль на расшифровку своего /boot/

bzFw5Ni2!

расскажи мне, как злоумышленник сможет узнать этот пароль? Он может его попросту сбросить, однако, ты сразу поймёшь, что /boot/ твой расковыряли, и заковыряли туда закладку.

drBatty ★★ ()
Ответ на: комментарий от wbrer

Для ноутбуков (тех, которые без битлокера и нормальной ОС) достаточна пломба, забитый вручную сиквенс загрузки, пароль на биос, отсутствие свапа и шифрованных хомяк

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от drBatty

Записать его рядом с телом твоего загрузчика, дабы прочитать его тем же путем, как туда попал модифицированный граб, например

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от drBatty

Он может его попросту сбросить

В LUKS «сброс» пассфразы эффективно уничтожает все зашифрованные данные.

Homura_Akemi ()
Ответ на: комментарий от Homura_Akemi

Нет, компилить свой GRUB придётся в случае, описанном в топике :) С открытым /boot достаточно сунуть закладку в initramfs.

ну с открытым boot'ом возможны варианты.

Единственный актуальный способ не держать не зашифрованного кода без использования внешних носителей — TPM.

TPM это тоже «внешний носитель», который содержит ключи для расшифровки.

Но безопасность и качество реализации оных (напомню, что при открытом стандарте TPM остаётся закрытым устройством) вызывают большие сомнения.

угу. Сложно гарантировать отсутствие закладок в закрытом TPM.

drBatty ★★ ()
Ответ на: комментарий от vasily_pupkin

хорошо. Но если там записан не сам пароль, а его MD5, например

477c3463e94b9470c2825946325db99c

?

А этим паролем зашифрован ключ.

drBatty ★★ ()
Ответ на: комментарий от Homura_Akemi

В LUKS «сброс» пассфразы эффективно уничтожает все зашифрованные данные.

уважаемый кэп, я не про пассфразу говорил, а про пароль для входа в зашифрованный grub. Имеется ввиду, что злоумышленник может сменить весь /boot вместе с грабом на свой, чистый, который будет запрашивать пассфразу на /home/, но _не только_ расшифровывать, но и сохранять эту пассфразу на сервере злоумышленника. В таком случае при сбросе пассфразы данные уничтожаться _для тебя_, а не для него (ибо у него есть копия).

drBatty ★★ ()
Ответ на: комментарий от vasily_pupkin

Ну так можно проверять свою флэшку на вшивость каким-нибудь скриптом, который находится на зашифрованном устройстве. Это же касается /boot и/или загрузочной области. Возможно, я что-то упускаю, но это выглядит более надёжно, чем идея доверить безопасность производителю TPM (я охотно верю, что там нет закладок, но это никак не означает, что устройство сделано качественно).

Homura_Akemi ()
Ответ на: комментарий от drBatty

Какие то невменяемые параноики пошли

- В нашем городе участились случаи краж
- Я переложу ключ от квартиры из под коврика в плафон
- Но если его там найдут?
- Я напишу записочку, что это от другой двери

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

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от Homura_Akemi

Ну так можно проверять свою флэшку на вшивость каким-нибудь скриптом

ШТО

идея доверить безопасность производителю TPM

Вы сначала решите от кого защищаетесь

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

ШТО

Это ответ на

Слишком просто изготавливается дубликат :(

Поскольку ключа на флэшке нет, то единственная цель создания «дубликата» — его дальнейшая модификация и подсовывание владельцу вместо оригинала. И если эта флэшка после загрузки тестируется, то владелец узнает, что его поимели, после чего сменит пароль.

Homura_Akemi ()
Ответ на: комментарий от Homura_Akemi

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

Другой вопрос что её можно тестировать до загрузки. На другом устройстве. And we need to go deeper

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

Потому что мой бут код может все вернуть взад после загрузки. Это же очевидно.

Но тогда нет смысла дампить пароль в загрузочную зону и куда-либо ещё :) Остаётся отправка на удалённый хост, но это подразумевает достаточно нескучные действия в труднопредсказуемом окружении, хотя при должном желании проблемой не будет.

And we need to go deeper

Я знаю об этой проблеме, спасибо :3

Homura_Akemi ()
Ответ на: комментарий от Homura_Akemi

Как я уже отметил выше, проблема является принципиальной. Можно до бесконечности усложнять жизнь злоумышленнику набором костылей и подпорок.

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

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

да. И что? Каким образом ты будешь атаковать эту md5sum?

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

Однако, остаётся возможность внедрения закладки. Что-бы этого не допустить, можно зашифровать /boot/

С другой стороны, это действительно имеет мало смысла - даже если /boot/ зашифрован, и даже если злоумышленник не может его расшифровать, то в любом случае он его может подменить. Причём на такой /boot/, который открывается ЛЮБЫМ паролем. В этом случае владелец скорее всего ничего не заметит, и спокойно введёт сначала ключ/пароль от /boot/ (который подойдёт ессно), а потом введёт пассфразу/ключ/пароль от своих данных. Далее новый загрузчик будет действовать в точности как обычно, но только срисует ваш ключ/пароль/пассфразу.

Короче, настоящие параноики должны хранить свой /boot/ на своей флешке. Очевидно ОТДЕЛЬНО от компьютера. В другом сейфе, в другом городе, и в другой стране. Так более-менее надёжно. Flash-ROM BIOS желательно хранить в третьем сейфе, как это делаю я.

drBatty ★★ ()
Ответ на: комментарий от drBatty

Короче, настоящие параноики должны хранить свой /boot/ на своей флешке.

Это конечно лучше, но не сильно, пушо см. выше.

Я вообще не понял пассажа про md5, так что оставил в стороне. Кстати сам загрузчик не зашифрован )) Он не в /boot хранится. Впрочем, это не имеет никакого значения

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

Это конечно лучше, но не сильно, пушо см. выше.

не вижу что-то. Если мой /boot/ и ключ к /dev/root у меня на флешке, что ты сможешь сделать с моим компом, в отсутствии этой флешки?

Я вообще не понял пассажа про md5, так что оставил в стороне.

что тут непонятного? для расшифровки любой информации нужен некий ключ или пароль. Мы можем проверить пароль так, что-бы не засветить свой ключ. В этом случае злоумышленник может только _подменить_ наш пароль, но не сможет его подобрать. Но если злоумышленник _подменит_ пароль, это сразу будет замечено.

Кстати сам загрузчик не зашифрован )) Он не в /boot хранится. Впрочем, это не имеет никакого значения

кстати сам загрузчик может хранится на той же флешке, а не в MBR как обычно.

drBatty ★★ ()
Ответ на: комментарий от drBatty

Для расшифровки информации неплохо было бы этот ключ сначала ввести. В этот момент его задампят. Вот как бы и все.

Про флешку я уже написал - слишком просто компрометируется.

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

Для расшифровки информации неплохо было бы этот ключ сначала ввести. В этот момент его задампят. Вот как бы и все.

кто?

Про флешку я уже написал - слишком просто компрометируется.

каким же образом?

drBatty ★★ ()
Ответ на: комментарий от drBatty

кто?

Компрометированный загрузчик

каким же образом?

Устройство с произвольным доступом, без аутентификации и авторизации. Достаточно забыть на открытом месте.

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

Но давайте будем честными, в топике речь совершенно о другом юзкейсе ))))

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от drBatty

С другой стороны, это действительно имеет мало смысла - даже если /boot/ зашифрован, и даже если злоумышленник не может его расшифровать, то в любом случае он его может подменить.

Лол как? :)) Если /boot зашифрован, то очевидно, что вместе со всем остальным. Хотите подменить терабайты данных? о.О

Homura_Akemi ()
Ответ на: комментарий от vasily_pupkin

Компрометированный загрузчик

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

Устройство с произвольным доступом, без аутентификации и авторизации. Достаточно забыть на открытом месте.

если есть такая опасность, то возможно установить на флешке например Slax, и подписать /boot/ своим gpg ключом. Ну и перед загрузкой загрузиться в Slax, и проверить подпись используя свой публичный ключ скаченный из сервера публичных ключей в Сети. Это сильно затруднит работу злоумышленника.

Но давайте будем честными, в топике речь совершенно о другом юзкейсе ))))

а каком ещё? шифрование $HOME обычно даёт достаточную защищённость.

drBatty ★★ ()
Ответ на: комментарий от Homura_Akemi

Лол как? :)) Если /boot зашифрован, то очевидно, что вместе со всем остальным. Хотите подменить терабайты данных? о.О

разве там всё шифруется одним разделом?

drBatty ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.