Comments 59
Пока что я вижу, только «пользователь, имеющий учётку на системе с гипервизором, автоматически получает права администрирования». Внимание, вопрос. На кой чёрт вам в Dom-0 понадобилось больше одного пользователя?
При администрировании системы бывает ситуация, что администрирование производится силами нескольких человек. Для этого целесообразно создание нескольких учетных записей с различными правами доступа.
Ну тогда пишите заодно про 0-day уязвимости ядра Linux и утилит с suid-битом, они тоже позволяют рутовые права получить.
Подкиньте что-ли статейку для чего оно нужно.
Хорошая статья, но большинство из приведенных «уязвимостей», на мой взгляд, не настолько критичны (кроме, пожалуй, устаревших пакетов).
Это справедливо в отношении всех гипервизоров, ни ESXi, ни Hyper-V не шифруют трафик при vMotion/Live Migration. По этой причине крайне рекомендуется для этих целей использовать отдельные сетевые адаптеры или хотя бы изолировать трафик в отдельных VLAN'ах. То же касается iSCSI, ведь CHAP не защитит от прослушивания.
Что касается совместного использования ресурсов гипервизора несколькими людьми без необходимости давать им доступ непосредственно к консоли, то в этом случае может пригодиться Self Service Portal.
Еще одним проблемным местом системы является трансфер виртуальных машин между серверами в режиме XenMotion. Он происходит через 80-й порт системы в plain-text режиме. Таким образом, злоумышленник имеет возможность перехвата данных «на лету». Решение этой проблемы только одно, — применения средств шифрования IP уровня. Но это не единственная проблема при передачи данных,- так же по умолчанию сервис iSCSI передает учетные данные в открытом виде.
Это справедливо в отношении всех гипервизоров, ни ESXi, ни Hyper-V не шифруют трафик при vMotion/Live Migration. По этой причине крайне рекомендуется для этих целей использовать отдельные сетевые адаптеры или хотя бы изолировать трафик в отдельных VLAN'ах. То же касается iSCSI, ведь CHAP не защитит от прослушивания.
Что касается совместного использования ресурсов гипервизора несколькими людьми без необходимости давать им доступ непосредственно к консоли, то в этом случае может пригодиться Self Service Portal.
На фразе «Основой всего гипервизора является XenAPI (XAPI)» автора можно уносить и больше не слушать.
Основой всего гиперизора является файлик /boot/xen.gz (и его точные именования). xapi — всего лишь демон управления, который никак не может быть основой гипервизора.
Человек, который способен назвать верхушку тулстека гипервизором очевидно не разбирается в теме, про которую пишет.
Основой всего гиперизора является файлик /boot/xen.gz (и его точные именования). xapi — всего лишь демон управления, который никак не может быть основой гипервизора.
Человек, который способен назвать верхушку тулстека гипервизором очевидно не разбирается в теме, про которую пишет.
Я не ставил целью описание «низов» гипервизора.
Ну это всё равно, как бы мы обсуждали автомобили, и вы бы написали «жёсткая спортивная подвеска, являющаяся частью 200-сильного двигателя, показывает себя не очень».
Вся статья идет в рамках описания end-user системы.
А не с точки зрения полной моторики работы автомобиля.
Я говорю, что для водителя главное: руль.
Вы же, имея компетенцию автомеханика, утверждаете что главное в автомобиле это двигатель.
А не с точки зрения полной моторики работы автомобиля.
Я говорю, что для водителя главное: руль.
Вы же, имея компетенцию автомеханика, утверждаете что главное в автомобиле это двигатель.
Так говорите «руль».
Пожалуйста, не отстаивайте своё право на профанство. Если вы его отстоите, то и экспириенс вам нужно будет описывать примерно так «ну там какая-то кнопочка, если её нажать непонятно что происходит».
Либо мы говорим о сути происходящего c профессиональной точки зрения (используя при этом осмысленные термины), либо мы говорим про послушного пользователя, который выполнил все рекомендации цитрикса (например, закрыл management-сеть полностью) и выполняет действия с машинами через XenCenter.
Пожалуйста, не отстаивайте своё право на профанство. Если вы его отстоите, то и экспириенс вам нужно будет описывать примерно так «ну там какая-то кнопочка, если её нажать непонятно что происходит».
Либо мы говорим о сути происходящего c профессиональной точки зрения (используя при этом осмысленные термины), либо мы говорим про послушного пользователя, который выполнил все рекомендации цитрикса (например, закрыл management-сеть полностью) и выполняет действия с машинами через XenCenter.
Я решил дочитать.
Чушь! Абсолютная.
При запросе консоли средствами XAPI создается форк процесса vncterm на loopback интерфейсе и передается на XAPI пользователю.
vncterm форкается для для каждого нового домена на виртуальной машине (вы сырцы читали вообще, перед тем, как всё это писать?), точнее, он форкается для всех виртуальных машин, у которых в other-config не выставлено disable_pv_vnc. vncterm форкается вне зависимости от того, были ли запрошены консоли, его задача — эмулировать эмулятор терминала, читая данные из pts, созданного xenconsoled. Если бы vncterm форкался в момент запроса консоли, то всё предыдущее состояние экрана бы терялось (и вы бы чаще всего видели пустой чёрный экран).
Чушь! Абсолютная.
При запросе консоли средствами XAPI создается форк процесса vncterm на loopback интерфейсе и передается на XAPI пользователю.
vncterm форкается для для каждого нового домена на виртуальной машине (вы сырцы читали вообще, перед тем, как всё это писать?), точнее, он форкается для всех виртуальных машин, у которых в other-config не выставлено disable_pv_vnc. vncterm форкается вне зависимости от того, были ли запрошены консоли, его задача — эмулировать эмулятор терминала, читая данные из pts, созданного xenconsoled. Если бы vncterm форкался в момент запроса консоли, то всё предыдущее состояние экрана бы терялось (и вы бы чаще всего видели пустой чёрный экран).
Далее по тексту написано:
То есть, создав сессию на гостевую систему под пользователем root и забыв произвести выход из гостевой системы, вы оставите открытый VNC канал. При следующем запросе к данной гостевой системе любой пользователь XAPI получит ту самую открытую сессию.
Если есть открытый vncterm, то апи переключит на него.
То есть, создав сессию на гостевую систему под пользователем root и забыв произвести выход из гостевой системы, вы оставите открытый VNC канал. При следующем запросе к данной гостевой системе любой пользователь XAPI получит ту самую открытую сессию.
Если есть открытый vncterm, то апи переключит на него.
Я не вижу в этом узявимости.
«Если пользователь оставит сессию root на локальной консоли сервера и отключит монитор, то любой, подключившийся к этой консоли, получит ту самую открытую сессию».
Это терминал. Эмуляция того, куда монитор подоткнут. И его поведение тщательно соответствует поведению терминала.
А вообще, «логин рутом с консоли» — это половые проблемы гостевой машины. Не хотите разрешать логин? Убирайте из /etc/securetty. Или вообще из inittab'а. Это просто последовательный порт, и ведёт он себя ровно так же, как любой другой последовательный порт.
«Если пользователь оставит сессию root на локальной консоли сервера и отключит монитор, то любой, подключившийся к этой консоли, получит ту самую открытую сессию».
Это терминал. Эмуляция того, куда монитор подоткнут. И его поведение тщательно соответствует поведению терминала.
А вообще, «логин рутом с консоли» — это половые проблемы гостевой машины. Не хотите разрешать логин? Убирайте из /etc/securetty. Или вообще из inittab'а. Это просто последовательный порт, и ведёт он себя ровно так же, как любой другой последовательный порт.
Я считаю небезопасным данное:
Так происходит с любыми хостами, включая сам хост гипервизора. За небольшим исключением. В случае подключения на хост гипервизора, вместо отправки на аутентификацию, выполняется авторский код компании Citrix, предоставляющий вам мгновенный доступ к локальной консоли под пользователем root.
Это проблема номер раз. Почему любой пришедший получает доступ на рута? Все равны?
По поводу брошенных сессий: Я считаю небезопасным передачу сессий одного пользователя другому без преверки.
Так происходит с любыми хостами, включая сам хост гипервизора. За небольшим исключением. В случае подключения на хост гипервизора, вместо отправки на аутентификацию, выполняется авторский код компании Citrix, предоставляющий вам мгновенный доступ к локальной консоли под пользователем root.
Это проблема номер раз. Почему любой пришедший получает доступ на рута? Все равны?
По поводу брошенных сессий: Я считаю небезопасным передачу сессий одного пользователя другому без преверки.
Погодите. У вас какая-то феерическая каша в голове и терминология, из-за которой я просто не понимаю, о чём вы.
xsconsole, который слушает в dom0, не даёт вам доступа дальше, чем «посмотреть IP/имя». Дальше он спрашивает пароль.
Более того, если вы выйдите в шелл (есть там опция такая), то по таймауту шел завершится и снова будет на консоли xsconsole. Как раз в этом смысле всё сделано очень грамотно.
Таким образом я не понимаю про какое «получить рута» вы говорите.
Далее. Почему кто-либо имеет право запросить консоль для control domain'а какого-либо хоста? Либо у человека рут, и от него это прятать бесполезно, либо у вас настроенная аутоидентификация и запрашивать консоль от Control Domain'ов вам никто не даст (так же как не даст выполнять любые операции с хостами).
Давайте-ка вы разберётесь, как там всё это устроено, а после этого мы сможем поговорить более спокойно. Пока что у меня ощущение, что нужно читать лекцию на несколько часов про то, как работает зен, что такое /dev/xvc0, чем она отличается от /dev/ttyS0 и /dev/tty0.
xsconsole, который слушает в dom0, не даёт вам доступа дальше, чем «посмотреть IP/имя». Дальше он спрашивает пароль.
Более того, если вы выйдите в шелл (есть там опция такая), то по таймауту шел завершится и снова будет на консоли xsconsole. Как раз в этом смысле всё сделано очень грамотно.
Таким образом я не понимаю про какое «получить рута» вы говорите.
Далее. Почему кто-либо имеет право запросить консоль для control domain'а какого-либо хоста? Либо у человека рут, и от него это прятать бесполезно, либо у вас настроенная аутоидентификация и запрашивать консоль от Control Domain'ов вам никто не даст (так же как не даст выполнять любые операции с хостами).
Давайте-ка вы разберётесь, как там всё это устроено, а после этого мы сможем поговорить более спокойно. Пока что у меня ощущение, что нужно читать лекцию на несколько часов про то, как работает зен, что такое /dev/xvc0, чем она отличается от /dev/ttyS0 и /dev/tty0.
Давайте попробуем еще раз.
Речь идет не о xsconsole в данной ветке.
Речь о vncterm и его сессии для dom0.
При том, что xapi через pam забирает стандартные условия, любой добавочный юзер в системе может подключиться по ssh на систему и подцепиться на vncterm для dom0 под пользователем root.
Речь идет не о xsconsole в данной ветке.
Речь о vncterm и его сессии для dom0.
При том, что xapi через pam забирает стандартные условия, любой добавочный юзер в системе может подключиться по ssh на систему и подцепиться на vncterm для dom0 под пользователем root.
Ок, vncterm для dom0 запускается в dom0, читает (через /dev/pts) паравиртуализированную консоль dom0 (/dev/xvc0), на которой запущен xsconsole. Так?
Если нет, говорите что не так, будем выяснять, что кто где перепутал.
Если нет, говорите что не так, будем выяснять, что кто где перепутал.
Дико извиняюсь конечно, виртуала будет доступна в рабочее время.
Буду по памяти.
При открытии vncterm для dom0 на исполнение уходит exec /bin/login -f root
Если я правильно помню, она это и исполняет. Выдавая пользователю шелл.
Для простой проверки, если есть доступный хост, подключить к нему Xen-центром и откройте консоль сервера. К сожалению, я данную операцию сейчас проделать не могу.
Полноценный комментарий по данному вопросу я дам завтра в рабочее время.
Буду по памяти.
При открытии vncterm для dom0 на исполнение уходит exec /bin/login -f root
Если я правильно помню, она это и исполняет. Выдавая пользователю шелл.
Для простой проверки, если есть доступный хост, подключить к нему Xen-центром и откройте консоль сервера. К сожалению, я данную операцию сейчас проделать не могу.
Полноценный комментарий по данному вопросу я дам завтра в рабочее время.
А вот тут я внезапно, кстати, неправ. На /dev/xvc0 в dom0 действительно логин, а не xsconsole. Странно, нафига они это делали?
PS Мы XenCeter не юзаем, ибо он под винду и проприентарное говно.
Самурайский метод:
xvncviewer -via root@xenhost localhost:5900
В любом случае, если у вас есть админский доступ в xenserver (то есть вы можете делать там что угодно), то наличие консоли с рутом ситуацию хуже не делает.
А если есть ограниченный доступ, то у клиента просто не должно быть никаких прав на control domain или логин в dom0.
PS Мы XenCeter не юзаем, ибо он под винду и проприентарное говно.
Самурайский метод:
xvncviewer -via root@xenhost localhost:5900
В любом случае, если у вас есть админский доступ в xenserver (то есть вы можете делать там что угодно), то наличие консоли с рутом ситуацию хуже не делает.
А если есть ограниченный доступ, то у клиента просто не должно быть никаких прав на control domain или логин в dom0.
Спасибо, что потрудились проверить.
Как и описано в тексте, мне кажется сомнительным возможность подключения любого пользователя системы на данный vncterm.
Как и описано в тексте, мне кажется сомнительным возможность подключения любого пользователя системы на данный vncterm.
Я понял суть проблемы. Вам кажется, что посторонние пользователи должны иметь возможность логиниться в dom0. Это не так.
Никакой пользователь системы, кроме root, не должен иметь возможность исполнять свой код в dom0. Если в системе есть какие-то дополнительные пользователи, то они должны иметь шеллом /bin/false (true, date — по выбору).
Никакой пользователь системы, кроме root, не должен иметь возможность исполнять свой код в dom0. Если в системе есть какие-то дополнительные пользователи, то они должны иметь шеллом /bin/false (true, date — по выбору).
Я солидарен с вашим мнением.
Но данный аспект не является очевидным для рядовых пользователей XenServer.
При создании дополнительных пользователей в системе (второй администратор, итд) они рискуют потерять root запись.
Это произойдет из-за того, что любой пользователь системы, удовлетворивший pam условие xapi сможет подключиться на root шелл через vncterm без проверки пароля.
Но данный аспект не является очевидным для рядовых пользователей XenServer.
При создании дополнительных пользователей в системе (второй администратор, итд) они рискуют потерять root запись.
Это произойдет из-за того, что любой пользователь системы, удовлетворивший pam условие xapi сможет подключиться на root шелл через vncterm без проверки пароля.
Я никогда не возился с авторизацией в xenserver, однако, вопрос в том, сможет ли пользователь с ролью vm-operator получить этот доступ.
Если нет — вопроса нет. Если может — можно открывать SA. Заметим, что добавление чего-либо вручную в /etc/passwd — это явное «low-level ковыряние в xenserver» (одного класса с раскомментированием репозиториев yum) и в этом смысле не отличается от установки своих сервисов и прочей самодеятельности.
Лично я уверен, что никто, кроме pool-operator и pool-admin этих прав не имеют.
Если нет — вопроса нет. Если может — можно открывать SA. Заметим, что добавление чего-либо вручную в /etc/passwd — это явное «low-level ковыряние в xenserver» (одного класса с раскомментированием репозиториев yum) и в этом смысле не отличается от установки своих сервисов и прочей самодеятельности.
Лично я уверен, что никто, кроме pool-operator и pool-admin этих прав не имеют.
В статье обозначен продукт XenServer Free 5.6
По лицензии, в нем нет разделения на роли.
Проблма vncterm актуальна в том случае, если пользователь имеет логин в системе dom0.
По лицензии, в нем нет разделения на роли.
Проблма vncterm актуальна в том случае, если пользователь имеет логин в системе dom0.
Так не должно быть других пользователей в системе. Собственно, на этом можно ставить точку. Посмотрите на /etc/passwd — ни одного открытого аккаунта.
Впрочем, по поводу слушающего на /dev/xvc0 я вопрос в рассылку задал, посмотрим, что ответят.
Впрочем, по поводу слушающего на /dev/xvc0 я вопрос в рассылку задал, посмотрим, что ответят.
Возможно я и не прав, но я не заметил нигде рекомендации не заводить дополнительных пользователей в документации цитрикс. В нерабочее время проверить хлопотно.
Поэтому данный вопрос и был освещен. Для того, что бы end-user воздержался от данных действий.
Поэтому данный вопрос и был освещен. Для того, что бы end-user воздержался от данных действий.
Тыкать в мануал не буду (я всё больше по исходникам шарюсь), но я 100% гарантирую, что _любые_ изменения в dom0, сделанные не через xe/XenAPI будут злобным хакингом и нарушением целостности предустановленной системы.
Более того, я не уверен, что /etc/passwd не будет перезаписан при первом же чихе xapi.
Даже невинный xe-toolstack-restart может привести к проблемам, а вы ставите на уши систему авторизации xapi, а потом говорите " а она на ушах стоит".
(Вопроса с «какого хрена без пароля консоль» это не снимает и я с интересом жду ответа в рассылке).
Более того, я не уверен, что /etc/passwd не будет перезаписан при первом же чихе xapi.
Даже невинный xe-toolstack-restart может привести к проблемам, а вы ставите на уши систему авторизации xapi, а потом говорите " а она на ушах стоит".
(Вопроса с «какого хрена без пароля консоль» это не снимает и я с интересом жду ответа в рассылке).
Исследование данного вопроса актуально, так как при наличии уязвимости во второстепенных сервисах, приводящих к получению частичного доступа к системе может привести к полной потери dom0 именно из-за это «незапароленной консоли».
Каких, например? Предлагаю простой тест — заменяем любой воторостепенный сервис, работающий не из-под root'а на простенький телнет-сервер на связке bash'а и nc, и пробуем вызвать его (то есть спровоцировать уязвимость).
Заглянул в боевой dom0, там из «не рута» только ntp и portmap rpc'ный. portmap только на -l слушает (то есть дырки в нём никому не доступны), а ntpd слушает только на management интерфейсе, то есть опять же, снаружи не доступен.
Заглянул в боевой dom0, там из «не рута» только ntp и portmap rpc'ный. portmap только на -l слушает (то есть дырки в нём никому не доступны), а ntpd слушает только на management интерфейсе, то есть опять же, снаружи не доступен.
Не, это просто феерия профанства.
Citrix XenServer использует несколько режимов хранения виртуальных машин: в виде LVM и в виде VHD файлов.
Все SR у цитрикса (кроме HBA) используют VHD формат. В случае SR LVM и LVMoISCSI VHD хранится внутри LVM (неужели вы ни разу не читали кода /opt/xensource/sm? А /var/log/SMlog?). Существует (полудокументированная) возможность неиспользовать VHD, это делается передачей в device-config при создании SR'а опции type=raw.
Citrix XenServer использует несколько режимов хранения виртуальных машин: в виде LVM и в виде VHD файлов.
Все SR у цитрикса (кроме HBA) используют VHD формат. В случае SR LVM и LVMoISCSI VHD хранится внутри LVM (неужели вы ни разу не читали кода /opt/xensource/sm? А /var/log/SMlog?). Существует (полудокументированная) возможность неиспользовать VHD, это делается передачей в device-config при создании SR'а опции type=raw.
Извиняюсь, видимо не достаточно явно отметил что имеется ввиду отличии хранения в виде «файлов» и в виде LVM. Имелось ввиду представление.
LVM и VHD просто не должны писаться через запятую. VHD — это слой, предоставляющий всякие вкусности, класса thin provision, intellicache'а, обеспечивающий COW-защиту данных от предыдущего клиента (новый не сможет прочитать чужое), снапшоты и т.д.
А LVM — это один из промежуточных слоёв, использующийся разными SR'ами для управления VDI'ями.
Кстати, относительно патчей. Сильно пропатчены у цитрикса три пакета — udev, hotplug и lvm2. И да, их нельзя обновлять из центоса, а надо обновлять из репозитория цитрикса. Почему? Потому что вся вкусность shared SR для lvmoiscsi реализована именно за счёт глубокого и сильного изменения логики работы LVM, который теперь начинает понимать ключ --master.
А LVM — это один из промежуточных слоёв, использующийся разными SR'ами для управления VDI'ями.
Кстати, относительно патчей. Сильно пропатчены у цитрикса три пакета — udev, hotplug и lvm2. И да, их нельзя обновлять из центоса, а надо обновлять из репозитория цитрикса. Почему? Потому что вся вкусность shared SR для lvmoiscsi реализована именно за счёт глубокого и сильного изменения логики работы LVM, который теперь начинает понимать ключ --master.
Спасибо за разъяснение.
Как я уже и сказал, я ошибся в терминах описания способ хранения виртуальных машин.
Но проблема прав доступа остается тем не менее актуальной.
Как я уже и сказал, я ошибся в терминах описания способ хранения виртуальных машин.
Но проблема прав доступа остается тем не менее актуальной.
Минорные редакции XenServer'а не подразумевают наличие разных прав доступа к management'у. Старшие — позволяют настроить по своему усмотрению.
Пожалуйста, чуть внимательнее читайте.
В тексте было сказано:
Файл создается со стандартным umask из скриптов сервера: rw-r-r.
Хранение виртуальной машины с правами rw-r-r является небезопасным.
В тексте было сказано:
Файл создается со стандартным umask из скриптов сервера: rw-r-r.
Хранение виртуальной машины с правами rw-r-r является небезопасным.
Я вас просто не могу читать.
Первый режим можно расценивать как условно-безопасный, так как права на монтирование директорий имеет только суперпользователь.
Какие директории для LVM? В каком месте я должен начать воспринимать вас серьёзно?
Первый режим можно расценивать как условно-безопасный, так как права на монтирование директорий имеет только суперпользователь.
Какие директории для LVM? В каком месте я должен начать воспринимать вас серьёзно?
Спасибо, опечатка.
Пожалуйста, выскажитесь насчет тезиса:
Файл создается со стандартным umask из скриптов сервера: rw-r-r.
Хранение виртуальной машины с правами rw-r-r является небезопасным.
Пожалуйста, выскажитесь насчет тезиса:
Файл создается со стандартным umask из скриптов сервера: rw-r-r.
Хранение виртуальной машины с правами rw-r-r является небезопасным.
Как только у вас кто-то посторонний сумел залогиниться в dom0, то система скомпрометирована.
А про какой SR вы говорите? file? nfs? ext?
А про какой SR вы говорите? file? nfs? ext?
Факт.
Речиь идет в основном о удаленных хранилищах NFS.
Речиь идет в основном о удаленных хранилищах NFS.
А, ну так это всё строится на концепции изоляции dom0.
Кстати, я немного не понял вашего исследования. В системе нет ни одного пользователя, который бы имел право зайти в неё, кроме root'а.
Более того, я пока не могу объяснить причину, но попытка запустить из-под root'а login приводит к закрытию ssh-сессии.
Кстати, я немного не понял вашего исследования. В системе нет ни одного пользователя, который бы имел право зайти в неё, кроме root'а.
Более того, я пока не могу объяснить причину, но попытка запустить из-под root'а login приводит к закрытию ssh-сессии.
Я по тексту и написал, что или изолируйте сети, или же будут данные проблемы.
Проблемы же прав доступа решаются незначительными изменениями в скрипте.
Разговор о добавленных конечным пользователем пользователях.
Проблемы же прав доступа решаются незначительными изменениями в скрипте.
Разговор о добавленных конечным пользователем пользователях.
Так не должно быть таких! Если вы штатными средствами пустили в dom0 пользователя, у которого нет прав уровня root для dom0, всё, считайте, вы нашли дыру. Если же для этого нужно руками в конфигах его прописывать — это не дыра, а глупый хак.
Сделайте useradd testuser и зайдите под ним в систему.
Из под этого пользователя уже будет можно получить root через vncterm.
Из под этого пользователя уже будет можно получить root через vncterm.
Стоп. А кто вам это разрешил делать?
С тем же успехом вы можете поменять конфиг vnc так, чтобы он слушал не на lo, а потом говорить «уязвимость».
Нельзя никаких пользователей в dom0 добавлять.
Вот если вы обнаружите, что какой-то пользователь с низкими правами, созданный через xencenter, может залогниться на хост, да, повод бить в барабаны.
А до этого момента это всё равно что сказать «а вот если я ключик руту в каталог положу, а потом приватную часть на http сервере отдавать всем буду, то это будет уязвимость».
С тем же успехом вы можете поменять конфиг vnc так, чтобы он слушал не на lo, а потом говорить «уязвимость».
Нельзя никаких пользователей в dom0 добавлять.
Вот если вы обнаружите, что какой-то пользователь с низкими правами, созданный через xencenter, может залогниться на хост, да, повод бить в барабаны.
А до этого момента это всё равно что сказать «а вот если я ключик руту в каталог положу, а потом приватную часть на http сервере отдавать всем буду, то это будет уязвимость».
Опять же, по памяти: файловый SR создастся с такими же правами.
Да, проверил файловый, именно так. Вопросом является только то, откуда вы решили, что хоть кто-то будет иметь доступ в dom0.
Спасибо за уделенное на проверку время.
В случае получения такового через уязвимости доступ к виртуальным машинам облегчен.
Я считаю это небезопасным решением.
При таких правах на файл при использовании удаленного хранилища мне видится сомнительным безопасность файлов виртуальных машин. Любой пользователь данного хранилища будет иметь к ним доступ.
В случае получения такового через уязвимости доступ к виртуальным машинам облегчен.
Я считаю это небезопасным решением.
При таких правах на файл при использовании удаленного хранилища мне видится сомнительным безопасность файлов виртуальных машин. Любой пользователь данного хранилища будет иметь к ним доступ.
Ну вот тут вы уже начинаете ерунду говорить. Я имею в виду, что «пользователь хранилища» это какой-то нонсенс. Разумеется, на хранилище нет никаких лишних пользователей, если вы в SAN пустили хоть кого-то, то всё, можно уносить готового.
То есть, я хочу сказать, что это «уязвимость» одного уровня с возможностью получить доступ к конфигу iscsi target (и прочитать там chap password). После того, как злоумышленник оказывается на хранилищах СХД, говорить о дальнейших нюансах безопасности имеет смысла не больше, чем обсуждать влияние на причёску проехавшего по голове танка.
То есть, я хочу сказать, что это «уязвимость» одного уровня с возможностью получить доступ к конфигу iscsi target (и прочитать там chap password). После того, как злоумышленник оказывается на хранилищах СХД, говорить о дальнейших нюансах безопасности имеет смысла не больше, чем обсуждать влияние на причёску проехавшего по голове танка.
Речь об NFS хранилище.
К примеру, у нас есть NFS на котором гипервизор хранит виртуальные машины.
Так же есть, к примеру, ftp на котором удаленный сторедж тот же NFS.
Нужно ли, что бы любой пользователь данного NFS хранилища имел доступ к файлам виртуальных машин?
К примеру, у нас есть NFS на котором гипервизор хранит виртуальные машины.
Так же есть, к примеру, ftp на котором удаленный сторедж тот же NFS.
Нужно ли, что бы любой пользователь данного NFS хранилища имел доступ к файлам виртуальных машин?
Стоп. Всё, нарушение best practicie, кто-то имеет доступ к СХД.
Напомню, что в nfs авторизация по IP, так что если кто-то может прислать что-либо nfs-серверу, значит, он может выдать себя за добросовестный сервер, значит тут говорить не о чем.
СХД зена должна быть 100% изолирована от окружающего мира.
Напомню, что в nfs авторизация по IP, так что если кто-то может прислать что-либо nfs-серверу, значит, он может выдать себя за добросовестный сервер, значит тут говорить не о чем.
СХД зена должна быть 100% изолирована от окружающего мира.
Да, о чем и написано в начале статьи.
В NFS авторизация по айпи. При наличии уязвимости во второстепенных сервисах хоста NFS возможно получение доступа к файловой системе на уровне пользователя уязвимого сервиса. При начальных настройках, будет получен доступ к всем виртуальным машинам.
При наличии возможности исправления прав на более «жесткие» я считаю целесообразным внести данные изменения в скрипт.
В NFS авторизация по айпи. При наличии уязвимости во второстепенных сервисах хоста NFS возможно получение доступа к файловой системе на уровне пользователя уязвимого сервиса. При начальных настройках, будет получен доступ к всем виртуальным машинам.
При наличии возможности исправления прав на более «жесткие» я считаю целесообразным внести данные изменения в скрипт.
Э… Вы в курсе, что зен советует делать no_root_squash для шары? Это означает, что подделавший IP может просто прийти с ID 0 и настрать на права.
То есть опять вы про причёску после танка. Проблема большая — не должен никто приходить по NFS, кроме хостов. Сеть не защищённая, трафик по ней свободно ходит. Мораль: изоляция этой сети от всех остальных. Намертво.
У нас, например, эта сеть даже маршрутизации не имеет. Стоит себе коммутатор без аплинков.
То есть опять вы про причёску после танка. Проблема большая — не должен никто приходить по NFS, кроме хостов. Сеть не защищённая, трафик по ней свободно ходит. Мораль: изоляция этой сети от всех остальных. Намертво.
У нас, например, эта сеть даже маршрутизации не имеет. Стоит себе коммутатор без аплинков.
Sign up to leave a comment.
Citrix XenServer Free 5.6 Security или «…you need to find a different hypervisor»