Безопасное использование виртуальной ос

Интересуют практические аспекты безопастного использования виртуальной ос. Я считаю, если мы хотим анонимно работать из-под виртуальной ос, которая хранится на зашифрованном диске, то помимо обеспечения анонимного канала доступа в сеть на виртуальной ос должны быть проведены дополнительные мероприятия:
1) При каждом новом логине смена информации о ос и устройствах. (mac-адреса, серийные номера устройств, информация о версии ос, браузерах и.т.д.)
2) Ограниченные права пользователя (гость с дополнительными настройками).

Интересует прежде всего каким софтом можно обеспечить выполнение первого требования и в каких правах можно урезать гостя, какие службы отключить и.т.д.?




Комментарии
Гость (12/06/2012 00:12)   

Это наивный способ улучшить неразличимость. Он бы работал, только если б так делалось у всех, причём по умолчанию. Обратите внимание, что в Tor Browser наоброт выравнивают идентификацию так, чтобы все были как один (но для этого нужна массовость).

Информацию об ОС и устройствах (на уровне прав ограниченного пользователя) не скрыть (если только не обращаться к механизмам типа SeLinux): уязвимость в браузере её выдаст. Другое дело, что в виртуалке и всё железо виртуальное, т.е. это мало что даст атакующему, если виртуалка используется только для какой-то одной миссии.

Если помню правильно, mac-адрес в Xen, например, по умолчанию назначается равным некоторому определённому. Принудительно его рандомизировать (без нужды) может оказаться наоборот хуже для анонимности.

в каких правах можно урезать гостя
С точки зрения прав, интересных для анонимности, ни в каких — таково архитектурное свойство UNIX. Можно, разве что, суидность всюду поубирать и позаботиться об уменьшении прав, влияющих на безопасность (не путать с анонимностью).

какие службы отключить
Все, кроме тех, что нужны. Зависит от пользователя. Мне в норме хватало запущенного sshd (от силы).
Гость (12/06/2012 01:12)   
при постановке задачи, нужно определить четко исходные данные (тз):
1. какая хостовая система
2. какая гостевая
3. канал связи
4. какой адаптер используется для работы гостя
5. допускается ли расшаривание ресурсов гостя
6. допускается ли удаленный доступ к гостю
7. шифруется ли диск гостя
и etc
Гость (12/06/2012 01:13)   
в конце концов на каком носителе располагается жесткий диск гостя и какой это диск.
Гость (12/06/2012 01:17)   
да вот еще ))) а чем отличается настройка системы вирт машины и обычной? я по поводу:
Интересует прежде всего каким софтом можно обеспечить выполнение первого требования и в каких правах можно урезать гостя, какие службы отключить и.т.д.?
Гость (12/06/2012 01:23)   
Ну это же тех. форум по безопасности, потому и безопасность обсуждается в общем ключе. Обычно даются такие советы, которые от типа выбранного софта слабо зависят. Если что, Xen — единственная полноценная виртуалка (настоящий гипервизор), являющаяся оупенсорсной [и при этом имеющая очень малый оверхед из-за истиной паравиртуализации (ssd-носители не рассматриваем для простоты)]. Из-под виртуалки Xen (domU) о настоящем железе мало что известно[link1].
Гость (12/06/2012 02:51)   
А virtualbox чем не полноценен?
Гость (12/06/2012 03:21)   

virtualbox — не паравиртуализация[link2] ⇒ лишний оверхед.
На очередном двачетроллересурсе запостили топик «налетаем, много еды»?
Гость (12/06/2012 03:25)   
Comparison of platform virtual machines[link3]
Гость (12/06/2012 03:47)   
о настоящем "железе" гостевой ос мало что известно, в любой виртуалке.
Гость (13/06/2012 15:36)   

Что не ужели нет софта, который бы при загрузке ос подменял све параметры своими? Есть же софт который заменяет mac сетевой карты? Есть. И для других параметров должен быть. Интересует исключительно под Windows.

1. WinXP
2. WinXP
3. ?
4. ?
5. нет
6. нет
7. нет
Гость (14/06/2012 12:18)   

