| 1.2, Аноним (-), 13:45, 31/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я правильно понимаю, что эта брешь не распространяется на окружения, где не используется проброс разделов (т.е. файл-образ типа qcow2)?
| | |
| |
| 2.3, Аноним (-), 13:46, 31/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Я правильно понимаю, что эта брешь не распространяется на окружения, где не
> используется проброс разделов (т.е. файл-образ типа qcow2)?
Т.е. используется файл-образ типа qcow2
fixed
| | |
| 2.4, Аноним (-), 14:02, 31/12/2011 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Я правильно понимаю, что эта брешь не распространяется на окружения, где не
> используется проброс разделов (т.е. файл-образ типа qcow2)?
Да, правильно. Проблема проявляется только если внутри гостевой системы используется физический раздел.
| | |
|
| 1.12, Аноним (-), 15:50, 31/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Интересно, как оно действует при работе с томами LVM? Насколько я понимаю, работать не должно. Что автоматически отсекает все enterprise-системы.
| | |
| |
| 2.16, shadow_alone (ok), 16:22, 31/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Интересно, как оно действует при работе с томами LVM? Насколько я понимаю,
> работать не должно. Что автоматически отсекает все enterprise-системы.
Мне вот тоже интересно по LVM. По идее не должно работать, если даешь гостю том, то за пределы тома он не выйдет полюбе.
| | |
| |
| 3.20, Аноним (-), 17:36, 31/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
Это зависит от того, рассматривается ли группа томов как одно SCSI-устройство, или нет. По идее, не должна, но я в данной области не спец, потому и спрашиваю.
| | |
| |
| 4.22, shadow_alone (ok), 18:03, 31/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Это зависит от того, рассматривается ли группа томов как одно SCSI-устройство, или
> нет. По идее, не должна, но я в данной области не
> спец, потому и спрашиваю.
По идее,том как отдельное устройство.То есть выше прыгать уже некуда.
| | |
|
|
| 2.57, Кирилл (??), 02:54, 02/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
Что вы понимаете под "томом LVM"? Physical Volume, Volume Group или Logical Volume?
| | |
| |
| 3.58, shadow_alone (ok), 04:13, 02/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Что вы понимаете под "томом LVM"? Physical Volume, Volume Group или Logical
> Volume?
Конечно же Logical Volume
| | |
| |
| 4.59, Кирилл (??), 04:33, 02/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
Тогда не очень понимаю, за пределы чего можно выйти, используя описанную "уязвимость". Похоже речь идёт, всё же, не о выходе на уровень логического тома, а на уровень, как минимум, группы томов, в которой этот логический том определён.
| | |
| |
| 5.61, Аноним (-), 17:48, 02/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ну, например, если на логическом томе создана таблица разделов, и один из них выдан виртуалке :)
| | |
|
|
|
|
| 1.31, solardiz (ok), 20:50, 31/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 > Проблеме также подвержен OpenVZ, но только в случае проброса разделов, что обычно не практикуется для окружений на базе OpenVZ.
Проброс разделов в OpenVZ и даже просто разрешение использования /dev/loop* устройств внутри OpenVZ-контейнера небезопасны by design, и без этой уязвимости. Можно создать на таком устройстве запорченную файловую систему, которую потом попытаться подмонтировать - и получить таким образом kernel panic (гарантированно при направленных на это действиях - например, опция монтирования errors=panic для ext*), а потенциально - выполнение произвольного кода в ring 0 через особенности реализации одной из файловых систем.
Таких настроек следует избегать. (По умолчанию, /dev/loop* из контейнеров не доступны - именно по этой причине.) Если нужно пробросить отдельный диск, RAID-массив и т.п. в контейнер, соответствующие файловые системы следует монтировать с хост-системы. Например, так: http://wiki.openvz.org/Bind_mounts
| | |
| |
| 2.60, Bx (ok), 15:20, 02/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
 При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству в хост-системе, ошибка by design.
