Citrix XenServer Free 5.6 Security или «…you need to find a different hypervisor»

    Чем дальше развиваются технологии виртуализации, тем больше разнообразных «грандов ИТ технологий» выходит на рынок. Несмотря на то, что проект Xen как таковой довольно давно существует в виде open source решения, такая операционная система с интегрированным гипервизором как Citrix XenServer относительно недавно привлекла внимание клиентов Enterprise уровня. Изначально ОС была ориентирована на low/mid-end предприятия и предназначалась для решения проблем минимизации затрат на мультисерверную архитектуру. Но в процессе развития, компания Citrix интегрировала в свой гипервизор такие жизненно важные вещи как High Availability и Likewise интеграцию c Active Directory. Таким образом, на данный момент существуют коммерческие версии Citrix XenServer позиционирующиеся как реальная альтернатива VMWare ESX/ESXi. Но, как известно, к гипервизорам предъявляются особые требования безопасности. Это обусловлено тем, что при захвате гипервизора наиболее вероятно, что компания потеряет не только его, но и все виртуальные машины.




    Все чаще и чаще вендоры выпускают свою документацию по настройке как самой системы так и руководства класса «Hardening/Security Guide». Компания Citrix выпустила документы Common Criteria Security Target и User Security Guide. Данные документы имеют ряд рекомендаций и советов, но имеют слишком мало практической информации. В документации по CCST вы можете найти формальное описание объекта защиты и ряд практических настроек. В User Security компания описала общую методологию защиты системы. Таким образом, полноценный Security Guide от Citrix, который полностью бы охватывал все аспекты, к сожалению, отсутствует.

    В 2011 году компания Citrix получила звание Security Organization of the Year от ISSA. Особо подчеркивалось, что к продуктам Citrix применим термин «Secured By Design». Возможно, некоторые решения от этой компании и можно отнести к данной категории, но исследование их серверных продуктов XenServer показали наличие некоторой специфики их дизайна и своеобразие трактовки данного термина группой специалистов Citrix. В нашей статье мы познакомимся с некоторыми аспектами эксплуатации Citrix Free XenServer 5.6.0 и проблемами безопасности, которые возможно могут возникнуть при практическом использовании данной системы. Выбор конкретно данной версии обусловлен довольно большой распространенностью и известностью. Многое из сказанного далее не претерпело никаких изменений в версиях 6-го семейства.

    Основой всего гипервизора является XenAPI (XAPI). Это демон, выполняемый системой с правами суперпользователя и обеспечивающий интерфейс управления самой системой и виртуальными машинами. Будучи прямым родственником операционной системы Red Hat Enterprise Linux гипервизор унаследовал ряд стандартных решений от прародителя. Таковым является модуль PAM, отвечающий за подключение к XAPI.

    Данный модуль по умолчанию настроен на полный include стандартных настроек из system-auth. На практике же это значит, что любой пользователь, имеющий учетную запись в системе, может исполнять запросы XAPI с правами pool-admin за исключением смены пароля root средствами API. Данная особенность системы является документированной и присуща версиям Free и Advance. По политике компании Citrix при использовании данных вариантов XenServer вы имеете системы с «единым уровнем» пользователя, — LSU (Local Super User). Данное решение компании Citrix представляется сомнительным в рамках идеологии построения продуктов уровня Enterprise в ее общественном понимании.

    Данная специфика создает некоторые проблемы в рамкам использования гипервизора как многопользовательской системы. Для создания разграничений надо скорректировать настройки PAM модуля xapi таким образом, что бы ограничить круг лиц, допущенных до управления гипервизором. Возможностей для этого великое множество, в вашем распоряжении все стандартные средства PAM. Описание возможностей PAM и идеи для конфигурирования защиты XAPI вы можете подчерпнуть из “The Linux-PAM System Administrators Guide” от Andrew G.Mortan и Thorsten Kukuk.

    Еще одной спецификой XAPI является наличие в системе возможности удаленного управления по HTTP/HTTPS. Демон держит открытыми 80 и 443 порты на административном интерфейсе. В рамках этой статьи мы не будем рассматривать многоинтерфейсные системы, там эта проблема стоит чуть менее остро, учитывая возможность физического отделения сети управления. Но хотелось бы отметить, что данная компоновка необходима для любого production-решения.



    Довольно часто, административный интерфейс является и общим для передачи данных и каскадирования виртуальных машин. Таким образом, любое управление по 80-му порту без использования SSL тоннелей дает возможность злоумышленнику как минимум использовать сниффер и получить настройки системы, а как максимум провести успешную инъекцию кода или перехватить сессию управления. Как вариант решения, Iptables оптимален. В целом же, стоит ограничить трафик, поступающий на 80\443 порты в системе. Достойно этот вопрос освещен в собственном документе компании Citrix Common Criteria Evaluated Configuration Guide for Citrix XenServer 5.6, Platinum Edition.
    Для разъяснения следующего вызывающего вопросы места, погрузимся чуть глубже в моторику работы Citrix XenServer. Для удобства доступа к виртуальными машинам гипервизор использует передачу текстовых\графических консолей гостевых систем на XAPI. Для этого используется небольшая программка vncterm. Идеология работы примерно следующая: При запросе консоли средствами XAPI создается форк процесса vncterm на loopback интерфейсе и передается на XAPI пользователю.



    Так происходит с любыми хостами, включая сам хост гипервизора. За небольшим исключением. В случае подключения на хост гипервизора, вместо отправки на аутентификацию, выполняется авторский код компании Citrix, предоставляющий вам мгновенный доступ к локальной консоли под пользователем root.



    Любой пользователь, имеющий доступ на XAPI на сервере без привязки к Active Directory сможет получить root доступ на хост гипервизора.

    Как вторичную проблему vncterm отметим единую для всех сессию. То есть, создав сессию на гостевую систему под пользователем root и забыв произвести выход из гостевой системы, вы оставите открытый VNC канал. При следующем запросе к данной гостевой системе любой пользователь XAPI получит ту самую открытую сессию. Компрометация системы неизбежна. Отметим, что локальная аутентификация пользователя так же происходит автоматически на mingetty –autologin root с автоматической загрузкой xsconsole.



    Это не является критичным, но теоретически возможна инъекция sh кода. Поэтому следует ограничить выдачу привилегий суперпользователя в системе.

    Еще одним проблемным местом системы является трансфер виртуальных машин между серверами в режиме XenMotion. Он происходит через 80-й порт системы в plain-text режиме. Таким образом, злоумышленник имеет возможность перехвата данных «на лету». Решение этой проблемы только одно, — применения средств шифрования IP уровня. Но это не единственная проблема при передачи данных,- так же по умолчанию сервис iSCSI передает учетные данные в открытом виде. Данная проблема решается активацией CHAP.

    Citrix XenServer использует несколько режимов хранения виртуальных машин: в виде LVM и в виде VHD файлов. в виде LVM разделов или отдельных файлов. Первый режим можно расценивать как условно-безопасный, так как права на монтирование разделов имеет только суперпользователь. А вот режим VHD хранения в виде отдельных файлов представляет собой очередную проблему безопасности. Файл создается со стандартным umask из скриптов сервера: rw-r-r. Таким образом, виртуальная машина доступна любому пользователю системы. Эта проблема решается методом исправления скриптов, который будет описан в Positive Technologies Citrix XenServer 5.6 Security Guide.

    Так как системы является потомком RHEL, то она унаследовала их систему менеджмента пакетов RPM вместе с надстройкой yum. Изначально в системе, при попытке тривиального “yum update” вы не получите обновлений систем. Хотя явственно ощущаете, что за красивой заставкой спрятался динозавр линуксостроения. Проблема заключается в том, что компания Citrix блокирует подключение к репозиториям CentOS на уровне конфигурации yum. Конечно, не является проблемой включить их обратно и выполнить обновление системы. Но данное действие приведет к досрочному упокоению гипервизора из-за того, что Citrix изменили некоторые стандартные вещи в системе на свои, «религиозно-верные», и теперь накатывание обновлений приводит к краху системы. Так как некоторые пакеты в системе определяются сканером безопасности как имеющие уязвимости уровня “critical” (dhclient к примеру), то установка обновлений становится обязательной. Для решения подобных проблем вам потребуется сканер безопасности, yum, dump и терпение.

    Хотелось бы отметить, что из общих настроек системы «из коробки» присутствует важная промашка в настройках модуля pam_unix.so. Конкретнее, у него не включен режим хранения паролей в /etc/shadow.
    Таким образом, учитывая стандартные права на файле /etc/passwd есть потенциальный доступ к хэшам паролей системы. Так же это и касается моторики работы системы с NFS хранилищами. Citrix XenServer Administration Guide рекомендует выставление на NFS сервере опции no_root_squash. Такое решение является стандартным для гипервизоров, и следует максимально изолировать такое хранилище от внешнего мира, используя средства iptables или подобные. Дополнительно, конечно, следует скорректировать режимы создания файлов и произвести ремаппинг root пользователя на специализированного пользователя системы.

    Таким образом, подводя итог в целом, получается что продукт Citrix Free XenServer в исходной настройке имеет несколько возможных серьезных проблем безопасности «by design». Многие из них являются общими проблемами для RHEL семейства, другие же являются уникальными для данной системы. Конечно, с точки зрения Citrix, это не проблемы, а особенности архитектуры их гипервизора. Решение вопросов безопасности и общая методология защиты данной ОС будут представлены в документе Positive Technologies: Citrix XenServer Security Guide, который в ближайшем будущем выйдет в открытое бета-тестирование.
    Positive Technologies
    113,88
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 59

      +2
      Пока что я вижу, только «пользователь, имеющий учётку на системе с гипервизором, автоматически получает права администрирования». Внимание, вопрос. На кой чёрт вам в Dom-0 понадобилось больше одного пользователя?
        0
        При администрировании системы бывает ситуация, что администрирование производится силами нескольких человек. Для этого целесообразно создание нескольких учетных записей с различными правами доступа.
          –1
          Ну тогда пишите заодно про 0-day уязвимости ядра Linux и утилит с suid-битом, они тоже позволяют рутовые права получить.
            0
            По моему мнению ситуация с пользователями важна в рамках контекста позиционирования системы как «Enterprise» решения.
              +2
              Энетрпрайз версии Citrix Xen идут уже с нормально настроенной безопасностью / авторизацией.

              Free — на то и free, чтобы настраивать :) Это скорее некий конструктор.
                0
                Да.
                Там используется привязка к AD через Likewise.
                Довольно неплохое решение, которое позволяет разделить привилегии.
                Аспекты же работы остальной моторики остаются такие же.
                К примеру, — перехват vncterm сессии реален.
        –2
        Подкиньте что-ли статейку для чего оно нужно.
          +2
          Хорошая статья, но большинство из приведенных «уязвимостей», на мой взгляд, не настолько критичны (кроме, пожалуй, устаревших пакетов).

          Еще одним проблемным местом системы является трансфер виртуальных машин между серверами в режиме XenMotion. Он происходит через 80-й порт системы в plain-text режиме. Таким образом, злоумышленник имеет возможность перехвата данных «на лету». Решение этой проблемы только одно, — применения средств шифрования IP уровня. Но это не единственная проблема при передачи данных,- так же по умолчанию сервис iSCSI передает учетные данные в открытом виде.

          Это справедливо в отношении всех гипервизоров, ни ESXi, ни Hyper-V не шифруют трафик при vMotion/Live Migration. По этой причине крайне рекомендуется для этих целей использовать отдельные сетевые адаптеры или хотя бы изолировать трафик в отдельных VLAN'ах. То же касается iSCSI, ведь CHAP не защитит от прослушивания.

          Что касается совместного использования ресурсов гипервизора несколькими людьми без необходимости давать им доступ непосредственно к консоли, то в этом случае может пригодиться Self Service Portal.
            +3
            На фразе «Основой всего гипервизора является XenAPI (XAPI)» автора можно уносить и больше не слушать.

            Основой всего гиперизора является файлик /boot/xen.gz (и его точные именования). xapi — всего лишь демон управления, который никак не может быть основой гипервизора.

            Человек, который способен назвать верхушку тулстека гипервизором очевидно не разбирается в теме, про которую пишет.
              0
              Я не ставил целью описание «низов» гипервизора.
                –1
                Ну это всё равно, как бы мы обсуждали автомобили, и вы бы написали «жёсткая спортивная подвеска, являющаяся частью 200-сильного двигателя, показывает себя не очень».
                  +1
                  Вся статья идет в рамках описания end-user системы.
                  А не с точки зрения полной моторики работы автомобиля.
                  Я говорю, что для водителя главное: руль.
                  Вы же, имея компетенцию автомеханика, утверждаете что главное в автомобиле это двигатель.
                    0
                    Так говорите «руль».

                    Пожалуйста, не отстаивайте своё право на профанство. Если вы его отстоите, то и экспириенс вам нужно будет описывать примерно так «ну там какая-то кнопочка, если её нажать непонятно что происходит».

                    Либо мы говорим о сути происходящего c профессиональной точки зрения (используя при этом осмысленные термины), либо мы говорим про послушного пользователя, который выполнил все рекомендации цитрикса (например, закрыл management-сеть полностью) и выполняет действия с машинами через XenCenter.
                      +1
                      Уважаемый amorao, в контексте блога «Информационная безопасность» и освещения проблемы безопасности в базовых сервисах Citrix XenServer без глубокого погружения в систему я считаю целесообразным считать основным управляющим элементом API системы, так как я не затрагиваю более глубокий слой.
              0
              Я решил дочитать.

              Чушь! Абсолютная.

              При запросе консоли средствами XAPI создается форк процесса vncterm на loopback интерфейсе и передается на XAPI пользователю.

              vncterm форкается для для каждого нового домена на виртуальной машине (вы сырцы читали вообще, перед тем, как всё это писать?), точнее, он форкается для всех виртуальных машин, у которых в other-config не выставлено disable_pv_vnc. vncterm форкается вне зависимости от того, были ли запрошены консоли, его задача — эмулировать эмулятор терминала, читая данные из pts, созданного xenconsoled. Если бы vncterm форкался в момент запроса консоли, то всё предыдущее состояние экрана бы терялось (и вы бы чаще всего видели пустой чёрный экран).
                0
                Далее по тексту написано:

                То есть, создав сессию на гостевую систему под пользователем root и забыв произвести выход из гостевой системы, вы оставите открытый VNC канал. При следующем запросе к данной гостевой системе любой пользователь XAPI получит ту самую открытую сессию.

                Если есть открытый vncterm, то апи переключит на него.
                  +1
                  Я не вижу в этом узявимости.

                  «Если пользователь оставит сессию root на локальной консоли сервера и отключит монитор, то любой, подключившийся к этой консоли, получит ту самую открытую сессию».

                  Это терминал. Эмуляция того, куда монитор подоткнут. И его поведение тщательно соответствует поведению терминала.

                  А вообще, «логин рутом с консоли» — это половые проблемы гостевой машины. Не хотите разрешать логин? Убирайте из /etc/securetty. Или вообще из inittab'а. Это просто последовательный порт, и ведёт он себя ровно так же, как любой другой последовательный порт.

                    0
                    Я считаю небезопасным данное:

                    Так происходит с любыми хостами, включая сам хост гипервизора. За небольшим исключением. В случае подключения на хост гипервизора, вместо отправки на аутентификацию, выполняется авторский код компании Citrix, предоставляющий вам мгновенный доступ к локальной консоли под пользователем root.

                    Это проблема номер раз. Почему любой пришедший получает доступ на рута? Все равны?

                    По поводу брошенных сессий: Я считаю небезопасным передачу сессий одного пользователя другому без преверки.
                      0
                      Погодите. У вас какая-то феерическая каша в голове и терминология, из-за которой я просто не понимаю, о чём вы.

                      xsconsole, который слушает в dom0, не даёт вам доступа дальше, чем «посмотреть IP/имя». Дальше он спрашивает пароль.

                      Более того, если вы выйдите в шелл (есть там опция такая), то по таймауту шел завершится и снова будет на консоли xsconsole. Как раз в этом смысле всё сделано очень грамотно.

                      Таким образом я не понимаю про какое «получить рута» вы говорите.

                      Далее. Почему кто-либо имеет право запросить консоль для control domain'а какого-либо хоста? Либо у человека рут, и от него это прятать бесполезно, либо у вас настроенная аутоидентификация и запрашивать консоль от Control Domain'ов вам никто не даст (так же как не даст выполнять любые операции с хостами).

                      Давайте-ка вы разберётесь, как там всё это устроено, а после этого мы сможем поговорить более спокойно. Пока что у меня ощущение, что нужно читать лекцию на несколько часов про то, как работает зен, что такое /dev/xvc0, чем она отличается от /dev/ttyS0 и /dev/tty0.
                        0
                        Давайте попробуем еще раз.
                        Речь идет не о xsconsole в данной ветке.
                        Речь о vncterm и его сессии для dom0.

                        При том, что xapi через pam забирает стандартные условия, любой добавочный юзер в системе может подключиться по ssh на систему и подцепиться на vncterm для dom0 под пользователем root.
                          0
                          Ок, vncterm для dom0 запускается в dom0, читает (через /dev/pts) паравиртуализированную консоль dom0 (/dev/xvc0), на которой запущен xsconsole. Так?

                          Если нет, говорите что не так, будем выяснять, что кто где перепутал.
                            +2
                            Дико извиняюсь конечно, виртуала будет доступна в рабочее время.
                            Буду по памяти.

                            При открытии vncterm для dom0 на исполнение уходит exec /bin/login -f root
                            Если я правильно помню, она это и исполняет. Выдавая пользователю шелл.

                            Для простой проверки, если есть доступный хост, подключить к нему Xen-центром и откройте консоль сервера. К сожалению, я данную операцию сейчас проделать не могу.

                            Полноценный комментарий по данному вопросу я дам завтра в рабочее время.
                              0
                              А вот тут я внезапно, кстати, неправ. На /dev/xvc0 в dom0 действительно логин, а не xsconsole. Странно, нафига они это делали?

                              PS Мы XenCeter не юзаем, ибо он под винду и проприентарное говно.

                              Самурайский метод:

                              xvncviewer -via root@xenhost localhost:5900

                              В любом случае, если у вас есть админский доступ в xenserver (то есть вы можете делать там что угодно), то наличие консоли с рутом ситуацию хуже не делает.

                              А если есть ограниченный доступ, то у клиента просто не должно быть никаких прав на control domain или логин в dom0.
                                0
                                Спасибо, что потрудились проверить.
                                Как и описано в тексте, мне кажется сомнительным возможность подключения любого пользователя системы на данный vncterm.
                                  0
                                  Я понял суть проблемы. Вам кажется, что посторонние пользователи должны иметь возможность логиниться в dom0. Это не так.

                                  Никакой пользователь системы, кроме root, не должен иметь возможность исполнять свой код в dom0. Если в системе есть какие-то дополнительные пользователи, то они должны иметь шеллом /bin/false (true, date — по выбору).
                                    0
                                    Я солидарен с вашим мнением.
                                    Но данный аспект не является очевидным для рядовых пользователей XenServer.
                                    При создании дополнительных пользователей в системе (второй администратор, итд) они рискуют потерять root запись.
                                    Это произойдет из-за того, что любой пользователь системы, удовлетворивший pam условие xapi сможет подключиться на root шелл через vncterm без проверки пароля.
                                      0
                                      Я никогда не возился с авторизацией в xenserver, однако, вопрос в том, сможет ли пользователь с ролью vm-operator получить этот доступ.

                                      Если нет — вопроса нет. Если может — можно открывать SA. Заметим, что добавление чего-либо вручную в /etc/passwd — это явное «low-level ковыряние в xenserver» (одного класса с раскомментированием репозиториев yum) и в этом смысле не отличается от установки своих сервисов и прочей самодеятельности.

                                      Лично я уверен, что никто, кроме pool-operator и pool-admin этих прав не имеют.
                                        0
                                        В статье обозначен продукт XenServer Free 5.6
                                        По лицензии, в нем нет разделения на роли.
                                        Проблма vncterm актуальна в том случае, если пользователь имеет логин в системе dom0.
                                          0
                                          Так не должно быть других пользователей в системе. Собственно, на этом можно ставить точку. Посмотрите на /etc/passwd — ни одного открытого аккаунта.

                                          Впрочем, по поводу слушающего на /dev/xvc0 я вопрос в рассылку задал, посмотрим, что ответят.
                                            0
                                            Возможно я и не прав, но я не заметил нигде рекомендации не заводить дополнительных пользователей в документации цитрикс. В нерабочее время проверить хлопотно.

                                            Поэтому данный вопрос и был освещен. Для того, что бы end-user воздержался от данных действий.
                                              0
                                              Тыкать в мануал не буду (я всё больше по исходникам шарюсь), но я 100% гарантирую, что _любые_ изменения в dom0, сделанные не через xe/XenAPI будут злобным хакингом и нарушением целостности предустановленной системы.

                                              Более того, я не уверен, что /etc/passwd не будет перезаписан при первом же чихе xapi.

                                              Даже невинный xe-toolstack-restart может привести к проблемам, а вы ставите на уши систему авторизации xapi, а потом говорите " а она на ушах стоит".

                                              (Вопроса с «какого хрена без пароля консоль» это не снимает и я с интересом жду ответа в рассылке).
                                                0
                                                Исследование данного вопроса актуально, так как при наличии уязвимости во второстепенных сервисах, приводящих к получению частичного доступа к системе может привести к полной потери dom0 именно из-за это «незапароленной консоли».
                                                  0
                                                  Каких, например? Предлагаю простой тест — заменяем любой воторостепенный сервис, работающий не из-под root'а на простенький телнет-сервер на связке bash'а и nc, и пробуем вызвать его (то есть спровоцировать уязвимость).

                                                  Заглянул в боевой dom0, там из «не рута» только ntp и portmap rpc'ный. portmap только на -l слушает (то есть дырки в нём никому не доступны), а ntpd слушает только на management интерфейсе, то есть опять же, снаружи не доступен.
                                                    0
                                                    Я не проводил исследования уязвимостей сервисов XenServer.
                                                    Пример постараюсь привести вам завтра, когда доберусь до рабочей виртуалки.
                +2
                Не, это просто феерия профанства.

                Citrix XenServer использует несколько режимов хранения виртуальных машин: в виде LVM и в виде VHD файлов.

                Все SR у цитрикса (кроме HBA) используют VHD формат. В случае SR LVM и LVMoISCSI VHD хранится внутри LVM (неужели вы ни разу не читали кода /opt/xensource/sm? А /var/log/SMlog?). Существует (полудокументированная) возможность неиспользовать VHD, это делается передачей в device-config при создании SR'а опции type=raw.
                  +1
                  Извиняюсь, видимо не достаточно явно отметил что имеется ввиду отличии хранения в виде «файлов» и в виде LVM. Имелось ввиду представление.
                    0
                    LVM и VHD просто не должны писаться через запятую. VHD — это слой, предоставляющий всякие вкусности, класса thin provision, intellicache'а, обеспечивающий COW-защиту данных от предыдущего клиента (новый не сможет прочитать чужое), снапшоты и т.д.

                    А LVM — это один из промежуточных слоёв, использующийся разными SR'ами для управления VDI'ями.

                    Кстати, относительно патчей. Сильно пропатчены у цитрикса три пакета — udev, hotplug и lvm2. И да, их нельзя обновлять из центоса, а надо обновлять из репозитория цитрикса. Почему? Потому что вся вкусность shared SR для lvmoiscsi реализована именно за счёт глубокого и сильного изменения логики работы LVM, который теперь начинает понимать ключ --master.
                  0
                  Спасибо за разъяснение.
                  Как я уже и сказал, я ошибся в терминах описания способ хранения виртуальных машин.
                  Но проблема прав доступа остается тем не менее актуальной.
                    0
                    Минорные редакции XenServer'а не подразумевают наличие разных прав доступа к management'у. Старшие — позволяют настроить по своему усмотрению.

                      0
                      Пожалуйста, чуть внимательнее читайте.

                      В тексте было сказано:
                      Файл создается со стандартным umask из скриптов сервера: rw-r-r.

                      Хранение виртуальной машины с правами rw-r-r является небезопасным.
                        0
                        Я вас просто не могу читать.

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

                        Какие директории для LVM? В каком месте я должен начать воспринимать вас серьёзно?
                          0
                          Спасибо, опечатка.

                          Пожалуйста, выскажитесь насчет тезиса:

                          Файл создается со стандартным umask из скриптов сервера: rw-r-r.
                          Хранение виртуальной машины с правами rw-r-r является небезопасным.
                            0
                            Как только у вас кто-то посторонний сумел залогиниться в dom0, то система скомпрометирована.

                            А про какой SR вы говорите? file? nfs? ext?
                              0
                              Факт.
                              Речиь идет в основном о удаленных хранилищах NFS.
                                0
                                А, ну так это всё строится на концепции изоляции dom0.

                                Кстати, я немного не понял вашего исследования. В системе нет ни одного пользователя, который бы имел право зайти в неё, кроме root'а.

                                Более того, я пока не могу объяснить причину, но попытка запустить из-под root'а login приводит к закрытию ssh-сессии.
                                  0
                                  Я по тексту и написал, что или изолируйте сети, или же будут данные проблемы.
                                  Проблемы же прав доступа решаются незначительными изменениями в скрипте.

                                  Разговор о добавленных конечным пользователем пользователях.
                                    0
                                    Так не должно быть таких! Если вы штатными средствами пустили в dom0 пользователя, у которого нет прав уровня root для dom0, всё, считайте, вы нашли дыру. Если же для этого нужно руками в конфигах его прописывать — это не дыра, а глупый хак.
                                      0
                                      Сделайте useradd testuser и зайдите под ним в систему.
                                      Из под этого пользователя уже будет можно получить root через vncterm.
                                        0
                                        Стоп. А кто вам это разрешил делать?

                                        С тем же успехом вы можете поменять конфиг vnc так, чтобы он слушал не на lo, а потом говорить «уязвимость».

                                        Нельзя никаких пользователей в dom0 добавлять.

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

                                        А до этого момента это всё равно что сказать «а вот если я ключик руту в каталог положу, а потом приватную часть на http сервере отдавать всем буду, то это будет уязвимость».
                                          0
                                          Выше ответил.
                                          Я не видел запрета на такие действия, и как раз предлагаю их не совершать.
                                0
                                Опять же, по памяти: файловый SR создастся с такими же правами.
                                  0
                                  Да, проверил файловый, именно так. Вопросом является только то, откуда вы решили, что хоть кто-то будет иметь доступ в dom0.
                                    0
                                    Спасибо за уделенное на проверку время.
                                    В случае получения такового через уязвимости доступ к виртуальным машинам облегчен.
                                    Я считаю это небезопасным решением.

                                    При таких правах на файл при использовании удаленного хранилища мне видится сомнительным безопасность файлов виртуальных машин. Любой пользователь данного хранилища будет иметь к ним доступ.
                                      0
                                      Ну вот тут вы уже начинаете ерунду говорить. Я имею в виду, что «пользователь хранилища» это какой-то нонсенс. Разумеется, на хранилище нет никаких лишних пользователей, если вы в SAN пустили хоть кого-то, то всё, можно уносить готового.

                                      То есть, я хочу сказать, что это «уязвимость» одного уровня с возможностью получить доступ к конфигу iscsi target (и прочитать там chap password). После того, как злоумышленник оказывается на хранилищах СХД, говорить о дальнейших нюансах безопасности имеет смысла не больше, чем обсуждать влияние на причёску проехавшего по голове танка.
                                        0
                                        Речь об NFS хранилище.
                                        К примеру, у нас есть NFS на котором гипервизор хранит виртуальные машины.
                                        Так же есть, к примеру, ftp на котором удаленный сторедж тот же NFS.
                                        Нужно ли, что бы любой пользователь данного NFS хранилища имел доступ к файлам виртуальных машин?
                                          0
                                          Стоп. Всё, нарушение best practicie, кто-то имеет доступ к СХД.

                                          Напомню, что в nfs авторизация по IP, так что если кто-то может прислать что-либо nfs-серверу, значит, он может выдать себя за добросовестный сервер, значит тут говорить не о чем.

                                          СХД зена должна быть 100% изолирована от окружающего мира.
                                            0
                                            Да, о чем и написано в начале статьи.

                                            В NFS авторизация по айпи. При наличии уязвимости во второстепенных сервисах хоста NFS возможно получение доступа к файловой системе на уровне пользователя уязвимого сервиса. При начальных настройках, будет получен доступ к всем виртуальным машинам.

                                            При наличии возможности исправления прав на более «жесткие» я считаю целесообразным внести данные изменения в скрипт.
                                              0
                                              Э… Вы в курсе, что зен советует делать no_root_squash для шары? Это означает, что подделавший IP может просто прийти с ID 0 и настрать на права.

                                              То есть опять вы про причёску после танка. Проблема большая — не должен никто приходить по NFS, кроме хостов. Сеть не защищённая, трафик по ней свободно ходит. Мораль: изоляция этой сети от всех остальных. Намертво.

                                              У нас, например, эта сеть даже маршрутизации не имеет. Стоит себе коммутатор без аплинков.
                                                0
                                                Я написал про это в статьи, если вы не заметили. Вариант решения так же.

                                                Повторюсь еще раз. При наличии изолированной сети, данная проблема не актуальна. Мы рассматриваем случай не разделенных сетей.

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

                    Самое читаемое