Занятно : первое что я услышал о линуксе (тогда вообще узнал о его существовании), что это невероятно крутая ОС, в которой можно шифровать участки памяти так, что даже имея все права в ядре какер ничего не добудет. Сколько я искал решений по шифрованию памяти - ничего толкового не нашел.
По делу: воровство из tmpfs - это еще полбеды, можно ведь из гипервизора в памяти гостя копаться.

, можно ведь из гипервизора в памяти гостя копаться.

А гипервизор в биосе, а гость это обычная установленная ОС?

Чем можно зашифровать tmpfs?

Имхо таких средств нет, но ты можешь начать их разработку, например добавить шифрование в драйвер tmpfs

Моя тебя не понимать.

Единственный совет: не хранить критичные данные в tmpfs.

Лучше вообще не хранить критичные данные. Нигде.

ну допустим пойдём мы другим путём, засунем в память зашифрованный ext4 раздел в виде файла образа. tmpfs зашифрован, ок. а с обычной рабочей памятью как быть? я вот root:toor эту строчку скопировал ctrl + c, откуда мне знать, что она не утечёт из памяти в открытом виде?

надо шифровать всю память на самом низком уровне ядра. там же и tmpfs окажется недоступен, тогда.

сцуко, 2020 год на дворе, неужели линукс так и не может в шифрование памяти.

Ты уверен, что тебе это надо? У тебя пароли в памяти plaint text’ом висят? Не захешенные и не засоленные? Из хоста можно прочитать твои хеши/соли?

НИКОГДА не копируй пароли в буфер обмена

В QEMU есть замечательная команда dump-guest-memory по протоколу qmp, так что даже линукс работающий в tmpfs выдаст всё своё содержимое.

Эта команда точно также и ключ от зашифрованного tmpfs выдаст, так что какой смысл

с обычной рабочей памятью как быть?

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

Остальное имхо потребует не только переписывания ядра, но и пользовательских программ.

Эта команда точно также и ключ от зашифрованного tmpfs выдаст, так что какой смысл

Ну как минимум часть автоматических зондов отсеится.

В приципе ещё можно сделать шифрующее устройство на основе подключенного через два RS порта(не USB) микроконтроллера с активированной защитой ппошивки.

RS порта два потому что с одним работает драйвер FS, а другой через два cat отправляются на zram или sd накопитель.

Только через аппаратную поддержку. Софтом шифровать - бесполезно

https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html

почему?

почему?

Ну копируй.

надо шифровать всю память на самом низком уровне ядра

И с какой скоростью будет работать шифрование/расшифрование содержимого памяти на лету? Чай не военная ОС особого назначения. Что ты вообще несешь? Весь тред – чушь несусветная и будь модераторы на этом ресурсе хоть чутка технически грамотны, снесли бы с -7 «Тупак».

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

Если предполагается, что есть возможность снять дамп памяти, то никак.

Недавно завезли новый зонд, кажется, Lockdown. С случае с qemu не поможет, конечно, но можно запретить локальному руту шароёбиться в памяти. Но софтовые решения всё равно такое себе

Существует RamCrypt который может шифровать память на низком уровне и хранить ключи напрямую в регистрах AES-NI-совместимого процессора.

ЕМНИП в максимально параноидальной конфигурации позволяет шифровать до 97% содержимого всей памяти вообще(в т.ч. tmpfs). Но есть проблема - оно старое и может не собраться с современным ядром.

Раз уж есть возможность потестировать, то попрошу тебя, ТС, попробовать это в современном ядре и отписаться по результатам, мне и самому интересно.

годнота, я не параноик, но потыкать интересно.

Обязательно отпишись по результатам!

Может даже всей толпой нормальный форк сделаем, совместимый с современным ядром.

С Xen копаться будет труднее.

Блочные устройства запиливаются вот этим: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/ramdisk.html

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

момент съема данных система в виртуалке просто физически не заметит.

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

вариант2: копировать ram параллельно с работой системы. для хоста это не проблема. или сразу, абсолютно прозрачно для гостя, анализировать его работу

вариант3: насколько я встречал, сейчас пытаются делать систему менеджмента ram виртуалок с CoW. тут момент копирования ram, точнее творения снимка системы, вообще мгновенный.

короч только личный железный сервер спасет отца русской демократии.

в виртуалке

Может слегка повысить затраты.

короч только личный железный сервер

Эта фича хорошо бы пригодилась для железного сервера. Для готовности добавить panic button.

вариант2: копировать ram параллельно с работой системы

Палево.

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

Если можно оправиться от одиночного удара и есть watchdog (которых нет), то это неважно.

вариант3