| | |
| |
| 3.62, Аноним (-), 17:51, 02/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
> При всем моём уважении, Вы ошибаетесь. Уязвимость именно в передаче ioctl устройству
> в хост-системе, ошибка by design.
Уязвимость необязательно обусловлена только одной ошибкой. Неконтролируемый ioctl - одна из таких ошибок. Но передача блочных устройств в контейнер - тоже, безусловно, неправильное и небезопасное решение. Сабжевая новость демонстрирует только одну из возможных проблем, связанных с этим решением (примеры других проблем приведены в комментарии выше).
| | |
| 3.63, solardiz (ok), 23:29, 02/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
Я не столько о конкретной уязвимости, сколько о том, что разработчики OpenVZ ранее приняли решение считать проброс блочных устройств и доступность /dev/loop* внутри контейнеров выходящими за рамки политики безопасности OpenVZ. Этот вопрос обсуждался во время моего аудита OpenVZ в конце 2005 (незадолго до выхода проекта на публику). Он сравнительно недавно поднимался повторно здесь: http://bugzilla.openvz.org/show_bug.cgi?id=1847 - вердикт по конкретным проблемам, проявляющимся при доступности блочных устройств в контейнере, пока что остался прежним - как видим, это WONTFIX. С правильностью этого подхода можно соглашаться или спорить, но это нынешняя позиция OpenVZ upstream, и она остается неизменной вот уже 6 лет. Возможно, следует улучшить документацию, чтобы эти и другие риски были более очевидны для OpenVZ-сисадминов. (Говоря о других рисках - например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ. Это тоже могло бы быть документировано явно, что, кажется, на данный момент не сделано.)
| | |
| |
| 4.64, alex.h (??), 22:27, 06/01/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> например, использование хост-системы для чего-либо кроме администрирования контейнеров тоже выходит за рамки политики безопасности OpenVZ
Можно раскрыть этот момент подробнее? Получается что такая система как Proxmox VE (http://proxmox.com/products/proxmox-ve) потенциально небезопасна согласно политики OpenVZ?
| | |
| |
| 5.65, solardiz (ok), 23:03, 06/01/2012 [^] [^^] [^^^] [ответить]
| +/– | |
В OpenVZ не предусмотрена изоляция процессов внутри контейнеров от действий процессов с тем же uid на хост-системе. (В другую сторону и между контейнерами - предусмотрена.) Также, с хост-системы видны через procfs процессы всех контейнеров. Поэтому если на хост-системе создать пользователя, то такой пользователь получит излишние привилегии. Это же относится к псевдо-пользователям сервисов хост-системы и аналогичным в контейнерах (совпадение uid). Правда, роль играет еще флаг dumpable (который в privsep children обычно оказывается сброшен), да и, похоже, защита от ptrace(2) с хост-системы теперь появилась (только что проверил на недавнем ядре из rhel5-ветки: kill процесса с тем же uid в контейнере прошел, а вот ptrace уже нет; насколько я помню, раньше проходил и ptrace тоже). Но формально об изменении политики заявлено не было, так что это скорее hardening.
Реально это относится прежде всего к ситуациям, когда на системе уже что-то было, а потом, не убирая этого, ядро заменили на OpenVZ'ное и стали еще и создавать контейнеры. Настроенные таким образом системы подвергают пользователей и сервисы в контейнерах дополнительному риску атак со стороны пользователей и сервисов хост-системы.
> Получается что такая система как Proxmox VE потенциально небезопасна согласно политики OpenVZ?
Я не в курсе деталей, но мне представляется что там риск оправданный - т.е. всё, что делается на хост-системе, относится к администрированию контейнеров. (Разве что администрирование еще и виртуальных машин KVM можно посчитать неоправданным риском для систем в OpenVZ-контейнерах, но и тут есть некоторый смысл в этой универсальности, что может оправдывать риск.) Они могли бы этот риск снизить выбрав для своего веб-интерфейса диапазон uid, обычно в контейнерах не используемый. (Сделали ли они так или нет - не знаю. Я сам Proxmox VE пока не использовал.)
| | |
| |
| 6.66, alex.h (??), 02:10, 07/01/2012 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо за развёрнутый ответ! Изначально я подумал что существует обратная опасность, т.е. повлиять на сервисы хост-сиситемы из контейнера.
| | |
|
|
|
|
|
|
