Защита от НСД: Очистка оперативной и внешней памяти

Скорее всего никак. И сертифицированны они по какому-то самому низшему разряду.

Для затирания файлов есть opensource утилита (их даже несколько, но названий не помню), а память кажется раньше grsec чистить умел.

Т.е реализовать это opensource утилитами проблем нет, а вот насчет как сделано - хз.

Очистка памяти требуется с класса защищенности 5 и выше (http://www.fstec.ru/_docs/doc_3_3_003.htm).
Отечественные системы сертифицированы в среднем по четвертому классу, значит реализация в них должна быть.

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

Неужели и Вам, как юзеру Gentoo Hardened, нечем похвастаться?

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

Если уж совсем паранойя, то есть wipe и shred, но используются целево, а не подчищают в фоне.

Просто обычно подразумевается, что если есть физических доступ к УЖЕ работающей машине с УЖЕ подмонтированным крипторазделом, то тут могут помочь только аппаратные меры (например intel AES, который не в оперативке хранит ключ, а в регистре процессора, при это считать его просто так невозможно). Если же кто-то поимел удаленно истинного рута (в случае SELinux root != истинный root) в системе, то тут тоже считается, что ничего нельзя сделать, кроме как отключить систему.

Защита, при которую Вы тут пишете имеет смысл только в случае, если на системе работают с настолько важными данными, что оперативку заморозят и сдампят, найдя в ней часть документа, а Вам засунут в зад паяльник, чтобы получить пароль от криптотома, чтобы там посмотреть остаточную информацию о файле. Только вопрос в том, что при такой атаке Вам лично (а не Вашим начальникам) будет уже пофиг на ИБ, поэтому мало кто из гражданских этим заинтересован, т.к. при настолько серьёзной атаке ИБ уже бессмысленна.
Если же рассматривается ситуация со злостными шпийонами, которые похитят (работающий!!! с подмонтированным криптотомом!!!) ноутбук, то тут всё просто - гибернация через 10 минут неактивности с перезагрузкой по окончанию гибернации. Если память ECC, то даже не нужно извращаться с тем, что первая запись в GRUB было memtest.
Только вот дело в том, что в таких случаях обычно применяют системы физического уничтожения накопителей и оперативной памяти, т.к. вероятность, что документ был вообще стерт в диска весьма мала.
Мало того, если нужно, чтобы нельзя было сдампить оперативку, то достаточно иметь ECC: её невозможно переинициалировать без автостирания.

Пишешь патчик для ведра, который перед free() будет записывать в оперативку мусор.

Дело в том, что реально это нафиг никому не нужно

Потому-то патчика до сих пор и нет. Страдающие паранойей не умеют, а умеющим это нафиг не нужно.

Прошу прощения, для оперативки есть поддержка в случае hardened kernel. Просто я никогда не видел этот пункт, т.к. нужно, что HIBERNATION было установлено в n.


Configuration option: CONFIG_PAX_MEMORY_SANITIZE
By saying Y here the kernel will erase memory pages as soon as they are freed. This is turn reduces the lifetime of data stored in the pages, making it less likely that sensitive information such as passwords, cryptographic secrets, etc. stay in memory for too long.

This is especially useful for programs whose runtime is short, long lived processes and the kernel itself benefit from this as long as they operate on whole memory pages and ensure time freeing of pages that may hold sensitive information.

The tradeoff is performance impact, on a single CPU system kernel compilation sees a 3% slowdown, other systems and workloads may vary and you are advised to test this feature on your expected workload before deploying it.

Note that this feature does not protect data stored in live pages, e.g., process memory swapped to disk may there for a long time.

См. выше.

Остался только вопрос про ФС. Теоретически, это можно через FUSE реализовать.

Да просто шифровать нужные директории — и все.

Я уже писал об этом выше. Но тут другая атака рассматривается.

Когда там уже аппаратно ускоренное криптование оперативы?

Замутить что ли криптосвоп поверх тмпфс... Тормозить только будет похлеще свопящегося оффтопика.

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

Кстати, а есть способ заставить ведро и прочие бинари работать со страницами памяти в свопе напрямую, без копирования в аппаратную оперативную память

А ключи для шифрования SSD ты будешь хранить... в кэше процессора? :)

А ключи для шифрования SSD ты будешь хранить... в кэше процессора?

Тоже интересный вопрос. На неиспользуемых регистрах? Или в буфере на контроллере памяти... Или вкорячить в микрокод... ХЗ. Вообще-то для этого дела подошёл бы TPM с небольшим количеством памяти, для хранения всего дешифрующего кода ведра. Но это всё фантазии. Или нет?

