К сожалению, в плане технологий электропитания и связных с ними областей мы безнадежно отсталая страна.
Российские заводы все еще выпускают элементы с «химией» 10-ти летней давности.
А модернизация схемы контроля батарей не представляется возможным, так как по вышеуказанным причинам у нас мало опыта работы с данными алгоритмами.
В NFS авторизация по айпи. При наличии уязвимости во второстепенных сервисах хоста NFS возможно получение доступа к файловой системе на уровне пользователя уязвимого сервиса. При начальных настройках, будет получен доступ к всем виртуальным машинам.
При наличии возможности исправления прав на более «жесткие» я считаю целесообразным внести данные изменения в скрипт.
Исследование данного вопроса актуально, так как при наличии уязвимости во второстепенных сервисах, приводящих к получению частичного доступа к системе может привести к полной потери dom0 именно из-за это «незапароленной консоли».
Речь об NFS хранилище.
К примеру, у нас есть NFS на котором гипервизор хранит виртуальные машины.
Так же есть, к примеру, ftp на котором удаленный сторедж тот же NFS.
Нужно ли, что бы любой пользователь данного NFS хранилища имел доступ к файлам виртуальных машин?
Возможно я и не прав, но я не заметил нигде рекомендации не заводить дополнительных пользователей в документации цитрикс. В нерабочее время проверить хлопотно.
Поэтому данный вопрос и был освещен. Для того, что бы end-user воздержался от данных действий.
В статье обозначен продукт XenServer Free 5.6
По лицензии, в нем нет разделения на роли.
Проблма vncterm актуальна в том случае, если пользователь имеет логин в системе dom0.
Спасибо за уделенное на проверку время.
В случае получения такового через уязвимости доступ к виртуальным машинам облегчен.
Я считаю это небезопасным решением.
При таких правах на файл при использовании удаленного хранилища мне видится сомнительным безопасность файлов виртуальных машин. Любой пользователь данного хранилища будет иметь к ним доступ.
Я солидарен с вашим мнением.
Но данный аспект не является очевидным для рядовых пользователей XenServer.
При создании дополнительных пользователей в системе (второй администратор, итд) они рискуют потерять root запись.
Это произойдет из-за того, что любой пользователь системы, удовлетворивший pam условие xapi сможет подключиться на root шелл через vncterm без проверки пароля.
Спасибо, что потрудились проверить.
Как и описано в тексте, мне кажется сомнительным возможность подключения любого пользователя системы на данный vncterm.
Дико извиняюсь конечно, виртуала будет доступна в рабочее время.
Буду по памяти.
При открытии vncterm для dom0 на исполнение уходит exec /bin/login -f root
Если я правильно помню, она это и исполняет. Выдавая пользователю шелл.
Для простой проверки, если есть доступный хост, подключить к нему Xen-центром и откройте консоль сервера. К сожалению, я данную операцию сейчас проделать не могу.
Полноценный комментарий по данному вопросу я дам завтра в рабочее время.
Уважаемый amorao, в контексте блога «Информационная безопасность» и освещения проблемы безопасности в базовых сервисах Citrix XenServer без глубокого погружения в систему я считаю целесообразным считать основным управляющим элементом API системы, так как я не затрагиваю более глубокий слой.
Российские заводы все еще выпускают элементы с «химией» 10-ти летней давности.
А модернизация схемы контроля батарей не представляется возможным, так как по вышеуказанным причинам у нас мало опыта работы с данными алгоритмами.
Повторюсь еще раз. При наличии изолированной сети, данная проблема не актуальна. Мы рассматриваем случай не разделенных сетей.
Пример постараюсь привести вам завтра, когда доберусь до рабочей виртуалки.
В NFS авторизация по айпи. При наличии уязвимости во второстепенных сервисах хоста NFS возможно получение доступа к файловой системе на уровне пользователя уязвимого сервиса. При начальных настройках, будет получен доступ к всем виртуальным машинам.
При наличии возможности исправления прав на более «жесткие» я считаю целесообразным внести данные изменения в скрипт.
Я не видел запрета на такие действия, и как раз предлагаю их не совершать.
К примеру, у нас есть NFS на котором гипервизор хранит виртуальные машины.
Так же есть, к примеру, ftp на котором удаленный сторедж тот же NFS.
Нужно ли, что бы любой пользователь данного NFS хранилища имел доступ к файлам виртуальных машин?
Поэтому данный вопрос и был освещен. Для того, что бы end-user воздержался от данных действий.
Из под этого пользователя уже будет можно получить root через vncterm.
По лицензии, в нем нет разделения на роли.
Проблма vncterm актуальна в том случае, если пользователь имеет логин в системе dom0.
В случае получения такового через уязвимости доступ к виртуальным машинам облегчен.
Я считаю это небезопасным решением.
При таких правах на файл при использовании удаленного хранилища мне видится сомнительным безопасность файлов виртуальных машин. Любой пользователь данного хранилища будет иметь к ним доступ.
Проблемы же прав доступа решаются незначительными изменениями в скрипте.
Разговор о добавленных конечным пользователем пользователях.
Но данный аспект не является очевидным для рядовых пользователей XenServer.
При создании дополнительных пользователей в системе (второй администратор, итд) они рискуют потерять root запись.
Это произойдет из-за того, что любой пользователь системы, удовлетворивший pam условие xapi сможет подключиться на root шелл через vncterm без проверки пароля.
Речиь идет в основном о удаленных хранилищах NFS.
Как и описано в тексте, мне кажется сомнительным возможность подключения любого пользователя системы на данный vncterm.
Пожалуйста, выскажитесь насчет тезиса:
Файл создается со стандартным umask из скриптов сервера: rw-r-r.
Хранение виртуальной машины с правами rw-r-r является небезопасным.
Буду по памяти.
При открытии vncterm для dom0 на исполнение уходит exec /bin/login -f root
Если я правильно помню, она это и исполняет. Выдавая пользователю шелл.
Для простой проверки, если есть доступный хост, подключить к нему Xen-центром и откройте консоль сервера. К сожалению, я данную операцию сейчас проделать не могу.
Полноценный комментарий по данному вопросу я дам завтра в рабочее время.
В тексте было сказано:
Файл создается со стандартным umask из скриптов сервера: rw-r-r.
Хранение виртуальной машины с правами rw-r-r является небезопасным.