https://www.opennet.ru/openforum/vsluhforumID3/82159.html В реализации virtio-устройств обнаружена уязвимость (https://rhn.redhat.com/errata/RHSA-2011-1849.html), позволяющая (https://lkml.org/lkml/2011/12/22/270) организовать из изолированных гостевых систем запись и чтение данных для блочных устройств или LVM-разделов, через отправку SCSI-команд через SG_IO ioctl. Уязвимости подвержены окружения, работающие под управлением QEMU и KVM. Проблеме также подвержен OpenVZ, но только в случае проброса разделов, что обычно не практикуется для окружений на базе OpenVZ. Системы на базе Xen не подвержены проблеме, так как драйвер блочных устройств, используемый в Xen, не поддерживает вызов SG_IO ioctl.<br><br><br><br><br>Уязвимость распространяется только на блочные устройства, используемые в работе гостевых систем: например, если в гостевую систему проброшен раздел /dev/sda3, то злоумышленник, имеющий root-права в гостевой системе, может не покидая изолированное окружение получить доступ ко всем данным на диске /dev/sda, включая другие разделы и загрузочный сек...<br><br>URL: http://rwmj.wo https://www.opennet.ru/openforum/vsluhforumID3/82159.html#66 Fri, 06 Jan 2012 22:10:37 GMT Спасибо за развёрнутый ответ! Изначально я подумал что существует обратная опасность, т.е. повлиять на сервисы хост-сиситемы из контейнера.<br> https://www.opennet.ru/openforum/vsluhforumID3/82159.html#65 Fri, 06 Jan 2012 19:03:15 GMT В OpenVZ не предусмотрена изоляция процессов внутри контейнеров от действий процессов с тем же uid на хост-системе. (В другую сторону и между контейнерами - предусмотрена.) Также, с хост-системы видны через procfs процессы всех контейнеров. Поэтому если на хост-системе создать пользователя, то такой пользователь получит излишние привилегии. Это же относится к псевдо-пользователям сервисов хост-системы и аналогичным в контейнерах (совпадение uid). Правда, роль играет еще флаг dumpable (который в privsep children обычно оказывается сброшен), да и, похоже, защита от ptrace(2) с хост-системы теперь появилась (только что проверил на недавнем ядре из rhel5-ветки: kill процесса с тем же uid в контейнере прошел, а вот ptrace уже нет; насколько я помню, раньше проходил и ptrace тоже). Но формально об изменении политики заявлено не было, так что это скорее hardening.<br><br>Реально это относится прежде всего к ситуациям, когда на системе уже что-то было, а потом, не убирая этого, ядро заменили на OpenVZ'ное и стали еще и с https://www.opennet.ru/openforum/vsluhforumID3/82159.html#64 Fri, 06 Jan 2012 18:27:32 GMT &gt; например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ<br><br>Можно раскрыть этот момент подробнее? Получается что такая система как Proxmox VE (http://proxmox.com/products/proxmox-ve) потенциально небезопасна согласно политики OpenVZ?<br> https://www.opennet.ru/openforum/vsluhforumID3/82159.html#63 Mon, 02 Jan 2012 19:29:16 GMT Я не столько о конкретной уязвимости, сколько о том, что разработчики OpenVZ ранее приняли решение считать проброс блочных устройств и доступность /dev/loop* внутри контейнеров выходящими за рамки политики безопасности OpenVZ. Этот вопрос обсуждался во время моего аудита OpenVZ в конце 2005 (незадолго до выхода проекта на публику). Он сравнительно недавно поднимался повторно здесь: http://bugzilla.openvz.org/show_bug.cgi?id=1847 - вердикт по конкретным проблемам, проявляющимся при доступности блочных устройств в контейнере, пока что остался прежним - как видим, это WONTFIX. С правильностью этого подхода можно соглашаться или спорить, но это нынешняя позиция OpenVZ upstream, и она остается неизменной вот уже 6 лет. Возможно, следует улучшить документацию, чтобы эти и другие риски были более очевидны для OpenVZ-сисадминов. (Говоря о других рисках - например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ. Это тоже могло бы быть док https://www.opennet.ru/openforum/vsluhforumID3/82159.html#62 Mon, 02 Jan 2012 13:51:57 GMT &gt; При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству <br>&gt; в хост-системе, ошибка by design.<br><br>Уязвимость необязательно обусловлена только одной ошибкой. Неконтролируемый ioctl - одна из таких ошибок. Но передача блочных устройств в контейнер - тоже, безусловно, неправильное и небезопасное решение. Сабжевая новость демонстрирует только одну из возможных проблем, связанных с этим решением (примеры других проблем приведены в комментарии выше).<br> https://www.opennet.ru/openforum/vsluhforumID3/82159.html#61 Mon, 02 Jan 2012 13:48:49 GMT Ну, например, если на логическом томе создана таблица разделов, и один из них выдан виртуалке :)<br> https://www.opennet.ru/openforum/vsluhforumID3/82159.html#60 Mon, 02 Jan 2012 11:20:26 GMT При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству в хост-системе, ошибка by design.<br> https://www.opennet.ru/openforum/vsluhforumID3/82159.html#59 Mon, 02 Jan 2012 00:33:08 GMT Тогда не очень понимаю, за пределы чего можно выйти, используя описанную "уязвимость". Похоже речь идёт, всё же, не о выходе на уровень логического тома, а на уровень, как минимум, группы томов, в которой этот логический том определён.<br> https://www.opennet.ru/openforum/vsluhforumID3/82159.html#58 Mon, 02 Jan 2012 00:13:22 GMT &gt; Что вы понимаете под "томом LVM"? Physical Volume, Volume Group или Logical <br>&gt; Volume?<br><br>Конечно же Logical Volume<br><br>