В реализации 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.

Уязвимость распространяется только на блочные устройства, используемые в работе гостевых систем: например, если в гостевую систему проброшен раздел /dev/sda3, то злоумышленник, имеющий root-права в гостевой системе, может не покидая изолированное окружение получить доступ ко всем данным на диске /dev/sda, включая другие разделы и загрузочный сек...

URL: http://rwmj.wordpress.com/2011/12/22/cve-2011-4127-privilege.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32703

• Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 13:45 , 31-Дек-11
  • Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 13:46 , 31-Дек-11
  • Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 14:02 , 31-Дек-11
    • Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 15:47 , 31-Дек-11
• Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 15:50 , 31-Дек-11
  • Уязвимость, позволяющая получить доступ к диску хост-системы...,shadow_alone, 16:22 , 31-Дек-11
    • Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 17:36 , 31-Дек-11
      • Уязвимость, позволяющая получить доступ к диску хост-системы...,shadow_alone, 18:03 , 31-Дек-11
  • Уязвимость, позволяющая получить доступ к диску хост-системы...,Кирилл, 02:54 , 02-Янв-12
    • Уязвимость, позволяющая получить доступ к диску хост-системы...,shadow_alone, 04:13 , 02-Янв-12
      • Уязвимость, позволяющая получить доступ к диску хост-системы...,Кирилл, 04:33 , 02-Янв-12
        • Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 17:48 , 02-Янв-12
• Уязвимость, позволяющая получить доступ к диску хост-системы...,solardiz, 20:50 , 31-Дек-11
  • Уязвимость, позволяющая получить доступ к диску хост-системы...,Bx, 15:20 , 02-Янв-12
    • Уязвимость, позволяющая получить доступ к диску хост-системы...,Аноним, 17:51 , 02-Янв-12
    • Уязвимость, позволяющая получить доступ к диску хост-системы...,solardiz, 23:29 , 02-Янв-12
      • Уязвимость, позволяющая получить доступ к диску хост-системы...,alex.h, 22:27 , 06-Янв-12
        • Уязвимость, позволяющая получить доступ к диску хост-системы...,solardiz, 23:03 , 06-Янв-12
          • Уязвимость, позволяющая получить доступ к диску хост-системы...,alex.h, 02:10 , 07-Янв-12

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

> Я правильно понимаю, что эта брешь не распространяется на окружения, где не
> используется проброс разделов (т.е. файл-образ типа qcow2)?

Т.е. используется файл-образ типа qcow2
fixed

> Я правильно понимаю, что эта брешь не распространяется на окружения, где не
> используется проброс разделов (т.е. файл-образ типа qcow2)?

Да, правильно. Проблема проявляется только если внутри гостевой системы используется физический раздел.

Причем через virtio.

Интересно, как оно действует при работе с томами LVM? Насколько я понимаю, работать не должно. Что автоматически отсекает все enterprise-системы.

> Интересно, как оно действует при работе с томами LVM? Насколько я понимаю,
> работать не должно. Что автоматически отсекает все enterprise-системы.

Мне вот тоже интересно по LVM. По идее не должно работать, если даешь гостю том, то за пределы тома он не выйдет полюбе.

Это зависит от того, рассматривается ли группа томов как одно SCSI-устройство, или нет. По идее, не должна, но я в данной области не спец, потому и спрашиваю.

> Это зависит от того, рассматривается ли группа томов как одно SCSI-устройство, или
> нет. По идее, не должна, но я в данной области не
> спец, потому и спрашиваю.

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

Что вы понимаете под "томом LVM"? Physical Volume, Volume Group или Logical Volume?

> Что вы понимаете под "томом LVM"? Physical Volume, Volume Group или Logical
> Volume?

Конечно же Logical Volume

Тогда не очень понимаю, за пределы чего можно выйти, используя описанную "уязвимость". Похоже речь идёт, всё же, не о выходе на уровень логического тома, а на уровень, как минимум, группы томов, в которой этот логический том определён.

Ну, например, если на логическом томе создана таблица разделов, и один из них выдан виртуалке :)

