Только так же, как modprobe
«победит» безопасность, загрузив новый код в ядро.
По разным причинам иногда имеет смысл иметь полу-привилегированный код (, например графические драйверы, внутри X-сервера ), работающего в пользовательском -пространстве, а не в потоке ядра.
kill
сделать это легче, если только это не блокирует HW. Это не сильно влияет на безопасность, но дает большие преимущества в плане надежности и архитектуры программного обеспечения.
Встраивание графических драйверов в ядро может уменьшить количество переключений контекста между X-клиентами и X-сервером, например, одним пользователем ->kernel ->user вместо того, чтобы получать данные в другой процесс использования -пространства, но X-серверы исторически были слишком большими и слишком глючными, чтобы их можно было полностью включить в ядро.
Да, вредоносный код с этими привилегиями может захватить управление ядром, если захочет, используя /dev/mem
для модификации кода ядра.
Или, например, на платформе x86 запустите инструкцию cli
, чтобы отключить прерывания на этом ядре после выполнения системного вызова iopl
, чтобы установить его уровень привилегий ввода-вывода равным звонку 0.
Но даже x86 iopl
"только" дает доступ к некоторым инструкциям:in/out (и строковым версиям ins/outs )и cli/sti. Это не позволяет вам использовать rdmsr
или wrmsr
для чтения или записи «регистров, специфичных для модели» (, например. IA32_LSTAR
, который устанавливает адрес точки входа ядра для инструкции x86 -64 syscall
), или используйте lidt
для замены таблицы дескрипторов прерываний -(, что позволит вам полностью взять на себя управление машина с существующим ядром, по крайней мере на этом ядре.)
Вы даже не можете прочитать регистры управления (, такие как CR3, которые содержат физический адрес каталога страниц -верхнего -уровня, который атакующий процесс может счесть полезным в качестве смещения в /dev/mem
для изменения свои собственные таблицы страниц в качестве альтернативы mmap
расширению /dev/mem
.)
invd
(сделать недействительными все кэши без записать -обратно!!(вариант использования = ранний BIOS до настройки ОЗУ ))— еще один забавный вариант, который всегда требует полного CPL 0 (текущего уровня привилегий ), а не только IOPL. Дажеwbinvd
является привилегированным, потому что он такой медленный (и непрерываемый ), и должен сбрасывать все кеши на всех ядрах. (См. Есть ли способ сбросить весь кэш ЦП, связанный с программой? и Использование инструкции WBINVD)
Ошибки, которые приводят к переходу на неверный адрес, запускающий данные как код, таким образом, невозможно случайно выполнить какую-либо из этих инструкций на пользовательском -пространстве X-сервере.
Текущий уровень привилегий (в защищенном и длинном режиме)представляет собой младшие 2 битаcs
(селектора сегмента кода). mov eax, cs
/ and eax, 3
работает в любом режиме для чтения уровня привилегий.
Чтобы записать уровень привилегий, вы выполняете jmp far
или call far
, чтобы установить CS:RIP
(, но запись GDT/LDT для целевого сегмента может ограничить его на основе старого уровня привилегий, поэтому пользователь -пространство не может сделать это, чтобы возвыситься ). Или вы используете int
или syscall
для переключения на кольцо 0 в точке входа ядра.
Однажды я столкнулся именно с этой проблемой.
Теперь, всякий раз, когда я устанавливаю новую виртуальную машину с помощью virt-install
, я обязательно включаю следующие параметры --nographics
, -x console=ttyS0
. Параметр -x console=ttyS0
создает подключение к виртуальной консоли через порт ttyS0. Это позволяет мне войти в виртуальную машину с хоста, используя virsh console <VMname>
, а затем я могу сбросить сетевые настройки на виртуальной машине, не перезагружая ее полностью. Внутри самой виртуальной машины это добавит следующие настройки в /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,9600n8"
GRUB_CMDLINE_LINUX=""
На одной из моих виртуальных машин мне пришлось добавить эти строки вручную после установки и пересобрать grub с помощью grub-mkconfig
, чтобы получить настройки, выдерживающие перезагрузку.
Следующие строки необходимы для того, чтобы хост мог общаться с гостями в среде KVM
Допустим, интерфейс вашего хоста выглядит так
interface: eth0
ip: 192.168.0.10/24
gateway: 192.168.0.1
Отредактируйте /etc/rc.local и добавьте следующие команды
ip link add link eth0 address 51:51:51:A8:28:A1 macvlan0 type macvlan mode bridge
ip address add 192.168.0.10/24 dev macvlan0
ip link set dev macvlan0 up
ip route flush dev eth0
ip route add default via 192.168.0.1 dev macvlan0 proto static