Нет. Тут нужен софт, который меняет, по сути, всю систему. Представьте, что вас посадили за компьютер, дали возможность пользоваться разными средствами разработки софта и запускать всякие программы. При всё этом вы не должны суметь отличить имитируемую версию винду от другой версии, или вообще линукса. Это практически никак не сделать. Более того, софт, запущенный в виртуалке, всегда потенциально может определить[link4], что он именно в виртуалке, а не на реальной машине. Не забывайте, что виртуалка используется для большей анонимности, а не большей безопасности, потому речь идёт о правах произвольного кода, запущенного от потенциально скомпрометированного юзера (но не root'а) виртуалки.


Вы уверены, что по умолчанию по логам системы нельзя отследить, какой был предыдущий mac?
— LUYTRT (27/06/2012 23:13)   
ЕСТЬ ТАКОЕ ДЕЛО.СТОИТ 600$
Гость (28/06/2012 01:49)   
ЕСТЬ ТАКОЕ ДЕЛО.СТОИТ 600$
300 стоит новый нетбук.
Гость (30/06/2012 00:30)   
Кто нибудь покупал VMWare SysClean и VMXPatch?
— neverward (05/07/2012 19:28)   
Не забывайте, что виртуалка используется для большей анонимности, а не большей безопасности

как раз таки гипервизор обеспечивает изоляцию гораздо более надёжную нежели любая ОС своими средствами.
Гость (05/07/2012 19:49)   
TdR бы с вами не согласился[link5].
— neverward (05/07/2012 20:07, исправлен 05/07/2012 20:12)   

T

dR бы с вами не согласился.

о да bsdшники вообще консерваторы лютые, даже яндекс от них сбежал. Виртуализация даёт ring -1. А уж дальше всё зависит от программы гипервизора.
Угроза хост системе заключается в атаке на софт сетевого интерфейса со стороны Сети. Теоретически если там есть ошибки, то можно попасть в хост систему. Т.е. есть мост между хост системой и гостевыми. Ещё могут быть ошибки в реализации гипервизора или даже процессора. В остальных случаях если хост системе запрещено что либо делать кроме того как быть мостом и обслуживать виртуальные контейнеры можно рассчитывать на изоляцию. Гарантия конечно не 100%, как обычно, но она выше, чем при защите толкьо средствами ОС, так как гипервизор таки проще, чем ядро ОС, гораздо проще

Гость (05/07/2012 20:13)   
Т.е. есть мост между хост системой и гостевыми
в vmware предлагается использовать Nat.
Ещё могут быть ошибки в реализации гипервизора или даже процессора
так же зависит от производителя гипервизора, процессора, используемых систем (хоста и гостевой).
— neverward (05/07/2012 20:26)   
в vmware предлагается использовать Nat.

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

в XEN HVM гостевая ОС не может напрямую влиять на реальное оборудование, в том числе память и процессор, что ИМХО является более высоким уровнем безопасности, что бы там не говорили.
Гость (05/07/2012 20:32)   
концепция виртуализации для защиты раньше оценивалась скептически. Докажет ли Рутковская обратное — неизвестно.
/comment38597[link6]. Типа, Qubes — это не просто гипервизор Xen, т.к. там ещё и аппаратная защита/изоляция систем есть.
Гость (05/07/2012 20:37)   
как гипервизор таки проще, чем ядро ОС, гораздо проще
К слову: если что, то вы, наверное, уже в курсе[link7].
Гость (05/07/2012 20:43)   
что ИМХО является более высоким уровнем безопасности
Интересно, что значимее — ваше мнение или мнение основателя и идейного лидера проектов OpenBSD и OpenSSH, а также одного из основателей проекта NetBSD[link8]. Да и пруфлинк на эпик фейл Xen+Intel выше. За SELinux подобных фейлов не припоминается.
— neverward (05/07/2012 20:44)   
Типа, Qubes — это не просто гипервизор Xen, т.к. там ещё и аппаратная защита/изоляция систем есть

недавно натыкался на сию ОС, концепция интересная, если оправдает себя, то возможно в будущем будет стандартом безопасности исполнение отдельный приложений в изолированной от реального оборудования среде.
— neverward (05/07/2012 21:00)   
Интересно, что значимее — ваше мнение или мнение основателя и идейного лидера проектов OpenBSD и OpenSSH, а также одного из основателей проекта NetBSD. Да и пруфлинк на эпик фейл Xen+Intel выше

значимее мнение специалистов по безопасности конечно, но с другой стороны не раскрыта концепция уровня ring -1, т.е. непонятно почему полная изоляция гостевых ОС от реального железа и друг от друга не повышает безопасность скажем отдельного контейнера у которого нет сети и вообще связи с другими контейнерами. Мне интересно не личность, а физическая причина. Например сейчас понятно, что концепция ring таки повышает устойчивость к взлому. Т.е. изоляция программ от железа обязательна. Почему изоляция всей ОС от железа ни к чему не приведёт полезному?

SE как и любая система не может быть 100% надёжной, т.е. нужно чтобы в ОС была абсолютная гарантия от физического доступа атакующего приложения к hdd иначе будет руткит и 100% контроль над системой
Гость (05/07/2012 21:08)   
За SELinux подобных фейлов не припоминается.
Ой, да ладно вам! Вот эта[link9] новость[link10] (у нас тоже[link11] обсуждалось) или какая там? [где SeLinux в принципе помочь от local root не мог, т.к. в коде была логическая ошибка]. Про баги в самом SeLinux unknown пусть лучше расскажет[link12]:
Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.
Гость (05/07/2012 21:14)   
Наверно, TdR хотел сказать, что если ОС работает на реальном железе, есть уязвимости только в самой ОС. А если ОС работает в виртуалке, то потенциально есть узявимости в гипервизоре в нагрузке к уязвимостям в самой ОС. Изначально виртуалки не позицинировались как средство безопасности — это просто средство разделения ресурсов. Не стоит забывать, что TdR смотрит на ОС как на сервер-рутер, где прежде всего критичны remote exploit, а не как на систему для большей анонимности. Я бы не стал применительно к анонимности аппелировать к авторитету Тео, как к истине в последней инстанции, т.к. он имел в виду другие задачи и другие цели, другие модели угрозы.
— unknown (05/07/2012 21:23, исправлен 05/07/2012 21:24)   

И это позволяет разработчикам SELinux всегда отвечать, что никакой дыры в самом SELinux нет, а просто правила недоделаны.


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


Производители виртуалок (и создатели большинства программ) рекомендуют отключать SELinux при малейших глюках, потому что не имеют желания с ним разбираться. Создатели SELinux, наоборот, в последнее время продвигают идею SELinux-модулей для виртуалок. А также связки лёгких псевдовиртуальных контейнеров + SELinux для всяких песочниц (Sandbox).

— neverward (05/07/2012 21:29)   
Наверно, TdR хотел сказать, что если ОС работает на реальном железе, есть уязвимости только в самой ОС. А если ОС работает в виртуалке, то потенциально есть узявимости в гипервизоре в нагрузке к уязвимостям в самой ОС. Изначально виртуалки не позицинировались как средство безопасности — это просто средство разделения ресурсов. Не стоит забывать, что TdR смотрит на ОС как на сервер-рутер, где прежде всего критичны remote exploit, а не как на систему для большей анонимности. Я бы не стал применительно к анонимности аппелировать к авторитету Тео, как к истине в последней инстанции, т.к. он имел в виду другие задачи и другие цели, другие модели угрозы.

полностью согласен. Плюс виртуальные контейнеры могут быть построены по разному, т.е. у каждого из контейнеров может быть включены минимально необходимые модули ядры и вообще выключена загрузка модулей на ходу. Целостность файлов контейнера может быть проверена из хост системы, т.е. в обмен на риск увеличения риска ошибок появляется возможность проверять гостевые ОС на любые взломы просто поставив её на паузу, это не считается как повышение, как и многое другое, что даёт гипервизор? Просто утверждение, защитный код с отдельным уровнем только ухудшает безопасность, просто из-за того, что кода стало больше и никак её не улучшает звучит как-то неполно, возможно мы не знаем весь контекст беседы, ссылку на которую привели выше
Гость (05/07/2012 22:56)   
защитный код с отдельным уровнем только ухудшает безопасность, просто из-за того, что кода стало больше и никак её не улучшает звучит как-то неполно

Есть два противоположных эффекта:

  1. Чем больше объём кода, чем сложнее его логика и чем больше функционал, тем, при прочих равных, он менее безопасен (система тем надёжней и безопасней, чем она проще).
  2. При прочих равных, чем лучше продумана архитектура кода, всякие разные страховки (SeLinux и др.), тем система более безопасна.

В своём время в рассылке был поучительный флейм на тему того, хорошо ли использовать механизмы типа strlcpy[link13]. Одни говорили, что это шаг к большей безопасности, т.к. защищает от непреднамеренных случайных ошибок с копированием строк в C. Другие же говорили, что это шаг к меньшей безопасности, т.к. оно добавляет очень нетривиальную семантику, и если вдруг возникнут ошибки, обнаружить их, найти и понять в чём они, будет намного тяжелее (но ошибки от этого не исчезнут). По-своему правы и те и другие. OpenBSD пошёл по первому пути, Linux — по-второму. Примерна та же дилемма, пожалуй, возникает и при обсуждении виртуалок.
Гость (06/07/2012 00:47)   
исполнение отдельный приложений в изолированной от реального оборудования среде
а что сейчас мешает в любой системе запускать каждое приложение в своей песочнице? или я неправильно понимаю, что вы имели ввиду?
Гость (06/07/2012 00:55)   
подмывает заоффтопить ))
(система тем надёжней и безопасней, чем она проще)
жигули проста, но не хочется на ней ездить именно потому что не надежна.
— neverward (06/07/2012 04:14)   
Примерна та же дилемма, пожалуй, возникает и при обсуждении виртуалок.
Да, навскидку сказать очень сложно, но однозначно утверждать, что безопасность не улучшается я бы не стал.

