ядро: отключение / dev / kmem и / dev / mem

Я понимаю это /dev/kmemи /dev/memпредоставляю доступ к памяти (т.е. сырой оперативной памяти) системы. Я также знаю, что это /dev/kmemможет быть полностью отключено в ядре, и что доступ может быть ограничен для /dev/mem.

Мне кажется, что необработанный доступ к памяти может быть полезен для разработчиков и хакеров, но зачем мне нужен доступ к памяти через /dev/mem. AFAIK это нельзя отключить в ядре (в отличие от /dev/kmem). Мне кажется, что наличие доступа к необработанной памяти, которая может быть потенциально злоупотреблена / использована, просто напрашивается на неприятности.

Есть ли какое-то практическое применение для этого? Требуются ли какие-либо пользовательские программы для правильной работы?

Существует слайд-платформа из Scale 7x 2009 под названием: « Подрыв ядра Linux: внедрение вредоносного кода через / dev / mem», который содержал эти 2 маркера.

Кому это нужно?

• X Server (видеопамять и управляющие регистры)
• DOSEmu

Из всего, что я нашел в результате поиска, покажется, что эти 2 пули являются лидерами для законного использования.

Ссылки

• Энтони Линберри в / dev / mem Rootkits - LJ 8/2009, автор Mick Bauer
• Кому нужен / dev / kmem?

Стоит отметить , что даже если вы отключили /dev/memи /dev/kmemчто память может все еще быть сброшены; взгляните, man procчтобы раскрыть /proc/kcore; это физическая память системы. У действительно хорошего набора инструментов судебной экспертизы есть инструмент, который уже делает это ; он сбрасывает память (и /bootфайлы), чтобы их можно было проанализировать.

На самом деле Ubuntu по умолчанию отключает/dev/kmem :

В настоящее время нет более современного использования, /dev/kmemкроме атакующих, использующих его для загрузки руткитов ядра. CONFIG_DEVKMEMустановлен на «п». Хотя /dev/kmemузел устройства все еще существует в Ubuntu 8.04 LTS через Ubuntu 9.04, он фактически не связан ни с чем в ядре.

Ubuntu не отключается, /dev/memпотому что это нужно приложениям .

Некоторым приложениям (Xorg) требуется прямой доступ к физической памяти из пространства пользователя. Специальный файл /dev/memсуществует для предоставления этого доступа. В прошлом было возможно просматривать и изменять память ядра из этого файла, если злоумышленник имел root-доступ. Опция CONFIG_STRICT_DEVMEMядра была введена для блокировки доступа к памяти вне устройства (первоначально названной CONFIG_NONPROMISC_DEVMEM).

Как отключить /proc/kcore?

Не включайте CONFIG_PROC_KCOREпри сборке ядра.

Как вы отключаете /dev/mem?

Что ж, просмотр man memдает нам некоторые подробности о том, как он создан:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

Вы должны быть в состоянии просто rm -rf /dev/mem; вы можете отключить на этапе сборки ядра, не включив CONFIG_STRICT_DEVMEM.

Как отключить /dev/kmem?

Убедитесь, что CONFIG_DEVKMEMон не включен при сборке ядра.

Как предотвратить холодные атаки?

Что делать , если я был в состоянии отключить /proc/kcore, /dev/mem, /dev/kmemа затем используется зашифрованный раздел подкачки или не использовать своп вообще? Ну, ваша память может быть просто заморожена и доступна таким образом. Как вы предотвращаете эту атаку? Вы шифруете свою оперативную память; как вы шифруете свою оперативную память? Ты не можешь. Смотрите TRESOR для деталей .

Как известно, /dev/memобеспечивает доступ к физической памяти работающей системы. /dev/kmemобеспечивает доступ к виртуальной памяти ядра. Оба эти символьных устройства могут быть постоянно отключены с помощью параметров конфигурации ядра (код является наиболее авторитетным источником информации, поэтому он используется для справки). Отключение первых двух параметров ниже отключит соответствующие устройства.

• CONFIG_DEVKMEM: определяет, /dev/kmemсоздается ли при загрузке
• CONFIG_DEVMEM: определяет, /dev/memсоздается ли при загрузке
• CONFIG_STRICT_DEVMEM: если /dev/memсуществует, определяет, ограничен ли доступ к нему

В зависимости от вашего дистрибутива, текущая конфигурация ядра может быть видна с помощью чего-то вроде zless /proc/config.gzили less /boot/config-$(uname -r).

Я думаю, что первоначальная цель /dev/memсостояла в том, чтобы поддержать взаимодействие с отображенными в память периферийными устройствами. Очевидные негативные последствия для безопасности, связанные с доступностью этих виртуальных устройств (например, злоумышленник может на лету исправлять память другого процесса или даже ядра), известен уже как минимум десять лет. Ограничение доступа к /dev/memбыли поддержаны в магистральном ядре с началом 2008 года , /dev/kmemтакже были необязательным , так как вокруг тогда тоже.

Десять лет назад кажется, что Xэто зависело /dev/mem, я не думаю, что это все еще так. Чтобы проверить заявления о Xнеобходимости, /dev/memя вчера удалил виртуальное устройство из своего ноутбука, и с тех пор оно работает на первый взгляд безупречно. В 2017 году, похоже, нет практического применения этих устройств вне исследований и разработок.

С точки зрения безопасности рекомендуется удалить эти устройства. Тем не менее, стоит отметить, что удаленный злоумышленник с повышенными привилегиями может читать память за пределами своего адресного пространства. Память других приложений пользовательского пространства может быть доступна с помощью /proc/<pid>/mem. Доступ к памяти ядра возможен с помощью /proc/kcore.

Я не включил /dev/memв свою систему с самого начала. Я использую Gentoo Linux, так что это неудивительно, поскольку с помощью этого дистрибутива Linux вы практически самостоятельно собираете каждый пакет, включая ядро ​​Linux.

Я никогда не замечал никаких проблем из-за отсутствия /dev/mem даже при использовании X.org X11. Только сегодня я заметил, что emerge пакета x11-drivers/xf86-video-vesaпечатает сообщение о том, что оно требует /dev/mem, например:

* This driver requires /dev/mem support in your kernel
*   Device Drivers --->
*     Character devices  --->
*       [*] /dev/mem virtual device support

Так как я не устанавливал драйвер VESA для XServer намеренно или хотя бы в качестве запасного варианта , мне фактически никогда не приходилось его использовать, и поэтому я его не заметил - до сих пор.

Но это доказывает, что а) X11 больше не нужен /dev/mem, и б) что некоторые видеодрайверы X11 все равно могут это сделать.

Новые драйверы видео для конкретного оборудования, скорее всего, будут работать без него. Точно так же, как современный X.org-X11 (на Gentoo x11-base/xorg-server) больше не должен быть suid root , вот как выглядит прогресс ...