> Проблеме также подвержен OpenVZ, но только в случае проброса разделов, что обычно не практикуется для окружений на базе OpenVZ.

Проброс разделов в OpenVZ и даже просто разрешение использования /dev/loop* устройств внутри OpenVZ-контейнера небезопасны by design, и без этой уязвимости. Можно создать на таком устройстве запорченную файловую систему, которую потом попытаться подмонтировать - и получить таким образом kernel panic (гарантированно при направленных на это действиях - например, опция монтирования errors=panic для ext*), а потенциально - выполнение произвольного кода в ring 0 через особенности реализации одной из файловых систем.

Таких настроек следует избегать. (По умолчанию, /dev/loop* из контейнеров не доступны - именно по этой причине.) Если нужно пробросить отдельный диск, RAID-массив и т.п. в контейнер, соответствующие файловые системы следует монтировать с хост-системы. Например, так: http://wiki.openvz.org/Bind_mounts

При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству в хост-системе, ошибка by design.

> При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству
> в хост-системе, ошибка by design.

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

Я не столько о конкретной уязвимости, сколько о том, что разработчики OpenVZ ранее приняли решение считать проброс блочных устройств и доступность /dev/loop* внутри контейнеров выходящими за рамки политики безопасности OpenVZ. Этот вопрос обсуждался во время моего аудита OpenVZ в конце 2005 (незадолго до выхода проекта на публику). Он сравнительно недавно поднимался повторно здесь: http://bugzilla.openvz.org/show_bug.cgi?id=1847 - вердикт по конкретным проблемам, проявляющимся при доступности блочных устройств в контейнере, пока что остался прежним - как видим, это WONTFIX. С правильностью этого подхода можно соглашаться или спорить, но это нынешняя позиция OpenVZ upstream, и она остается неизменной вот уже 6 лет. Возможно, следует улучшить документацию, чтобы эти и другие риски были более очевидны для OpenVZ-сисадминов. (Говоря о других рисках - например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ. Это тоже могло бы быть документировано явно, что, кажется, на данный момент не сделано.)

> например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ

Можно раскрыть этот момент подробнее? Получается что такая система как Proxmox VE (http://proxmox.com/products/proxmox-ve) потенциально небезопасна согласно политики OpenVZ?

В OpenVZ не предусмотрена изоляция процессов внутри контейнеров от действий процессов с тем же uid на хост-системе. (В другую сторону и между контейнерами - предусмотрена.) Также, с хост-системы видны через procfs процессы всех контейнеров. Поэтому если на хост-системе создать пользователя, то такой пользователь получит излишние привилегии. Это же относится к псевдо-пользователям сервисов хост-системы и аналогичным в контейнерах (совпадение uid). Правда, роль играет еще флаг dumpable (который в privsep children обычно оказывается сброшен), да и, похоже, защита от ptrace(2) с хост-системы теперь появилась (только что проверил на недавнем ядре из rhel5-ветки: kill процесса с тем же uid в контейнере прошел, а вот ptrace уже нет; насколько я помню, раньше проходил и ptrace тоже). Но формально об изменении политики заявлено не было, так что это скорее hardening.

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

> Получается что такая система как Proxmox VE потенциально небезопасна согласно политики OpenVZ?

Я не в курсе деталей, но мне представляется что там риск оправданный - т.е. всё, что делается на хост-системе, относится к администрированию контейнеров. (Разве что администрирование еще и виртуальных машин KVM можно посчитать неоправданным риском для систем в OpenVZ-контейнерах, но и тут есть некоторый смысл в этой универсальности, что может оправдывать риск.) Они могли бы этот риск снизить выбрав для своего веб-интерфейса диапазон uid, обычно в контейнерах не используемый. (Сделали ли они так или нет - не знаю. Я сам Proxmox VE пока не использовал.)

Спасибо за развёрнутый ответ! Изначально я подумал что существует обратная опасность, т.е. повлиять на сервисы хост-сиситемы из контейнера.