а что сейчас мешает в любой системе запускать каждое приложение в своей песочнице? или я неправильно понимаю, что вы имели ввиду?
да, песочница штука хорошая, но опять же изоляция там не полная. Например процесс даже в песочнице может исчерпать память или нагрузить HDD так, что система начнёт тормозить, или начнёт форкать себя в бесконечном цикле, что в итоге иногда приводит к завершению ядром других процессов или полной остановке системы. Точно известно на практике, что виртуализация OpenVZ(она как раз по сути хорошая песочница) не защищает отдельные виртуальные контейнеры от влияния скомпрометированного контейнера.

Т.е. слишком сильно влияние программ на аппаратную часть. В случае виртуального контейнера даже полный отказ всей ОС в нём ничего не сделает ни HDD, ни RAM, ни любым другим железкам, так как у каждого контейнера свои собственные железки и друг на друга они почти не влияют. Можно ли считать это большей защитой, нежели sandox? Тут вопрос остаётся открытым
жигули проста, но не хочется на ней ездить именно потому что не надежна
тут сравнение не совсем корректно. Допустим жигули это ОС, а гипервизор это отдельная только для этих жигулей дорога на которой больше никого нет. Конечно можно ухитрится вылететь с дороги на другую изолированную дорогу, но всё таки сделать это сложнее, чем угробить жигулями сверхзащищённую другую машину на той же дороге.
Гость (06/07/2012 04:33)   
а что сейчас мешает в любой системе запускать каждое приложение в своей песочнице? или я неправильно понимаю, что вы имели ввиду?