Краеугольный вопрос всей темы секьюрити: а веришь ли ты производителю TPM?
Ведь используя сабжевые модули ты по сути кладешь свои ключики в черный ящик, принцип работы которого совершенно неизвестен.

веришь ли ты производителю «${NAMEYOURDEVICE}»?

Нет.

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

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

Краеугольный вопрос всей темы секьюрити

«Каковы стоимость и шанс успешного взлома?»

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

Садимся логическим анализатором на шину TPM'a и читаем. Даже паять может не понадобиться.

В этом вопросе рулят всякие кастомные одноплатники.

С одноплатниками в плане схемотехники даже проще разобраться, и JTAG там часто бывает.

А хранить пароль от TPM?

На всё это также есть контрмеры. ☺ Не хочется скатывать тред в гонку вооружений больше, чем он уже скатился.

Никто не скатывает, народ мозгами шевелит.
Какие контрмеры?

В предыдущем комменте я опечатался: Как хранить пароль от TPM?

Очистка должна производиться путем записи маскирующей информации в память при ее освобождении перераспределении

Кажется OpenBSD так делает

Какие контрмеры?

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

Как хранить пароль от TPM?

На внешнем носителе, больше негде.

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

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

память кажется раньше grsec чистить умел.

swap он точно затирает хренотой при штатном выключении, а вот насчет оперативы - не уверен, не помню

Update: да, только не grsec, а pax, как сказали выше

Eddy_Em

Пишешь патчик для ведра, который перед free()

тогда для libc уж. Кстати, проблема решается через LD_PRELOAD. Т.е. пара строчек в /etc и вуаля, дистр 5 категории защиты. Шутка.

А и правда ведь: можно ограничиться таким простым патчиком.

Но все-таки круче в ядро это воткнуть. И говорить: наше ведро — самое ведристое ведро в мире, и никакое ведро непереведряет наше ведро по ведристости.

В ядро воткнуть не получится, оно управляет памятью на уровне brk/sbrk, т.е. тупо выделяет один (с т.з. приложения) большой кусок памяти. А вот его уже malloc/new дробят на более мелкие куски, но ядру об этом ничего не известно.

и никакое ведро непереведряет наше ведро по ведристости.

это всегда можно сказать, мсвс так и делает :)

А я думал, что подчистку памяти после смерти процесса реализует ядро. Эх, учиться, учиться и еще раз учиться, как завещал товарищ Ленин!

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

В какой памяти? Процесс может быть 25 раз вытеснен в своп вместе с ключем, а потом следы этого ключа окажутся на разных _физических_ страницах. От вытеснения в своп кажется можно убежать с помощью параметров MMAP, но это доступно только руту.

Точно уверенным можно быть только с патчем на ядре.

Защита, при которую Вы тут пишете имеет смысл только в случае, если на системе работают с настолько важными данными, что оперативку заморозят и сдампят, найдя в ней часть документа, а Вам засунут в зад паяльник,

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

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

А я думал, что подчистку памяти после смерти процесса реализует ядро.

после смерти процесса да. Но я так понял что тут на каждый free() хотят забивать память мусором. Да ещё небось и указатель на NULL направлять. Кстати, полезная техника. В dovecot, например, так делают. Пару раз от дырок спасалою

shred

От вытеснения в своп кажется можно убежать с помощью параметров MMAP, но это доступно только руту.

Можно через mlockall, только надо ulimit -l поднять т.к. по дефолту 64кб памяти на процесс можно залочить.

В принципе для ключей должно хватить ;)

Но вот вопрос не могут ли при каких-то условиях данные переместиться между физическими страницами?

+ гибернейт по любому сбросит все в своп.

не могут ли при каких-то условиях данные переместиться между физическими страницами?

Может и могут (какой-нить vm.compact_memory), а на что это влияет? Что кому-то старая страница с ключом достанется? Да, косяк, это в ядре должно учитываться.

+ гибернейт по любому сбросит все в своп.

тут поможет шифрование свопа. Другое дело что гибернейт, собака, не поддерживает шифрованный своп (по крайней мере так было раньше).

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

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

По идее в кеше содержится кусочек памяти? Разве можно загрузить что-то в кеш напрямую, не используя память?

Поддерживает он шифрованный своп, только надо будет при старте пароль вводить.