Вот от него надо бежать без нюансов.

Эта фича хорошо бы пригодилась для железного сервера. Для готовности добавить panic button.

если к железу сервера есть аппратный доступ, то даже железный сервер можно вскрыть. сколь помню были эксперименты, при которых замораживали сервер и перезагружали со своим загрузчиком, который быстро дампил ram. отрицательные температуры увеличивали время жизни заряда в dram, содержимое памяти «зависало» в ячейках и прекрасно дампилось потом.

вариант2: копировать ram параллельно с работой системы

Палево.

Хде и каг ?? гостевая система никак не может отследить действия хоста.

чужое железо это чужое железо. там ты ничем не защищен…
не вскрываемые вычисления на чужом железе сколь помнится теоритически возможны только на квантовых компах.

Учишь, учишь, а все равно одни двоечники.

Глупый вопрос: зачем изобретается криптография на разных уровнях сетевой модели (комментарий)

Глупый вопрос: зачем изобретается криптография на разных уровнях сетевой модели (комментарий)

Глупый вопрос: зачем изобретается криптография на разных уровнях сетевой модели (комментарий)

Глупый вопрос: зачем изобретается криптография на разных уровнях сетевой модели (комментарий)

Наподобие как здесь описано:

Защита каталога паролем и автовход в centos (комментарий)

скриптом создаешь шифрованный каталог в /dem/shm/vasya

Любая технология шифрования каталогов будет работать с каталогами в tmpfs.

А кто тебе сказал что для защиты памяти от root ее надо только шифровать? Есть и другие, стандартные, методы защиты.

SME can therefore be used to protect the contents of DRAM from physical attacks on the system.

Это на случай когда рабочую планку памяти рбольют жидким азотом, выдернут и попробуют дампануть на спец оборудовании. Лучший вариант: закрывать дверь в серверную…

Тема классная, но, ИМХО, это всё полумеры способные вызвать чувство ложной защищенности. Единственный способ надежно защитить информацию от локального физического доступа - использовать свою собственную инфраструктуру. Т.к если на стороне облачного провайдера кто-то реально озаботится тем что-бы получить доступ к TLS ключам того-же NGINX по ссылке - то он просто будет снимать дампы до тех пор пока не попадёт на эти 3% времени когда ключ лежит в памяти незашифрованным. Это не настолько сложно сделать. Всего-то снять пару сотен дампов памяти с виртуалки в разные моменты времени, и, ключ будет обнаруживаться в паре дампов как минимум.

UPD: ну и необходимость делать «you need to disable swapping» в настройке конфигурации ведра делают данную штуку бесполезной в практическом применении.

На случай обливания планок памяти жидким азотом (и для сокращения возможности проведения аттак типа rowhammer) существует такая штука как DRAM Scrambling которая уже давным давно применяется во всех материнках, так что, думаю, просто облить работающую память жидким азотом и извлечь из неё данные на другой системе будет проблематично.

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

Фиг его знает. У некоторых материнок (вроде ASUS’а) вообще свои методы этого самого скрамблинга. Ключ-то наверняка где-то храниться, и вряд-ли в безопасном виде, т.к основная суть скрамблинга, все-таки в сокращении всяких потенциально опасных электромагнитных флуктуаций, а не в обеспечении безопасности.

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

А зачем всяким облакам палиться ?

Я имел ввиду - после обливания жидким азотом (не дописал немного). Так-то облака-то наверняка могут упереть данные из ОЗУ VPS’ки чуть-ли не на лету (в шапке темы такой способ даже описан).

существует такая штука как DRAM Scrambling которая уже давным давно применяется во всех материнках

Скремблер не является средством гарантирующим приватность и целостность!

Безопасность REST API для мобильного приложения (комментарий)

Безопасность REST API для мобильного приложения (комментарий)

Так-то облака-то наверняка могут упереть данные из ОЗУ VPS’ки чуть-ли не на лету (в шапке темы такой способ даже описан).

Уже много лет в линуксе и гипервизорах есть поддержка системы живой миграции CRIU, которая на лету переносит запущенную виртуалку (оперативную память, файловые дескрипторы, диски, если нужно) с одного физического хоста на другой, полностью прозрачно для виртуалки. Этим активно пользуются хостеры.

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

Ынтель - аппаратный троян от АНБ?!!

Security Boot и подпись загрузчика Windows (комментарий)

«восстановления закрытого ключа ECDSA, обрабатываемого в анклаве Intel SGX, после осуществления в системе всего одной операции с цифровой подписью»

был кстати патч на ядро, когда ключ для люкса хранился только в регистре процессора. как раз от колд бут атак.