Нужно, чтобы приложения

  1. Не знали про железо, на котором запущены.
  2. Не знали про чужие процессы, которые запущены в ОС.
  3. Не знали про юзеров, зарегистрированных в ОС.
  4. Не знали имена, содержание и даты создания/модификаций файлов (которые в норме всем доступы) в /var и /tmp.
  5. Не знали времена создания/модификации системных файлов (например, в /usr).

Список намного длиннее, его можно продолжить. Если все требования списка не удовлетворены, при наличии уязвимости обоих пользователей (анонимного и неанонимного) в одной и той же ОС/железе всегда можно доказать, что они живут в одной ОС ⇒ деанонимизация[link14]. Заметьте, настройки firewall'а от этого не спасут.

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

Под неанонимным профилем запускали скайп или flash-плагин? Считайте, что потенциально вся уникальная информация, которая была доступна из-под неанонимного пользователя, утекла. Остаётся добиться уязвимости в любом софте под анонимным пользователем (потенциальных комбайнеров много: firefox, openoffice, mplayer), и утекёт уникальная информация, доступная из-под него. Далее, противник, сопоставляя первую и вторую информацию, легко делает однозначный вывод. Firewall от этого в принципе не защищает.

Про уязвимости под неанонимным юзером я не преувеличиваю. В одной распространённой ОС довольно широкий список подобного по умолчанию сливается в MS при каждом обновлении. Под Linux дела не намного лучше: любая программа имеет доступ ко всем этим данным — так уж устроен UNIX. И никто не знает когда они утекали, и утекали ли вообще. А если считать, что потенциально утекли, вера в неуязвимость прикладного софта под анонимным пользователем — последний барьер защиты, на котором всё висит. Увы, без виртуалок проблема не решается никак. С ними — хоть как-то, но защищает не от полного профилирования (всё равно под виртуалкой будет свой уникальный набор доступных параметров), а только от полной и однозначной деанонимизации.
Гость (06/07/2012 04:42)   
жигули проста, но не хочется на ней ездить именно потому что не надежна.

В экстремальных случаях (низкие температуры, отсутствие СТО под рукой, выход деталей из строя) жигули могут оказаться как раз надёжней. В современной технике если главный компьютер машины откажет, уже ничего не сделаешь. Опыт пилотирования всяких навороченных машин с непрямым управлением самолётом опять же об этом свидетельствует: в критический момент нельзя взять управление в свои руки.