Кажется это умеет tuxOnIce. Точно не помню, уже давно не возился 8(

По идее в кеше содержится кусочек памяти? Разве можно загрузить что-то в кеш напрямую, не используя память?

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

Проблема кэша и регистров в том, чтобы не дать процессору сбросить их.

Нашёл какие-то патчи для ведра: http://www1.informatik.uni-erlangen.de/tresor

Also cast liberte

В какой памяти? Процесс может быть 25 раз вытеснен в своп вместе с ключем, а потом следы этого ключа окажутся на разных _физических_ страницах. От вытеснения в своп кажется можно убежать с помощью параметров MMAP, но это доступно только руту.

Эм... Насколько мне известно, всё kernel-mode ПО для шифрования запрещают вытеснение ключа в память, потому что.... ВНЕЗАПНО!!!... часто этим же ключем ещё и раздел со свопом зашифрован. Кстати, именно поэтому нельзя использовать swap по сети, если нет патчей, который запрещают вытеснение iscsi/nbd/nfs/чего угодно из реальной оперативки.

От вытеснения в своп кажется можно убежать с помощью параметров MMAP, но это доступно только руту.

Да, и не только этих параметров, особенно когда ядра касается.

доступно только руту.

Прошу хоть один пример ФС или шифратора для блочных устройств, которому не нужны права рута (да и модуль ядра обычно нужен, т.к. на FUSE - это ппц тормозно).
Если же Вы рассуждаете про всякие «шифровалка для одного файла» и «сделай зашифрованный архив одним кликом», то Вы несколько не поняли сути вопроса, не говоря уже о том, что такое ПО используется в энтерпрайзе (а не хомячками с виндой, чтобы мама/жена порно не увидела) только электронной почты (gnupgp).

Просто очевидно, что для нормальной работы ПО для шифрования ФС (или overlay-ФС или ФС с интегрированным шифрованием) нужен рут (а по-хорошему, ещё собственный модуль ядра, а не FUSE), где вопросы с вытеснением решены by-design, т.к. там может своп шифроваться.

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

Точно уверенным можно быть только с патчем на ядре.

???
См. выше:
1. Обычно своп можно класть через слой шифрования. А значит код защищен от вытеснения.
2. Обычно своп зашифрован в таких системах.

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

Мне кажется, что Вы - несколько воинствующая школота, которая начиталась Хакера и пытается харденед гентушнику, что он - говно собачье и ничего не смыслит в безопасности. Прочитайте уже про абстрактную модель угроз и уровней угроз: если у Вас разные уровни доступа, то это нисколько не значит, что стандартная модель уровня иерархии абстракций безопасности не работает. Т.е. если у взломщика уже есть более высокий уровень привилегий, то решать проблему уровнем ниже обычно не имеет смысла (как Вы будете защищать апач от действий злоумышленника, который получил истинного рута?)

Что касается ключей и возможности их с3.14здить:
1. В случае использования Intel AES соснёте (ключ внутри регистров проца, достать можно только разобрав процессор на лету).
2. В случае использования аппаратного контроллера шифрования соснёте.
3. В случае использования hot reboot + загрузка дампера с флешки и слитие на неё дампа памяти, то есть вероятность соснуть из-за того, что дампер сам затрет часть памяти собой, также биос может делать полный тест памяти, также может быть ECC, которая при ребуте точно очистится, на биосе тупо есть пароль и четко заданы boot-устройства.
4. В случае с выдергиванием кабеля из розетки, замораживанием оперативы и перетыканием её в другой комп/спец оборудование с дальнейшим дампом Вы соснете с ECC, т.к. она при инициализации очистится.
5. В случае, если злоумышленник использовал спец оборудование (USB/Firewire) и поимел ядро через переполнение буфера (или подобную ошибку), поможет PaX.
6. В случае, если была подключена express port (что очень вероятно для ноутов) или PCI-e карта, которая может легко считать память может помочь IOMUU (но я не видел реализации, которая бы ограничивала бы устройства заранее). Однако, тут же более вероятен более дешевый и беспалевный метод.
7. В случае, если система было взломана удаленно, был получен истинный рут, то можно слить дамп (хотя при особой настройке SELinux можно даже истинного рута повертеть сами знаете на чем, запретить ему прямой доступ к памяти (/dev/mem и прочие), а также запретить загружать/выгружать модули ядра). Но в этом случае Вас уже и так 10 раз поимели, т.к. тут уже получен доступ к более высокому уровню.

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

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

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

Я уже выше писал, что в PaX есть поддержка затирание RAM при освобождении.

Я прошу не употреблять слова типа школота, говно, федорасты итп.

Как модератор или просто просишь? :)

И да: почему мегабаксу можно, мне - нет?

просто прошу.

Мегабакс неадекватен, имхо. Не хочу с ним связываться, но если увижу то буду тереть. Только тут тоже много нюансов. Я же могу тебя нормально попросить, верно? А его просить бесполезно.