Это как сравнение электронных часов с механическими. У первых не показывает экран как при низкой температуре, так и при высокой, а вторые легко приходят в негодность от механического удара. Нет тут простой однозначности.
Гость (06/07/2012 09:56)   
Нужно, чтобы приложения
это называется: идеальные условия. достичь их невозможно даже в лабораторных условиях, поэтому это остается только теорией.
вообще, мне кажется что при обсуждении виртуальной ос, корректнее детализировать обстоятельства. хотя бы:
1. разработчик гипервизора
2. как построена связь между хостом и гостем
3. как настроена связь с интернет (внешними сетями)
Гость (06/07/2012 10:13)   
Нужно, чтобы приложения
это называется: идеальные условия. достичь их невозможно даже в лабораторных условиях, поэтому это остается только теорией.
Всё перечисленное достигается в Xen по умолчанию.
— neverward (06/07/2012 10:22)   
Всё перечисленное достигается в Xen по умолчанию.
++
XEN hvm
Гость (06/07/2012 11:20)   
Всё перечисленное достигается в Xen по умолчанию.
если он так хорош, почему тогда не используется так широко (за пределами unix)?
Гость (06/07/2012 11:44)   
Если UNIX так хорош, почему тогда повсюду на десктопах винда?
Amazon — это мало? Есть несколько коммерческих производных продуктов.
Гость (06/07/2012 12:26)   
так я не уменьшаю роль продукта. именно потому что пользователь винды большинство, логично было бы не игнорировать этот сегмент пользователей.
Гость (06/07/2012 12:44)   
Если виртуализация поддерживается процессором аппаратно, то можно принудительно виртуализировать в гостевых ОС всё, что угодно, хоть винду. Если не поддерживается, то нужны специальные ядра. Вы уверены, что у винды такого ядра нет? Пилили же, был проект на эту тему.
— SATtva (06/07/2012 14:20)   
жигули проста, но не хочется на ней ездить именно потому что не надежна.

"Make everything as simple as possible, but not simpler" © Эйнштейн. К слову, тенденция к навешиванию на автомобили компьютеров непрямого контроля движения (drive-by-wire) — контрпример нормальным активным системам безопасности, которых нет в "Жигулях", но которые не переусложняют систему более, чем нужно.
— unknown (06/07/2012 21:50, исправлен 06/07/2012 21:51)   

Были устойчивы к нахождению различителя между предлагаемой работающей системой и анонимным оракулом! Пусть анонимный оракул — это идеальная модель, описывающая множество анонимусов, что подразумевает и несвязываемость профилей. Нахождение различителя при помощи достижимых ресурсов — это атака и т.д. Это если не для красоты, а для объединения методологий доказуемой безопасности с доказуемой анонимностью. Может когда-нибудь и анонимную ОС разработают и напишут (с раздачей контекстов анонимности, мандатного управления, анонимными подписями доступа к ресурсам, например, на базе той же QubeOS или SELinux) в соответствии с каким-нибудь теоретическим подходом, а не просто пересборкой из того, что под руку попалось.

Гость (07/07/2012 01:02)   
Да, было бы неплохо. Несколько лет назад один проект делал много шума и самопиара в сети, типа если какую-то там законодательную инициативу примут, они зарелизят анонимую ОС и всем настанет ппц, законодатели пожалеют. Уже и не помню, зарелизили ли что, но интересного ничего не было. Кажетя, 4-5 букв в имени с буквой m, но не mint.
— SATtva (07/07/2012 07:57, исправлен 07/07/2012 07:57)   

m-o-o-t[link15]. Ничего они не выпустили.

Гость (07/07/2012 12:14)   
Анонимус выпустили свою ось.. шума не наделали.
Гость (08/07/2012 00:10)   
Анонимус выпустили свою ось
Очередной дистр/LiveCD с Linux на борту? И как там с фичами?

Ссылки
[link1] https://www.pgpru.com/comment48440

[link2] https://ru.wikipedia.org/wiki/Паравиртуализация

[link3] https://en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines

[link4] https://www.pgpru.com/comment17088

[link5] https://www.pgpru.com/comment32246

[link6] https://www.pgpru.com/comment38597

[link7] https://www.pgpru.com/comment53513

[link8] https://ru.wikipedia.org/wiki/Раадт,_Тэо_де

[link9] http://www.linux.org.ru/news/security/2491099

[link10] https://lwn.net/Articles/268783/

[link11] https://www.pgpru.com/forum/unixlike/osnovnoenaznachenieopciimontirovanijanoexec

[link12] https://www.pgpru.com/comment38599

[link13] http://openbsd.org/security.html

[link14] https://www.pgpru.com/comment48145

[link15] https://www.pgpru.com/novosti/2007/0707s1oktjabrjavvelikobritaniikljuchiperestanutbytjsekretami